Please remove the xwayland ("Wayland") and wayland ("Full Wayland") sessions as we know them

8 Mar 2021

      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

tags

participants (19)