Survey on changes of Plasma defaults: XWayland, xf86-input-synaptics

Hi,

we are considering a few changes in the defaults offered by the KDE Plasma
and related packages. If you have a touchpad or use any of the Plasma Wayland
sessions, they will likely have an impact on your workflow, so we'd like to
hear your feedback before committing to anything.

Let us know!

Offer only "Full Wayland" instead of both "Xwayland" / "Full Wayland" sessions
----------

To ease the transition into a Plasma Wayland session, it's configured that Qt
and GTK applications prefer XCB over native Wayland: in other words, Xwayland
is used for most applications instead of the native Wayland client
implementations. This is what the "Plasma (Wayland)" session does, which is
referred to here as "Xwayland" session for clarity.

This means that some benefits of Wayland, like isolation of clients and support
for per-monitor scaling (mixed-DPI setups), are missing. To mitigate that,
there is a second session, called "Full Wayland", which forces both Qt and GTK
applications to use their native Wayland client implementation again.

Now there is a discussion upstream where it was requested that this split and
GTK/Qt behaviour difference compared to other distros should be dropped:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/85

The arguments here are that this is not appropriate for developers and that
most of the issues worked around by the Xwayland session are fixed meanwhile.

So far we have read about both sides, some which wouldn't be able to use the
Plasma Wayland session without the Xwayland setup and some which have a better
experience with the "Full Wayland" session.

Arguments pro Full Wayland:

- Scaling works properly (including per-output scaling)
- More consistent application behaviour (assuming that they can speak wayland
  natively)
- More isolation between applications
- ...?

Arguments pro Xwayland:

- Upstream, Qt does not consider qtwayland to be a good default in GNOME
  sessions due to various compatibility issues and so it explicitly uses the
  fallback to XCB there (https://bugreports.qt.io/browse/QTBUG-68619).
- It avoids certain incompatibilities like with Yakuake and stability issues,
  like with KMail (and other users of WebEngine)
- ...?

I'd argue that developers are able to switch to the "Full Wayland" kind of
session themselves. If the "Full Wayland" session is perfectly usable by
those who use the "Xwayland" session currently, there's no reason to keep this
split anymore though. Otherwise, please tell us what makes the "Full Wayland"
session a worse experience.

Note that this won't touch the Xorg session at all: it'll stay the default for
the at least near future.

Don't recommend xf86-input-synaptics by default
----------

There are two main X11 drivers for touchpads: xf86-input-synaptics and
xf86-input-libinput. Synaptics is practically dead upstream while libinput is
the de-facto replacement, also for tablets.

Currently, if plasma5-desktop is installed, xf86-input-synaptics is
automatically pulled in as well. It takes precedence over the libinput driver.
While it's a simple step to remove the package and thus let libinput take over,
the question is whether this should be the default state.

Pro synaptics:
- More configuration options
- Some say it works better for them
- ...?

Pro libinput:
- Maintained upstream
- Some say it works better for them
- Used by wayland compositors, so a more consistent experience
- Better handling of some hardware configurations (e.g. Thinkpad trackpoints)
- ...?

Cheers,
the openSUSE KDE maintainers


-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]