@ptd006 how much effort is required to run the application in 800x480 screen, is it possible
Could not set X locale modifiers
while running application
Has anyone faced this issue?
1 Like
Hi
I was looking into “Enter Sim Coords”
Sim co-ordinariness do not get saved,
by default Latitude 53.4360564, Longitude -111.1600470
suppose change them and restart the application , it should take the new value but in linux the value remains the same. has anyone faced this issue
It should be saving it in your $HOME/.wine/drive_c/users/$USER/Local Settings/Application Data/AgOpenGPS/AgOpenGPS.exe_*/3.0.0.0 directory. Inside there you should eventually find a user.config file. It’s saved in there.
I found the location of the user.config file, but the file does not contain any settings, i am using mono to run application linux
Path of the Application
/home/iwave/.local/share/AgOpenGPS/AgOpenGPS.exe_Url_114eeec84c86f6138da808089d68527835cd1a43/user.config
No Settings is being saved in the config file
i have uploaded the user.config for your referenceuser.config.txt (90 Bytes)
I was going to say, that location doesn’t look where it would be if you ran it under wine.
Could be a mono issue.
Definitely saves the sim coordinates under wine.
@sheraz- as noted on my github summary something is up with settings on mono. I remember googling and finding a fix on stack exchange but never got round to implementing. This is something that could be fixed fairly easy though I suspect.
I am trying to run the application in arm based board
mono AgOpenGPS.exe
PID | USER | PR | NI| VIRT | RES | SHR | S %CPU | %MEM | TIME+ | COMMAND
607 | root | 20 | 0 | 167040 | 87664 | 34316 | R 94.1 | 17. 3 | 4:12.68 | mono
628 | root | 20 | 0 | 30776 | 20120 | 16476 | S 4.3 | 4.0 | 0:12.00 | Xwayland
642 | root | 20 | 0 | 3004 | 1840 | 1544 | R 1.0 | 0.4 | 0:01.66 | top
520 | root | 20 | 0 | 50776 | 8864 | 7124 | S 0.7 | 1.7 | 0:04.00 | weston
1 | root | 20 | 0 | 1708 | 328 | 292 | S 0.0 | 0.1 | 0:01.56 | init
2 | root | 20 | 0 | 0 | 0 | 0 | S 0.0 | 0.0 | 0:00.00 | kthreadd
top is giving 94.1 % CPU utilization for mono
has anyone faced this issue
Does it actually work, though? Draws the vehicle, toolbar, field, and coverage?
Bad news, however. The CPU usage is likely the result of the Mesa OpenGL library doing software rendering of everything. I know of no ARM board that supports immediate-mode OpenGL, which is what AOG uses, so if it works at all, you can be sure it’s software rendering which is very CPU intensive. Fortunately the Arm boards usually have multiple cores, so the app might still run okay, if you can keep the CPU from overheating.
What distro are you running on your Arm board? I see you have Wayland working. Were you able to get some kind of hardware-accelerated graphics driver running? So far I’ve had no luck at all with graphics drivers on my Pine A64 board. I can’t even figure out how to get any kind of Wayland desktop running, and X11 isn’t working so well on it.
I have managed to get accelerated OpenGL ES on my Raspberry Pi, however (using rasp-config to enable it).
Depending on your arm board, i remember trying something similar last year, on a raspberry pi 3. Did also run high 80 low 90% with version of last year. Couldn’t run directly from mono-develop either, had to close it first.
Some note on howto : Porting AgOpen for MultiOS | Page 6 | The Combine Forum
I am using DISTRO ?= ‘fsl-imx-xwayland’
That kind of CPU utilization is a pretty sure sign it’s using software OpenGL rendering, so no hardware acceleration. That’s not necessarily a problem, but something to be aware of. Without hardware acceleration AOG can lag a bit and get jittery, which will affect steering and section control.
System requirements needed for running AgOpenGPS in ARM board
Is AgOpenGPS built on OpenGL or DirectX
If OpenGL what version of OpenGL is AgOpenGPSV3 built on
AOG is built using OpenGL, not DirectX, and it uses the immediate mode API that OpenGL supported before version 3. Many/most modern graphics drivers for x86 systems still support the immediate mode API, even while supporting the most recent versions of OpenGL for backwards compatibility. The industry calls immediate mode OpenGL “legacy OpenGL.”
However as I mentioned before, no ARM board supports the immediate mode API of OpenGL in their graphics drivers. ARM boards only support OpenGL ES. Thus no hardware acceleration is available on any ARM device for AOG currently since Linux has to use software rendering provided by the Mesa shared library. This means 100% cpu utilization and jittery performance, even on boards where you’ve enabled hardware accelerated drivers.
Short answer to your CombineForum query: AOG is built on OpenGL API pre v3.1. Yes there are issues caused by ARM only supporting OpenGL ES.
As you have mentioned OpenGL ES will cause issue, Is it possible to port the application from legacy OpenGL to OpenGL ES
Yes one can replace the opengl immediate-mode calls with the creation of vertex buffers and shader scripts, and calls to opengl glDrawArrays. Brian mentioned briefly that in a future version he might change the opengl calls. I’m sure he would accept patches that implemented this. Anyone who wants to do this is welcome to use my shader scripts from QtAOG. I also created some helper functions to make it very easy to draw with opengl es. Anyone is welcome to borrow the idea and implement it in c#.
Hi Everyone,
What are the minimum hardware and software support required to run this application smoothly in Windows, Linux and ARM.
Your Feedback is appreciated.
@torriem Can you share the link?