Thank you, Adrien! I was bugged by this for a while. Is not critical yet since I am forced to use "enterprise" applications that are able to run only on x11 or need two vestals to hit enter on 15th of june to run on wayland. Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 8 Mar 2021 at 10:09, Adrien Glauser <adrien.glauser@gmail.com> wrote:
Dear all,
Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers.
If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively.
Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11.
Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks)
If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch.
And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland").
Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds.
To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*.
I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback.
Best,
Adrien