Hello there,
nice to see some people trying to run this app on Linux, too! My goal is to run AgOpenGPS on some cheap tablet. The most promising for me is the PineTab (ARM), which should be released soon and is able to run mainline Linux kernel. Or use some cheap Android tablet.
That requires:
AgOpenGPS working on Linux (@torriem and @ptd006 already started working on this, good job guys (although each chose different path))
Run app on ARM (should not be so difficult)
Run app on Androind ARM (I do not want to use Android, but who knows).
I just discovered this awesome app, but feel free to tell me if you want some help in this process.
P.S.: looks like this project required C# 7.1, which is not available on my VM Xubuntu 18.04 (Mono 4.6.2 only), I will try newer system in VM.
Another show stopper for anything based on ARM is OpenGL support. More specifically, AOG uses immediate mode GL calls, which are a part of OpenGL 2.1, and all Windows computers ship with an emulation of OpenGL 2.1, called opengl32.dll, that uses DirectX (much like Qt does, below).
Most desktop Linux machines are going to have Intel, AMD, or nVIDIA graphics cards and, so far as I know, they all support OpenGL 2.1, at least on Linux. Hence we can run AOG just fine in Wine or possibly directly with Mono with no issues. However ARM devices (including phones and tablets) only support OpenGL ES, which is a pipelined version of OpenGL and uses shaders to render the triangles. OpenGL ES is lighter weight but also faster than OpenGL 2.1, at least for the kind of things phones and tablets do (games).
When I started porting AOG to Qt, I started rewriting the OpenGL calls to OpenGL ES calls. Oddly enough, Qt on Windows doesn’t use OpenGL natively at all, but has an emulation layer that uses DirectX. That only provides an OpenGL ES interface there. Is your head spinning yet?
There are good reasons why Brian uses OpenGL 2.1, but that’s an area that some of us might contribute and Brian might not object to it that would ultimately lead to more portability. Aren’t we glad Brian used OpenGL and not DirectX!
I can speak more to the details of porting OpenGL calls to GL ES if anyone is interested in the details.
Qt may use directX, but windows dll does not. OpenGL is a direct API on the graphics card that is hardware accelerated. WINDCLASSEX class from the win32 API creates a device context and all required buffers directly since v1.4
If your video card was made in 1994 and had no opengl support, then software emulation was used.
whats the trick to get the program installed, i am new to linux as well as AOG, very interested in learning though as i have an old laptop, i would like to build the system around
I use an Ubuntu-based distro and installed wine through apt. You need to make sure you install the 32-bit version of wine:
sudo apt install wine32
Then wine should be able to run it. I like to put windows apps into their own prefix and I’ll often force it to be pure 32-bit. so I’ll do something like:
That will install aog into the ~/AgOpen/GPS prefix, and you can then run it with WINEPREFIX=~/AgOpenGPS WINEARCH=win32 wine ~/"AgOpenGPS/drive_c/Program Files/AgOpenGPS/AgOpenGPS.exe"
On my system, wine seems to automatically add any start menu shortcuts that an installer creates to the desktop menu, so you can reach it more easily through your normal linux desktop menu after installing, even with custom prefixes and special WINEARCH flags.
If you need to install MS dotnet runtime (it’s less glitchy than the mono runtime built into wine), you can download the winetricks script and then run it with your custom prefix: WINEPREFIX=~/AgOpenGPS WINEARCH=win32 /path/to/winetricks
Follow the menu prompts to install dotnet 4.6.3.
Oh my mistake. The ~ shortcut doesn’t like being in quotes. Just replace it with the path to your home directory. Or put the ~ just outside the beginning quote. I used quotes because of the “Program Files” has a space in it.
@soniccpp- I like the idea I fixed more things in the mono build but I’ve found the mono winforms slightly disappointing. Charts/plotting (used for the autosteerer) is not implemented for example, as well as the layout/spacing issues that are fine with wine. I read on stack exchange that mono WinForms is all but abandoned. So I lost a little motivation and may focus on wine.
An Android version with current code base is not going to happen I think, at least I don’t consider it a viable path and am not working on it*. However a lot of cheap android tabs can run some form of full linux.
*My current project involves running an object detection neural network (YoloV3) on a live video feed so needs decent hardware. Basically cheap tablet is a just nice side project. Rather than Android port it would be better for me to separate all the nice logic Brian has into a libAgOpenGPS I can easily pull into my current python code.
@ptd006 I see. Do you have plans to send PR with your changes to Brian? Even though you do not plan to continue porting app to Mono, those fixes are a good thing (unless they break something on Windows). Btw for building the app from your fork I had to use LANG=C env (since my environment is not eng) to avoid following err msg:
Input string was not in a correct format.
@torriem I disagree that Mono is no longer developed (it supports much more platforms than Net for example). Although Net Core supports Linux and also ARM devices these days. Even the OpenGL should not be such a problem - open source drivers evolved a lot in last years (but it is very different for every ARM vendor). But yeah, GL ES has better support in mobile devices.
It looks like the biggest issue is the Windows Forms. This app is not the first one I am facing the issue running Mono with WF on my PC. As torriem pointed out, Avalonia UI could be the right thing (it supports multiple backends, like Win32 and GTK). But as a non-C# developer I can not imagine how big effort would it be to port the WF to new UI.
@sonicpp - glad you tried my changes. I was indeed going to check I hadn’t broken anything on Windows before sending a PR to Brian. In WINE the behaviour and performance seems equal to the .msi version so I am optimistic I have an old Windows box I’ll need to dig out. Anyway AgOpenGPS/Ubuntu_Mono.md at master · ptd006/AgOpenGPS · GitHub for the changes so far (no updates recently as my local version is a bit of a mess).
Anyone seen GitHub - eringerli/QtOpenGuidance ? I haven’t checked exactly what is implemented. Seems he has clear design goals. My feeling is AOG would benefit from refactoring to separate the UI from the logic but I’m not excited by a big rewrite. OTOH avoiding duplicated effort would be great.
When I tried doing this last winter, I could get it working well enough in Wine to run a few passes, but then the GPS port (or autosteer, not sure now) would eventually bung up to the point that it had to be restarted, about every 10 minutes. And if you tried to go into certain settings pages, it would completely pooch itself.
I was running an Arch install so I had the latest libraries going and that seemed to help vs. a Kubuntu at the time.
I’m definitely going to try again this year now that I have UDP communications set up. I did try back then to Mono compile it but it would crap itself for some non-supported UI elements that were being used at the time.
QTOpenGuidance looks very interesting, I see they’re trying to keep it AOG compatible. Looks like it’s seeing a lot of dev, I did run across this last year and it was very early days.
This was where I was a couple years ago looking at the codebase and figuring it was better to start from scratch in QT than trying to directly port AOG. But as others have said, time is a factor and the thought of doing all that was daunting.
Has anyone faced this issue while opening Steer Chart
System.NotImplementedException: The method or operation is not implemented.
at System.Windows.Forms.DataVisualization.Charting.Chart.BeginInit () <0x41c1ab30 + 0x00017> in <filename unknown>:0
at AgOpenGPS.FormSteerGraph.InitializeComponent () <0x41c18650 + 0x00490> in <filename unknown>:0
at AgOpenGPS.FormSteerGraph..ctor (System.Windows.Forms.Form callingForm) <0x41c18390 + 0x001c7> in <filename unknown>:0
at (wrapper remoting-invoke-with-check) AgOpenGPS.FormSteerGraph:.ctor (System.Windows.Forms.Form)
at AgOpenGPS.FormGPS.toolStripAutoSteerChart_Click (System.Object sender, System.EventArgs e) <0x41c17ef0 + 0x00067> in <filename unknown>:0
at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs e) <0x41c15910 + 0x00065> in <filename unknown>:0
at System.Windows.Forms.ToolStripMenuItem.OnClick (System.EventArgs e) <0x41c16d90 + 0x0032b> in <filename unknown>:0
at System.Windows.Forms.ToolStripMenuItem.HandleClick (Int32 mouse_clicks, System.EventArgs e) <0x41c16d40 + 0x0001b> in <filename unknown>:0
at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs e, ToolStripItemEventType met) <0x41bea450 + 0x000e1> in <filename unknown>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem:FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType)
at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) <0x41c15620 + 0x001a7> in <filename unknown>:0
at System.Windows.Forms.ToolStripDropDown.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) <0x41c16ce0 + 0x00013> in <filename unknown>:0
at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) <0x41c152b0 + 0x00118> in <filename unknown>:0
at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) <0x41ae5d80 + 0x00217> in <filename unknown>:0
at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) <0x41b918a0 + 0x00013> in <filename unknown>:0
at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message& m) <0x41b965d0 + 0x00013> in <filename unknown>:0
at System.Windows.Forms.ToolStripDropDown.WndProc (System.Windows.Forms.Message& m) <0x41c12d50 + 0x00033> in <filename unknown>:0
at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) <0x41ae5d50 + 0x00024> in <filename unknown>:0
at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) <0x41ae5d10 + 0x00036> in <filename unknown>:0
at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) <0x41ae4650 + 0x0031c> in <filename unknown>:0
@sheraz my github contains the modified PNGs but I guess you found d them. I can’t remember the exact convert/mogrify command but I think it was simply converting index transparency to full alpha channel.
The error you are seeing above is because charting is not implemented on mono winforms- please see my comment above.
I fixed more things in the mono build but I’ve found the mono winforms slightly disappointing. Charts/plotting (used for the autosteerer) is not implemented for example, as well as the layout/spacing issues that are fine with wine. I read on stack exchange that mono WinForms is all but abandoned. So I lost a little motivation and may focus on wine.