It was only a matter of time but it's nearly upon us - KDE Plasma with version 6.8 will be entirely dropping the X11 session to go full Wayland.
For a lot of users it won't make much of a difference, according to the blog post announcement as the "vast majority of our users are already using the Wayland session". With this change they said it "opens up new opportunities for features, optimizations, and speed of development". Not surprising, since developing for and maintaining the Plasma desktop across two very different protocols can't be easy. At least they'll end up with more focused development.
So with this move support for all X11 applications will be "fully entrusted to Xwayland".
In the FAQ they mentioned the current Plasma X11 session will be supported still into early 2027, no exact timing as of yet though. If you really need X11, they're suggesting sticking to a long term support (LTS) distribution that ships older Plasma. If you are using X11 and sticking with it a while, the good news is that KDE applications will continue to run on X11. They're only dropping support specifically for the Plasma desktop itself.
There's still some significant issues they need to address though, which they're gradually working through to ensure Plasma on Wayland is truly good for everyone.
We're finally properly close to the year of Wayland on the desktop.
These are two sore points of still incomplete feature parity with X11.
Yes, there are workarounds. Yes, the old ways were insecure by design. Yes, it's damn hard to provide these features to unmaintained software that expects stuff to work in a certain way.
But removing used/useful features is not exactly progress, no matter in name of what is being done.
Quoting: syylkWayland needs a secure and backward compatible (which, unfortunately, rules out secure) way to manage global shortcuts and keypresses and viewport/video memory sharing.
These are two sore points of still incomplete feature parity with X11.
Yes, there are workarounds. Yes, the old ways were insecure by design. Yes, it's damn hard to provide these features to unmaintained software that expects stuff to work in a certain way.
But removing used/useful features is not exactly progress, no matter in name of what is being done.
I feel like there are so many ways to do this that could be fully backwards compatible.
The way KDE is mostly handling it right now is that XWayland apps can just fully listen to everything if you allow it, just like they could on X11.
No app changes necessary.
This could go further... give me a dashboard for the portal that allows me to pick specific apps. Discord can listen to all my keypresses, so i can use PTT. Now discord doesnt have to know if its in focus, or change any code to request anything, It just needs to know "when I see the keybind, i respond". No app changes necesary.
Then they could make that dashboard allow specific keys to pass to specific apps. Now instead of passing all my keys to discord, only my PTT key needs to go. Again, they dont need to know that they arent seeing global keypresses, they just need to know to respond to the keybind, which they will see without understanding why. No app changes necessary. Still fully backwards compatible.
And then all apps need is some sort of way to interact with this dashboard, so users don't need to go to a KDE dashboard to configure discord (or OBS, or etc), the app can say "oh my PTT keybind is now X, and I see the user is on wayland, I should make sure X is a keybind I can see globally"
And then taking it _even further_ it would be neat to allow the sharing to not be global. "This app overlay can only listen to my keybinds when the app it is an overlay for is focused." Steam gets around this by being the one who launches the game as a child process, so it can listen to the game keybinds in its overlay, but I have other apps that have 3rd party overlays that I _want_ to allow to listen to my keypresses when Im using the app, but not globally.
I believe for the most part, these things are sort of what KDE is currently doing... It has a way of requesting global shortcuts, which it adds to its global keybinds (the keybind for X becomes "send keystroke X to specified app"). However in my experience in the past, global DE keybinds tend to consume the keybind. If I want "control" to be my PTT button, I dont want discord to consume all control keypresses. I want discord to see control being pressed, but I dont want it to be THE control handler.
The whole interface is currently a bit clunky. But it at least works. I had an app surprise me by popping up the KDE portal requesting a global keybind map. I can find these in the KDE `System Settings > Keyboard > Shortcuts > System Services > org.chromium.Chromium` config (the app that prompted me to set things up was an electron app).




How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck