First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

Neal Gompa ngompa13 at gmail.com
Mon Sep 18 05:44:28 BST 2023


Hey all,

So unless you've been living under a rock for the past week, you might
have noticed a bunch of buzz about Fedora KDE proposing to drop the
X11 session with Plasma 6[1]. Those of you who were at Akademy last
year[2] or this year[3] knew that this was coming. For the rest of
you... 🤭

Over the past few days, I've gotten a deluge of use-cases and needs
that would be useful to sort through and figure out actions to move
forward on. Some of them, I've got ideas, others less so.

The first thing that came up was that KiCad seems to need help and has
had a bad experience interfacing with some folks over resolving their
issues moving into a Wayland world.
* https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/
* https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ
I don't have any particular suggestions here, though David Edmundson
mentioned in the Fedora KDE Matrix room the idea of creating a new
protocol to support their particular need of positioning and plumbing
it through to Qt so that wxQt can use it. Also, some dedicated
outreach might be a good idea to get them to be more amenable to the
Wayland world.

Session restore has come up a few times. It actually came up during
the initial discussion within the SIG too, and has come up again
during the proposal discussion in Fedora.
* https://pagure.io/fedora-kde/SIG/issue/347#comment-856399
* https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/
GNOME designed a protocol for their use, can we reuse this as an
initial way to solve this problem? What's stopping us from doing
something here?

Barrier/Input-Leap has come up as well. Seamless keyboard and mouse
handoff across computers is in demand.
* https://discussion.fedoraproject.org/t/89794/6
* https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12
The necessary portal frontends have landed in xdg-desktop-portal and
so we're just missing the requisite backend in xdg-desktop-portal-kde.

Something that was a little surprising to find out is that kwin's
support for the number pad seems to be in less than ideal condition.
* https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5VHB34MWX5UTJE3CLOINE6OBREQIX4RY/
This doesn't seem huge to fix, but I don't know a lot about key maps...

A rather dominating part of the discussion has been color management
(or the current lack thereof).
* https://discussion.fedoraproject.org/t/89794/12
* https://discuss.kde.org/t/fedora-kde-40-plans-to-completely-drop-x11/5047
* https://invent.kde.org/plasma/kwin/-/issues/11
This one seems to have been dragging on upstream in wayland-protocols
for years now. Could we consider shipping the draft as a kde
namespaced protocol (similar to what the Chrome OS folks did for
aura-shell) and migrating to the finalized version later?
(As a sidebar, I'm extremely disappointed in how poorly
wayland-protocols governance is going right now. I count seven
wayland-protocols proposed by folks I know are from KDE that are in
varying states of being stuck, with all but three 6+ months old and in
varying levels of decay. This is seriously hampering the development
of Plasma Wayland from my point of view. And it's not just protocols
from KDE that benefit KDE. Even ones from GNOME developers that we
want are in similar ruts.)

The lack of functioning support for host-guest clipboard copy-paste in
Plasma Wayland with SPICE was also brought up as a problem. Not just
for regular virtualization use, but also because it hampers testing
workflows.
* https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AERH56JOMVKMNJA6MDKCFFC7DKGIRV53/
* https://bugzilla.redhat.com/show_bug.cgi?id=2016563
* https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26
I am not sure what should be done here, but it clearly kind of sucks
to have this problem. It's not currently on our list of Plasma Wayland
"Showstoppers", maybe it should be listed there?

Semi-related but not necessarily in the land of KDE, I got feedback on
the Fediverse about the lack of a method for pre-authorizing
applications to access portals means that certain classes of
applications are functionally impossible to use in a Wayland
environment. The example I was given was Veyon, which allows teachers
to control school computer labs and monitor them while they're in use.
This is a much more interesting variation of the automatic headless
remote integration case for IT support systems software.
* https://mastodon.tedomum.net/@lebout2canap/111074670912414830
* https://github.com/flatpak/xdg-desktop-portal/issues/1105
This is probably a solution that needs to be handled at the
xdg-desktop-portal level, but I wanted to highlight it here for
everyone.

So you might think that with this list that it's all bad news, but
it's not! The good news is that most of these were already captured on
our Showstoppers list[4], which means we already had a good idea. This
may help us refine this further to focus on what people say they need
for the Plasma Wayland experience.

As I said earlier, I don't necessarily have the answers here, but I
hope this can help us get some focus around knocking down issues for
Plasma 6.

[1]: https://fedoraproject.org/wiki/Changes/KDE_Plasma_6
[2]: https://dot.kde.org/2022/10/16/akademy-2022-weekend-kde-talks-panels-and-presentations
[3]: https://dot.kde.org/2023/07/25/akademy-2023-how-it-happened
[4]: https://community.kde.org/Plasma/Wayland_Showstoppers


--
真実はいつも一つ!/ Always, there's only one truth!


More information about the kde-devel mailing list