apm_planner
apm_planner copied to clipboard
ArduPilot
Problems with primary flight display and QSG_RENDER_LOOP
@Arne-W I'm running into an issue with the solution suggested in #646.
- Without setting
QSG_RENDER_LOOP, apm planner works correctly but consumes a lot of CPU, as reported in #646. -
With
QSG_RENDER_LOOP=threaded, apm planner runs with reduced CPU, but the "primary flight display" is blank.
This is running on Fedora 25 (running XWAYLAND) on an Intel graphics chipset (Intel Corporation HD Graphics 520 (rev 07)), and apm planner was compiled against Qt 5.7.1.
(Note: connected to SITL, not actually flying in the middle of Boston Logan)
AHHRG - I hate this bug....
I have no Idea what is happening, but perhaps the XWAYLAND could be the culprit. Look at the second part of the the fix here. Perhaps setting the Qt::AA_X11InitThreads is not sufficient on XWAYLAND.
First of all you should check if the attribute is set on your Fedora build and depending of the result enable or disable Qt::AA_X11InitThreads attribute.
It looks like it is a QT/Wayland issue. If I log in using an Xorg session instead of Wayland the flight display works correctly. I guess this may be more of a Qt question at this point.
a small update:
Current Wayland status is: if user is using "QSG_RENDER_LOOP=threaded" then the primary flight display is dead, but the top statusbar (with mode, green/red heartbeat square) is alive, if that enviroment variable is NOT set, PFD works, but mode and heartbeat is frozen for any other tab than "flight data"
Ubuntu 18.04 uses Xorg by default again, and so the problem is gone ... for now. :)
FWIW : this is the status on current master today:
I tested on a Intel-graphics laptop running Ubuntu 23.04 Xorg and Wayland
The QGS_RENDER_LOOP variable does not seem to have any effect anymore (but there is no CPU hogging) The PFD and some other widgets work only for the self-compiled version, (not the current appimage)
@AndKe could you please test "LIBGL_ALWAYS_SOFTWARE=1" I know its not nice to turn off hardware acceleration but for me it works. It seems that there are some issues with the appimage which is build on an ubuntu 18.04 for maximum compatibility with newer graphics hardware.
@Arne-W , is that an environment variable? / to be used the same way as QSG_RENDER_LOOP?
Oh, sorry for forgetting to tell you. Yes, LIBGL_ALWAYS_SOFTWARE=1 works as advertised, it is kind of unfortunate to use more power for software rendering in the field (draining laptop battery faster) I am even surprised how much more power it takes to render even a static map and small PFD, (I connected to SITL)
Oddly, it is only PFD , EKF widget and the Vibration widget that is affected, the old PFD and the others are fine.
I think: "what do those three do differently, and why?"
@AndKe Perhaps you would like to test: https://www.dropbox.com/scl/fi/q9hu8bmdxy1enoc3cdqyj/APM-Planner_2-2.0.30-x86_64_DEV.AppImage?rlkey=r1q5wlxhfz2p2igfgqlfhu7p5&dl=0 The graphics issues should be fixed - hopefully :smile:
@Arne-W Much appreciated! Unfortunately, I left the intel-graphics laptop at office, and have only Nvidia laptop and workstation at home. So I'll test it Monday. Have a great weekend.
@Arne-W I picked up the small laptop at work, and the .AppImage works perfectly! Tested PFD, EKF, and Vibration widget. Thank you, please merge :)
I have to say that this issue is still with me on a non-Wayland configuration (and LIBGL_ALWAYS_SOFTWARE=1 also works for me), so the problem might be not in the format.setSamples(16) fix.
@mbuzdalov did you build from the master, or use something ..older?
FWIW - I just tested, no "LIBGL_ALWAYS_SOFTWARE=1" (which is great for battery life) - I tested with both Xorg and Wayland, on Ubuntu 23.10 - and both worked flawlessly.
@AndKe I build directly from master. This might be a funny combination of hardware (a nine-years-old ThinkPad), operating system (Gentoo) and the approach used in the widget. It worked two years ago and stopped with what was apparently a minor Qt update, which often means that some part of Qt is used in a way that miraculously happened to work with the older code. However, my Qt experience is non-existent, so I cannot blame anything or anyone for sure...
@mbuzdalov FWIW: I am using the Qt that comes with the distro, - not the community edition.
$ qmake -v
QMake version 3.1
Using Qt version 5.15.2 in /home/andre/Qt/5.15.2/gcc_64/lib
@mbuzdalov Could you please try to reduce format.setsamples(8) to 4 or 2 ? I changed it arbitrarily to 8 as it worked for me on ubuntu 18.04 to 23.10.
Have you checked the appimage I provided for testing? The link is here.
The AppImage has the same problems for me (blank primary flight display, which resumes to work after LIBGL_ALWAYS_SOFTWARE=1).
Building with format.setSamples(4) actually solves it for me, thanks!
@mbuzdalov Nice to hear that it works for you - perhaps we should reduce the value to 4 in general....