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