Issue with Qt Apps after enabling GDM Wayland via Garuda Assistant (among other things)

Issues & Assistance GNOME
1

TL;DR - The way enabling "GDM Wayland" is implemented via the Garuda Assistant breaks Qt-based apps running GNOME under X11 because it sets QT_QPA_PLATFORM=wayland globally.

Introduction

In this post, I'm putting forth some of the wealth of troubleshooting and research I've done today. It's not strictly a "help me" post since I figured out (most) of what was going on, but I do have some questions and suggestions at the end. If nothing else, hopefully it may be valuable to other users.

This might also serve as something of an update to my other posts/comments here and here as some of the issues seem related.

NOTE: Running GDM with the Wayland backend, and running GNOME under Wayland/X11 are two different things, and configured differently, the weirdness I ran into is tied to both. I've tried to be clear about which is which.

Bugs/Issues Encountered

  • Enabling the "GDM Wayland" option via the Garuda Assistant applied the intended changes initially, but:
    • One of those changes breaks Qt apps under X11 (the setting of QT_QPA_PLATFORM=wayland directly in /etc/environment)
    • Disabling the option also runs correctly, but if any other changes have been made to the files affected Garuda Assistant doesn't detect that it's run successfully and toggles the checkbox back on.
  • No option to choose between Wayland and X11 as the GNOME Shell display server is presented by default, unlike most other GNOME distros/editions, even though everything is packaged to allow for both.
  • The Garuda Assistant option both enables the GDM Wayland backend and the option to select GNOME or GNOME on Xorg, but its implementation breaks Garuda Assistant and other Qt-based apps.
  • Specific, additional, and seemingly unnecessary environment variables are set in ~/.profile, which is only sourced under X11 but don't successfully counter the breaking changes applied by Garuda Assistant after enabling "GDM Wayland"
  • Other seemingly unrelated and/or overlapping variables are set by said option directly into /etc/environment.

These last few aren't relevant to GNOME, but I did notice them in this process.

  • Both ~/.config/autostart/initial-user-setup.desktop and ~/.config/autostart/bashrc-setup.desktop don't appear to work, as evidenced by the fact that they haven't deleted themselves and the presence of both a mostly empty ~/.bashrc and the ~/.bashrc_garuda.
  • The mentioned initial-user-setup.desktop refers to gamemoded and setup_dxvk neither of which are pre-installed (at least on Garuda GNOME).
  • Though ~/.config/autostart/dconf-load.desktop does work since its options are set and it is removed, it does apply a couple keys that don't exist anymore for the GNOME Terminal.

The Usuals

My garuda-inxi is here. A log snippet for Garuda Assistant failing to launch after enabling "GDM Wayland" is here, and the associated coredump is here.

The Troubleshooting

As per this comment I looked into the relevant /usr/lib/udev/rules.d/61-gdm.rules, and while it is a bit more aggressive in disabling the Wayland backend for GDM, none of the flags applied to my system as far as I could tell.

I went through a number of Archwiki pages, manuals, etc. for GDM, GNOME, Wayland, X11, and anything related looking for stuff, and while I did learn a lot nothing proved super enlightening initially.

I spun up a Fedora 35 VM to compare the GDM and GNOME related files to a more "stock" GNOME 41 install, and while there were some notable differences I don't think any of them were causing any issues. I can provide significantly more detail on this if necessary.

I dug through all the files placed by garuda-gnome-settings as well as the entirety of /etc/skel/ which led me to where the actual scripts are for the "GDM Wayland" option I've mentioned. This was enlightening and helpful.

I also did as identical an installation as possible of Garuda GNOME in another VM just to start from default and do side-by-side comparisons. I installed both my machine and the VM from the latest 03/29 .iso's and selected the same Calamares options and post-install helper options. I made a detailed log of my troubleshooting steps here, as they're too long to put in this post.

This last step is how I found the culprit of the Qt-breaking issue above, and led me to the non-GNOME issues above.

Possible Fixes

  • It seems that since ~/.profile supercedes the options set in /etc/environment and is only sourced when logging into GNOME on Xorg, the simplest fix would just be to add a line like QT_QPA_PLATFORM= to .profile so that both GNOME and GNOME on Xorg should work without breaking Qt apps.
  • According to the Wayland Archwiki page under the Qt section, it's also valid to put QT_QPA_PLATFORM="wayland;xcb" so that Qt apps will use Wayland if available, but fallback to X if that doesn't work.
  • The on script for "GDM Wayland" could just also add the necessary variable(s) to .profile or somewhere else loaded exclusively by X11.
  • The same script could be changed to pipe variables to somewhere that only gets sourced under Wayland, although my time in the documentation didn't indicate something like that existed.

Further Suggestions

  • In general, it seems weird that variables like BROWSER and MAIL would need to be set for a script that just swaps on the Wayland backend for GDM. There may be a good reason for this though, I have no idea.
  • Xorg/X11 being preferred or recommended could still be enabled without writing out the possibility of switching between display servers entirely, and this behavior is possible without breaking anything (beyond what Wayland itself does) under other Arch- and non-Arch GNOME installs. I do get that Garuda is trying to offer a functional OOTB situation for as many GPUs as possible though so maybe not.
  • The out-of-the-box situation in ~/.config and ~/.local at least appears very cluttered. Lots of references to apps that don't ship with the distro and some scripts that don't run. This might be unavoidable or best-practice though.

Conclusion

Thanks for taking the time to read this if you did! I'm happy to do the work myself, I'm going to familiarize myself with the repos a bit more tonight and look into submitting pulls/reports for at least some of this stuff. I'd also be willing to work up something for the wiki as I have already put together a lot more than is pictured here. If anyone has any insight or anything to add, I'd love to hear it!

5 Likes
2

Thanks a lot for the detailed feedback - I will take a closer look at the weekend and apply the suggestions as needed :slight_smile:
Also, feel free to open merge requests! These are very welcome as well :blush:

3 Likes
3

Awesome, thank you! I was worried I'd gotten a little too verbose and/or nitpicky, lol

I'll try and put some requests through once I'm comfy with things and have done a bit of poking, but looking forward to contributing to this awesome project.

5 Likes