If anyone is interested, a long-standing bug in the Wine project has been fixed finally and once again we can install dotNet 4.8 in Wine and it runs AgOpenGPS nearly perfectly again. This of course only applies to x86 hardware. I have an old x86 tablet stuck on an old version of Windows 10 that I’m considering installing Linux on, and will try to run AgOpenGPS on it under Wine and see how it performs. On my Linux desktop it runs under Wine quite well.
Version 5 almost runs under Mono but not quite. It’s much more usable under Wine.
Anyone wanting to try it should make sure Wine is at least version 6.6 (I’m on 6.13), and use winetricks to install dotnet48.
Hi, thanks for info. I am trying it now, but the 3D viewport is not rendered at all. All other graphics (buttons, pictures) seems to work. Have you faced this issue?
Nothing interesting I guess. First I blamed this msg wgl:glxdrv_wglShareLists Could not share display lists, one of the contexts has been current already !
but then I tried it with Zink (translation layer to Vulkan), where it finally works, and there is exactly the same message.
Just for info, there is a project called box86 (or box64 for 64 bit version), which allows to run x86 (or amd64) instructions on ARM device for example. Together with running x86 Wine, you can run Windows application on Arm Linux. Unlike Qemu it does not emulate whole system, but uses native libraries where possible, so the performance is pretty good (check youtube). Because AOG uses OpenGL, which might not be supported on ARM devices, using another software for translating OpenGL calls to OpenGL ES, like GL4ES, might be required.
I tried AOG on TwisterOS, which has x86 Wine and Box86 preinstalled. Unfortunately it has still old Wine version by default so I manually replaced Wine by newer version, but AOG did not work for me.
But the future looks promising (if AOG compatible with Mono and GL ES will not arrive sooner).
QEMU has also been able to do this sort of emulation from the beginning also. They call it user mode emulation. I used to use it years ago to run Adobe Reader (x86 only) on my PowerPC linux laptop. It passes through kernel syscalls to the real native kernel. I don’t know about OpenGL support.
Getting wine running under any of this sort of user-level emulation is tricky because it requires a special kernel memory configuration that isn’t normal for the Pi. Kernels on the Pi 4 work fine.
If it weren’t for WinForms, AOG would run as-is on Arm linux at native speed right now using dot net core. Moving off of WinForms would be a huge undertaking.
There is another project Hangover, which uses Qemu. I think they use ARM version of Wine (for example) and one x86 version running in Qemu, where these two applications communicate. There is also some discussion and comparison between qemu and box86 using wine.
I have not tried Hangover yet, tho.
Interesting. So does that mean that AOG supports OpenGL ES now?
Oh yes. Forgot about that. Converting AOG to use pipeline GL calls would indeed be required (and would be good for regular AOG anyway). However, I believe the GL4ES project would work to provide OpenGL 2.1 support on any of the ARM SBC linux distributions, however. So that would allow AOG’s current OpenTK-based GL to work without change on dotnet core.
How did you guys get the COM port connections working while doing this? I’ve been trying with some ubuntu based distros and just can’t seem to figure it out.
What’s not working? Wine automatically picks up all serial devices you add to the computer. Mind you it’s a bit ridiculous as Wine counts all the pseudo-terminals as COM devices, so things go up to about COM34. Typically my plug-in devices end up being from COM35 and up.
What you can do is run Wine’s regedit. From a shell, run “wine regedit” and it will come up. Go to HKEY_LOCAL_MACHINE/Software/Wine/Ports. Right-click and add a new string value. Call it something like COM1 (or whatever port you want to define). Then take a look at /dev/serial/by-id. You should see consistent, unchanging names there. Past the name of the device into the value for the COM1 key you just created in regedit. This will cause WINE to consistently treat that device as COM1 (or whatever you chose). Makes it a bit easier than trying to figure out which of the automatically-discovered com ports is which.
On my laptop running Ubuntu 20.04, my my Ardusimple board is /dev/serial/by-id/usb-u_blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00. If I put that long name in to regedit under COM3, then it consistently comes up that way in wine. Very handy.
I assume you have to have everything plugged in before launching AOG in wine. I don’t think rescanning the ports quite works when it’s run under wine.
I did that and it seems to be reading the ports fine. Seems like the problem is between AgIO and AOG because I can have the ports connected and see the NMEA sentences coming in in AgIO but AOG is completely lost. Running the same setup in wondows, I’ve noticed there is some UDP communication even though I’m not using it. Still a bit green with linux to solve this one so help would be great.
Doesn’t AOG uses UDP to communicate with the AgIO binary? That should be working fine under wine but I haven’t ever actually tested it with real hardware. I might be able to do a test in the next few days.
Hi, I have the same issue. First I blamed Wine, but than I noticed that it does not work with Mono either. Seems like its because AOG uses broadcast on localhost for AIO. Could you check if there is BROADCAST enabled on your loopback? On my system, like many other Linuxes, broadcast on loopback is not enabled:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
Yeah I can’t think of any reason to use a broadcast address on the lo interface. Hopefully this will get merged.
If one could locate ARM versions of the official .NET 4 install packages for Windows, it should be possible to run AOG on an ARM linux computer under native ARM wine. That would be quite interesting.
Can you elaborate? I’ve never seen broadcast over loopback before.
I just tried the patch here and it seems to work fine on Windows 10. At least the GPS receiver gets into AgOpenGPs from AgIO, so I know the two apps can communicate directly over 127.0.0.1.
Looking at the source code I cannot think of any reason it would not work on Windows either. What am I missing? Perhaps a firewall issue?
Interesting! I wonder if the same problem occurs on Linux (under wine). Hopefully we’ll find out.
I don’t have a machine interface to test with yet. Would be interesting to fire up wireguard and see what’s happening when the traffic isn’t getting back to AOG.
