Preparing for KDE Plasma's Last X11-Supported Release
blog.davidedmundson.co.uk
blog.davidedmundson.co.uk
It describes the regression in accessibility software for Linux from x11 to Wayland. Unfortunately, judging by the pace of protocols being accepted, I think we're years out from having a solution.
The most notable thing not working is Talon, which is a voice input system that lets you insert speech to text, manipulate windows, call scripts, etc, all via voice. It's software that works on Windows, MacOS, and x11, but not Wayland.
I think unfortunately right now the best bet is to, if you need the software, stick with X11 for as long as possible. An environment like i3 will probably be maintained for decades to come. Alternatively it might make sense to build some type of bespoke solution on top of a specific wayland stack, like re implementing what you get of talon in a kde plugin or via sway IPC. This seems viable to me but an incredible amount of work.
For people that need this, having to be a developer and build your own tooling in order to use your computer... it's not a future of Linux I'm particularly excited about. I don't want to leave people who need accessibility software behind, and I don't think any security justifications are actually real roadblocks which would prevent being able to serve these people. We have a coordination problem. It's less of a technical issue and more of an issue of getting people to agree on protocols which would let software like Talon work against the entire ecosystem.
I am happy the ecosystem is moving to Wayland, I think we're going end up in a better place. Wayland does solve some real problems for me (x11 screen tearing / frame pacing issues on Nvidia). I'm happy that KDE exists, it's great software.
Ultimately I think this mostly confirms the danger of using closed source software (Talon). I have some personal accessibility tooling that works just fine on Wayland. It's KDE specific but it really wasn't hard to get working. And uinput works on a level below the compositor, so X11/Wayland are irrelevant.
My stuff is written in Rust, just like Talon. I'm sure it would take me an afternoon or less to copy it over to Talon... but the dev just isn't interested. I don't know why he's so dramatic about Wayland when there are people actively trying to help contribute. If you try to talk about Wayland on the official Slack, there's an autoresponder telling you to shut up about it. If this were open source, I or someone could just fork it and move on with my life.
Now I'm sure I could use Ghidra and hack the binary to add support, but I'm not excited about becoming dependent on software where the developer is actively hostile to my interests. It reminds me of the blog post from yesterday about the guy who hates his insulin pump. I'm still a Talon user but I hate it now.
I guess I'll be forced to move to XFCE soon? Where is everyone else moving to?
He's created an incredible piece of software, and that's entirely within his prerogative to do this, especially because him being able to work on it full time leads to more work going into the system. He's made the world a better place so I'm not trying to criticize too harshly. But it's also super unfortunate right, because now if I run into an issue with Talon I am unlikely to find a search result of someone else who has solved it, but rather I have to interact with the creator of the software in a silo'd manner that will not be useful to anyone else other than me.
Tthreatening to remove x11 support entirely (as the article alleges) is also unhinged, yes. We're in a situation in which the best accessibility software is being threatened to be removed from a working platform because the author is (justifiably) frustrated with support requests that he cannot fix because of the transition to Wayland.
I expect that sooner or later we're going to get a better solution to accessibility than Talon, I'm not sure exactly how but probably using local LLM's in a heavy way.
It's possible to do the simple compositor specific hacks from Talon's scripting system to give yourself partial Wayland support at roughly the quality I'd be able to provide myself, and I know of a couple efforts to do this.
The tentative plan for "dropping support for X11" is just to do one more public Linux X11 release, stop there, leave it available to download, and make it very clear what to expect when you download for Linux or run on Wayland. I plan to continue supporting X11 on the paid version indefinitely.
Most requests relating to Wayland on the Slack have not been offers to help, and way too many have ended up being unpleasant conversations.
I have a standing offer to reconsider my stance if someone can show the vast majority of the necessary APIs are available and well supported without compositor specific hacks.
For some of the other points above, consider me disappointed but not surprised.
If slack interactions are so unpleasant, why do you direct all support through it?
Is there no way you could say "yes this is a hack, but we'll live with it for now until an actually good solution is available"? Maybe it could be added in such a way that it's easy to remove later (abstraction, encapsulation)?
> You're not interested in addressing customers' needs
I would love to support Wayland, but it is my position that it is impossible to "support Wayland" for Talon. I can only support a subset of the features and only on specific compositors, and it would be a lot of work.
> or giving them ways to address their needs themselves
As I said at the top of the message you are replying to, I believe today users already have the tools to address their needs themselves with about the same level of jank I'd be able to provide on Wayland. If this is a veiled hard line on open source being the only way for users to address their needs themselves, we have a philosophical difference that won't be sorted out in this thread.
> If slack interactions are so unpleasant, why do you direct all support through it?
That's a whole new sentence. I was specifically referring to the support requests for Wayland, which in the long tail have been more hostile toward me than is likely warranted.
> "yes this is a hack, but we'll live with it for now until an actually good solution is available"
The hack is switching to X11, which is fully supported, or working around it in your user scripts, which has already been done by some users for their specific environment.
He provided a working version for Linux, he will continue to provide a version for Linux.
Wayland is deliberately sabotaging the Linux desktop by forcing it's way in, developers have their own time and schedule and do not appreciate being forced to throw out working code just because others want to reinvent the wheel. If Wayland did it right they had proper backward compatibility and none of this breakage would happen
Quote:
>As a community, gather together, and successfully implement the entire API surface needed for Talon on GNOME, KDE, and wlroots,
Can you help find where we can work out this list?
An all or nothing probably isn’t going to work, but we can chip away at this.
There are definitely people who want to help.
I think that is the only way forward. There is no "Linux desktop". There is KDE, Gnome etc. and if you want to do "system utilities" you have to target one of those.
Yes, that's a slow, annoying process, but doing something bespoke means either you do the same work over and over for every compositor, or you only support one or two compositors. Neither of those is a good result.
...and I'm saying that as a person who likes X11.
No ability to save and restore positions of native Wayland windows
Real-fake-session-restored apps don't remember which virtual desktop their windows were on
No full-screen aspect ratio correction
"Spare Layouts" feature not implemented
"Per-application Keyboard Layout" does not work
No way to change the gamma or manually adjust the colors without generating or finding an appropriate ICC profile
Can't switch between multiple touch strip modes
No headless RDP
Opening files using command-line binaries in Konsole doesn't raise existing windows
Global Menu is not supported for non-Qt apps
Some apps' non-maximizable windows are broken with placement policy set as maximized
[1] https://community.kde.org/Plasma/Wayland_Known_Significant_I...
Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt.
+1 on the gamma controls
I suspect that is not KDE's fault (or Wayland's) - it's probably PAM, which by default has a 2 second delay (+/- 50%). That default is extremely difficult to change, but you can configure it. See my instructions here: https://github.com/linux-pam/linux-pam/issues/778#issuecomme...
Also if you follow that issue you can see I've been trying to convince the PAM developers to fix it (by changing it to a 0.5 second delay, which is much more tolerable and no less secure). Unfortunately they have this weird idea that users want the delay, because it lets them recompose their thoughts after getting the password wrong or something like that.
There's such thing as bad defaults and starting too heavy-handed is starting with bad defaults.
In short, current default is a good compromise and a good default.
Although I think that there is FINALLY an actual spec for pointer warp. However, very few compositors support it.
And I rarely get it to recognize all my monitors first try. And it crashes semi-regularly.
Not sure how much is inherent to Wayland vs Gnome, but life is way better since I upgraded to Xlibre & Cinnamon.
I recommend Vicinae. https://docs.vicinae.com/clipboard
When I used GNOME, the Clipboard Indicator extension [1] served me well.
[1] https://extensions.gnome.org/extension/779/clipboard-indicat...
https://github.com/keepassxreboot/keepassxc/issues/2281
Though it looks like there's a recent PR for that:
Not saying that X11 is not broken and should not be replaced, but many Wayland's decisions harm user experience more than X11.
Does it require a little more knowledge on the part of the user? Yes, but it's worth it because with that knowledge comes power.
1. Right click PIP window 2. More Actions -> Configure special window settings 3. Add property -> Layer Force Popup
After this it spawned always in middle, I also added property Position Remember, so it spawns where it was previously. I have no idea if this is the best way to fix but worked for me.
1. Right click the PIP window and then click "More Actions-> Special Window Settings".
2. On the window that pops up, click "Add Property", and add "Window title". Change the drop-down from "Unimportant" to "Exact match" (this works on Firefox because the window title is always "Picture-in-Picture", you might have to do something slightly different on Chrome if it does something different).
3. Click "Add Property" again, add "Keep above other windows", change the drop-down to "Force", and change the radio button to "Yes".
4. From now on, all PIP windows will show up on top of other windows.
It would definitely be nicer if there was some sort of "always on top" permission that applications could request, but it's not too bad.
All that for _one_ feature which works out-of-the-box with Xorg, and which Wayland removed for security reasons. From what I've seen, sharing the screen is another common feature which was broken with Wayland and is still painful.
I don't think Wayland's security model is very relevant to me since I have faith in Debian for filtering out rogue applications. So I have to reason to drop my smooth UX for a world of "not too bad" workarounds.
What are you talking about? It's very convenient when I watch video while I do some work or entertaining thing on other web page or app. It's fine if you don't want to use it but many people do.
And to make it ergonomic I scripted kwin and set some shortcuts.
So yes, you can have any window PiP the way you like. But it requires you to do a long sequence of actions. Versus a single click for very specific PiP behavior.
Consider a window in a web browser tab. You could click the PiP button, which will pop out a tiny window, most likely already in a corner of the screen. This window is a mini video player. Your original browser tab stays untoucher, still at the same place in your web browser tab list, the rest of the tab still readable and scrollable etc etc.
Or, you could clone the tab. Move it to its own window. Locate the video. Put it in full screen. Un-fullscreen the window. Click on the pin button. Resize the window to the corner.
Same result, but not the same effort.
User behaviour is the only _real_ thing, it happens. Everything else is in your head. If people in the real world use PiP, then it should happen. The programming model has to bend and change to support it. It simply does not matter if the window manager does something or the window does something.
Sure, there is always the security argument wayland folks fall back to. But what ever is the problem with making a one-time permission popup? "Google Chrome wants to open in PiP: allow | allow once.". Just expose the existing PiP code in the window manager as an API guarded with an `if` that apps can call. It's not even that much real work, just pure bikeshedding and architecture astronauting.
How the heck can the window manager do it?
I cannot comprehend the way wayland folks think... quote from the xdg-pip discussion:
> To not make PiP windows effectively "always on top" and "on every workspace" dialogs - a terrible and sadly by applications used concept on X11 - PiP windows must be input-only, i.e. not receive keyboard, pointer and touch input
Like what the heck even? That is how pip windows are expected to work? And of course you want inputs on them? e.g to mute/unmute on a video call? Like these are use cases used daily by people. And its "terrible".
As many buttons as he thinks he needs, and as a compromise they can be disabled by default and enabled through settings. Instead your ilk will probably remove even those remaining buttons and replace them with some obscure movement command
I have a pretty strong oppinion that GUI basics must be simple but more advanced stuff (e.g. tools that trainee professionals spend most of their workday in) must not hide its raw power because the user can be expected to learn.
User interface essentials have to be understandable without mental gymnastics by default without appearing overwhelming. The overwhelming majority of computer users don't change defaults on most software and a shockingly big number of computer users deal with them only because they must, not because they derive joy from it. They don't engage deeply with these devices at all. So those defaults must be picked carefully to keep the UI approachable. This isn't the same as ripping out features or antagonizing power users that do bother to learn.
using the titlebar for moving a window is extremely backwards and productivity killer.
that being said, I agree with you, and I think its an outright abomination to put the tabs in the titlebar, and its disgusting how crome and firefox by default removes the real titlebar
in either case, that appears to be the very extreme minority of cases you have to move a window
It also allows you to use it with win-drag of course.
Ultimately, the screen is just an unbroken flat surface and windows are just a software level abstraction that has been tortured beyond hope and one that users shouldn't have to micromanage or understand deeply.
If an application needs something to appear at a specific spot in a specific way, the display manager needs to bend over backwards to make it happen or it's broken. Windows understands it. MacOS understands it. X11 understand it, but the community is working hard to throw that wisdom away.
Making a decision on the user's behalf doesn't sound very free to me.
Sorry but all I can say to that is: lol
As for security, it's easy/possible to cut holes into a solid wall. But if your whole system is swiss cheese, you can't plug all of them in. Wayland is a solid wall where protocols are the means to cut new holes. Sure, protocol development is slow (at least their acceptance), but this is the proper way to do it.
And even if you have faith in your applications, do you also have faith in your data? Because it's a mostly C/c++ application set, one vulnerability is enough to make them malicious. And with the beautifully engineered default "GNU/Linux" userspace security model, the only thing a random script can't do on your machine is install a new video card driver. But everything else is under the same user and readily accessible with full network access.
I much prefer the latter, especially since I get the choice.
I'm guessing this would mess up other games as well, like multi-screen flight simulators or driving games. It would be really nice if user-trusted apps could be granted permissions on an app-by-app basis to allow absolute placement of windows for these cases instead of making us jump through hoops.
Makes me mad.
I want application to know the screens, send windows to know positions etc etc. And this is now compositor specific. So some applications will know how to talk to the kde compositor to share the screen, or place a window at a specific position (very useful for so many things).
Alternately, if it's using layer-shell windows, those can also be pinned to a specific output.
If it's not layer-shell, and the windows aren't fullscreen, then yes... it's annoying. The xdg-session-management protocol will likely fix that in this particular case (at the expense of having to manually place the windows in the right places once, and then it can remember in the future), but that protocol has just recently been stabilized and of course no one supports it yet.
It's all so frustrating watching the Wayland folks reinvent everything, poorly, and after more than 10 years it's still not there yet.
The whole project started in 2008, so almost 18 years.
If the logic is that it's the window manager's job to set window rules for this, fine, but in that case Plasma should probably ship with preconfigured rules matching the Chrome/Firefox PiP window.
I also find the lack of an Xlib-compatible macro API disruptive but I usually run an X11 session inside Xvnc for this purpose anyway.
Wayland doesn't allow apps to force themselves to be always on top. I would argue that it is up to the window manager to provide this functionality at the discretion of the user. Kwin does this.
It still lacks keyboard LED control, so unprivileged X11 programs that use the Scroll Lock light as an indicator cannot be ported to Wayland.
This Plasma change is going to be painful for me. I wonder if there's an up-to-date list of Wayland shortcomings.
I didn't know such apps existed! What do they use it for?
Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequences.
Others surely exist, since hardware lights can indicate just about anything, and are especially valuable where visibility is important. Even shell scripts can use them on X11, via the xset command.
probably also exists other tools to do it. this is then generic linux LED framework
Moreover, granting permissions on the sysfs nodes won't distinguish between a user who is logged in to the current virtual console and one who is not. Wayland correctly delegates keyboard ownership to compositors, but they have no way to expose the keyboard's outputs (the LEDs) because Wayland hasn't yet defined a protocol for doing so.
X11 has a protocol for this, and X servers handle it just fine. They account for different users and LED states on each virtual console, and do not require clients to have any special permissions. It's an area where Wayland fails to be a suitable replacement.
Are you sure that windows that, without your consent, are allowed to stay on top and grab your input are a good idea? And spawned by Chrome? As if we hadn't already enough ad-ware, click-harvesters, and spoofed dialogs popping up everywhere!
I know there is a couple of legitimate uses for this, but the ways it can be abused are vastly more.
I think the sensitive default should be to block it, and allowing it should be behind some user's conscious action. Yes, it adds some friction to some workflows and it takes a bit to get accustomed to. But it doesn't deserve the label "security paranoia".
It's that Wayland's design, implementation, their attitude, and everything else about it is terrible. It could have been implemented without compromising on features or convenience by explicitly specifying minimalistic controlled side channels in their security model from the start, instead of shifting it onto ad-hoc implementations. And of course the windowing system is already too large of an attack surface. Many people are thinking about going full Qubes due to the current realities, while the others live in denial and call even window isolation "paranoia". Fascinating.
Apple apologists keep making the excuse that Apple has to provide no side loading because if there was any single way to do it, all scammers would be making all grandmas do that. They're correct.
I use Wayland and it has a "stay on top" option for windows.
> Moving forward with a single code path going through Wayland is going to allow us to bring new performance improvements, memory optimisations, and brand new exciting features throughout Plasma.
I think the blog post would have been better if he had some specific examples in mind that he could have shared here.
Instead, I could tell literally no difference. Multiple desktops works fine, scaling works fine, screen capture works fine, old apps work fine, literally everything works just fine.
Good job, KDE team.
in all other cases other than gaming and recording, Wayland has been a delight.
I could run the game on the GPU and leave more CPU for the desktop and encoder, maybe I'd be able to record and play on Wayland that way, but there's some additional drawing latency if I run the game on the GPU, the frame buffer gets sent back to the CPU before it's drawn on the display anyways.
As it's rhythm games I mainly play (ITGmania, Stepmania fork), the additional latency for getting the picture out on the display it's not really working out great for me.
For example I was a big user of devilspie for placing windows in certain locations, on certain desktops, marking windows as sticky, or marking them as different types of windows.
I am still a heavy user of pidgin (I know I know but I’ve even written my own protocols for it). I really liked being able to place it in a certain position as a certain size, mark it as sticky, put it below anll windows, and mark the buddy list as a utility window. This places in the background, removed borders, and doesn’t include it in alt-tab or window list when you do the expose type of thing. Then I had a global key binding to bring it to the front of all windows or drop it back of all windows.
As far as I know, none of these paradigms even exist in Wayland and I’ve had to deal with less useful options or completely change my interactions which is unfortunate.
This is Linux desktop, like if you have never had a black screen before then I'm not sure what you expect. One culprit could actually be the home .config/.cache folders that have all kind of sh*t accumulated (like why do we still do it this way? It's horrible), so I usually rename them and try again to see if this is the problem behind the scenes.
This specifically isn't the biggest issue for me right now because I use this machine mainly over ssh, but if I eventually can't do x-forwarding, RDP, or log in manually without finding some fix, that's a lot of extra work and lost functionality.
Honestly everything just worked, but using it made me so nauseous. There was some latency somewhere, never figured it out. Running Cinnamon on X11 now. I did read some suggestions to improve latency but I have PTSD so it's going to take a while before I try Wayland again.
This is with multiple monitors on Nvidia’s, all of which support vsync. Disabling that did help, but why would I want to?
Wayland, currently, is butter smooth.
Both KDE and GNOME seem to run very smoothly on Wayland.
Unless you have proprietary X server blobs, you have mostly the same low level route in either case to display stuff, so it's on the exact compositor you have tried, not on the wayland protocol.
I don't remember why gamma correction didn't work for me Wayland but I'll give it another try next year, maybe it got fixed by then. X11 is working perfectly well and it always did for me.
Or, the X11 code is more complex and they prefer Wayland because it is simpler. Fewer features. Is it a surprise that wayland would be faster, if it does less?
> by this point most stuff has been updated to work properly on Wayland
Really? Strange how comments on reddit do not confirm this. Admittedly they did fix various issues. I don't see how this equates KDE on wayland being better than KDE on xorg - even more so as they abandoned xorg now, as that blog post shows. So how can this even be compared?
> I don't notice any breakage or missing features in day-to-day usage
Why is this contradicting what others report then?
> I think the blog post would have been better if he had some specific examples in mind that he could have shared here.
David and Nate are all about marketing buzz. I am hardly the only one to have noticed this already. Then again if you are too critical of them on reddit, you get banned. I found that out when I critisized Nate's obsession with money. :)
Though, I am hardly the first with that either:
https://jriddell.org/2025/09/14/adios-chicos-25-years-of-kde...
Edit: Interesting, the above URL no longer works. Guess jriddell took down his old criticism some weeks ago. Anyone able to show how the old content looked like?
Edit2: Hah, found it - wayback machine is so great; people would have thought I made the above URL in error, but here is the old content from last year:
https://web.archive.org/web/20250917012150/https://jriddell....
That is because people who don't have a problem don't think about this and so don't comment. Many wayland users don't know. I think I switched this machine I'm using now to wayland a while ago but I don't remember, and maybe it switched back in an update and I didn't notice (which is the point, I know I switched at some point and I couldn't tell the difference - which is how it should be)
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
I use it on a touchscreen and the on-screen-keyboard crashes several times a day.
I would not say it's fully ready.
In serious projects (read, your career is at stake) a much better strategy is to first make the feature unavailable by normal means while still allowing a workaround (in this case, for example, PLM could remove X11 option from the menu but still allow X11 sessions when some magic environment variable is set.) That would give people an easy way to get the old functionality if something is critically impaired for them. And only then, once we are confident that no massive unforeseen issue has surfaced, can the codebase be removed.
They started doing that in early 2024 with the release of KDE 6.0 by enabling KDE Wayland by default. The Wayland-only change won't happen til 6.8 which will be an early 2027 release.
https://pointieststick.com/2023/11/10/this-week-in-kde-wayla...
> And only then, once we are confident that no massive unforeseen issue has surfaced, can the codebase be removed.
Yes, that's the current step they'll be at with 6.8.
If it's a SaaS API or a web application, the developers can look at access logs or analytics to determine what endpoints and features are being used, and when users need to go back to the deprecated interfaces to get what they want.
There's no way for a KDE developer to learn "$NUMBER users went back to X11 because $FEATURE is missing in the Wayland version".
(Of course they can ask their users, or hope that users file issues on the bug tracker, but things will definitely fall through the cracks via these imperfect communication channels.)
I'll be sad if that is still the case when 6.8 rolls around as then I'll be hunting for another DE.
What is a compositor - thing that actually draws window content on the screen? Whatever KDE provides?
Edit: To be fair to KDE/Wayland, the Wayland Kubuntu 24.04 experience was vastly improved over Kubuntu 22.04.
The only issue that I noticed it's with screen scaling doing weird things with OpenOffice.
A quick search (in which I found no evidence of heated controversy) suggests to me that it's the first one.
Why is it a warning sign? Sounds very useful to keep X11 support for machines that have no good video acceleration like office computers or stuff relying on VNC protocols.
I suppose you're from the " hop onto the bandwagon no questions asked crowd " then.
The risk in that in this age of AI-assisted bughunting, X11 security vulnerabilities are more numerous and as nasty as they've ever been. And that says a lot.
The solution would be either for Plasma to do something like River did [1] and separate compositing from window management, or for Plasma to make it possible to use Plasma widgets in other compositors. As it stands now I either have to make do with Krohnkite or go down the ricing rabbit hole with with River and Quickshell.
I went from ALSA to pipewire. I tried pulseaudio but it never worked decently.
- The nvidia binary driver is shit with Wayland
- The nvidia OSS driver does not support Pascal GPUs.
- Nouveau got a bunch of stability improvments in Linux 6.19, without which Wayland crashes roughly weekly.
You can get a stable system either by using the latest kernel+nouveau or:
MESA_LOADER_DRIVER_OVERRIDE=kms_swrast
I guess in a few years I'll need to patch it and carry my patches forever. Yay progress!
Yet another glowing endorsement for libinput.
At this point, it's simply a bit too late. I'm sure in the early days it was still a choice, but when you want prepackaged things, you get systemd.
There are some truly special people among Linux users that think diversity in init systems/libc implementations/etc is a good thing for a general-purpose desktop. They don't understand that people just want stuff to work, and developers don't want to support more than 1 init system (or other trivial thing) for their package.
Success of Linux on the desktop is fundamentally incompatible with diversity, but unfortunately not everyone gets that.
The vast majority of "server" distributions now use systemd as well.
But if you are using software that other people provided to you for free, I think the developers also get a say in how things work. And in case you didn't notice, most open source licenses will tell you that they don't provide any kind of warranty.
I wish they would have listed what some of those features might be.
The maintenance and performance stuff is good, but it’s not exactly end user stuff. Yeah you benefit but it’s less obvious.
I don’t follow this stuff closely so personally I have no idea what kind of Wayland only features could exist that couldn’t before.
Honestly my computer gave it a red underline so I decided to do that. I didn’t think about it harder than that.
If I recognized it like “colour” I wouldn’t have.
fulfill vs. fulfil
judgment vs. judgement
disk vs. disc (https://en.wiktionary.org/wiki/disk#Usage_notes)
hiccup vs. hiccough
diarrhea vs. diarrhoea
In British English "judgment" without the 'e' is generally only used for talking about judicial rulings, whereas most other uses of the word contain the 'e'.
Why? You were quoting text so it would never be confused for yours anyway.
And it completely misses the point. Yes, there’s a lightweight tool for everything, but the appeal of KDE is that I don’t need to know. It mostly just works, is extendable and configurable.
But i also understand the appeal of staying minimal. The thing is, i want some kind of middleground: I want a simple tiling window manager. But i also want to easily install and configure stuff without falling back to the command line.
Maybe it's also brain damage of using too much Windows (with wsl). But there I have a different problem: It's easy to install and configure stuff, but it's everything else than minimal.
I can see the appeal of KDE - I just got fed up of things breaking when I did mandatory upgrades for security. I don't have to choose between stability and security. After 10+ years, I would find it harder to go pecking through menus for what I need when I can just type it.
You could make your own tiny Windows 'distro' building on Tiny 11.
Meanwhile there is a slightly larger minority that need things that cannot be done in X.
For the vast majority of people they cannot tell the difference, either works just fine. If there are issues they are tiny things they don't notice until somebody points it out - and then they forget in a few days.
I had just finished reading the link in the first post and, frankly, I'm grateful for.the insight it gives. I think we all should have more perspective than what we have around things that we take for granted. Wayland itself would be better if its own devs had done the same.
List of things that cannot be done in X:
Or really, give up on anything that might change behaviour, if you don't want to break back compat.
what about emulation / virtual machines?
They have their own custom compositor for handheld-mode, named gamescope. https://github.com/ValveSoftware/gamescope?tab=readme-ov-fil... XWayland based.
However, few days ago my non-technical girlfriend wanted to use my laptop, I couldn't see her using i3 so I decided to install Plasma, a proper desktop environment. Lo and behold I couldn't launch it. After searching I found out I needed plasma-x11-session as the default plasma install now included just a Wayland session. I found this a bit surprising, so I did further digging and discovered a huge chunk of Linux desktop community have basically migrated to Wayland since the last time I was here. Very surprising I must say.
So I decided to try Wayland again; I installed Sway and was pleasantly surprised. My screen resolution was automatically calibrated, operations seemed to run more smoothly, my laptop's fan kicked in less frequently (don't know why), and I didn't need a compositor package to fix screen tear (bye Picom). But all these weren't the reasons I decided to stick with Wayland. You see, in x11 I've been having a persistent problem: playing videos from certain websites, notably Twitter, introduces noticeable flickers. I tried everything to get rid of this: media drivers, verifying GPU acceleration, calibrating refresh rates, nothing worked. When I installed Sway I decided to see if this issue got magically fixed, and lo! It was. Wayland has come a long way since I last tried it. Now that I mentioned it, I have just remembered I need to figure out a way to share screens on Google meets, at the moment I seem to be limited to sharing just the Chrome window.
For now I can deal with that stuff but it looks like more I use wayland more issues I see so not sure that I will able stick with it long term.
oh now I also has flickers with discord app
only partially and both Sway and Hyperland still doesn't has official support yet.
this blog post explaining some issues https://michael.stapelberg.ch/posts/2026-01-04-wayland-sway-...
Here is a short setup guide on how to get it working rather nicely: https://thesaigoneer.bearblog.dev/freebsdkdeplasma6wayland/
Now the concept of a "working system" can be a bit hard to grasp for some people, so let me put it this way: There are vastly more things that normal people do on their computer that work on Linux than on BSDs.
Complete removal of X11 should be an event to trigger KDE 7.0.
Thus, that particular comment (https://lwn.net/Articles/555124/) was prophetic: "With that sort of attitude, I have no confidence that remote Wayland will ever work properly. Clearly Daniel just has a laptop and does all his work on it, and damn everyone who uses more than one machine for anything."
They showed the statistics based on their telemetry tools and said they match crash data.
Not that it was 100% from crashes.
Also the fact they can tell which one is in use does not mean that’s the reason it crashed. It could be crashes due to bad network handling or file corruption or something that has nothing to do with the GUI.
The ones that don't are more likely those who leave things on defaults, are involved with the project or a distro, or similar. No, I don't have anything that backs this up. The statistics they're using can never be accurate, by virtue of being free software that ships on privacy concious distros to privacy cincious people. There was a study that backs up this claim, but I'm not google.
OTOH, xfce is doing fine.
Security conscious doesn't mean not getting involved with the community and helping useful projects.
>For transparency, the one caveat in all of the above is that I've deliberately always focused on people using the latest Plasma release. We do still have a sizable chunk of users on X11 still using Plasma 5.27. Including them, the total Wayland adoption rate is about 76%.
Wonder how representative of the real end user population this is?
Dude…
That being said, on a different box with an older gen Nvidia card (3070) it defaulted to Wayland and just worked out of the box.
So, bit of a mixed bag. ;)
I'd love to be proven wrong about KDE's accessibility support. Hopefully they'll adopt GNOME's acccessibility extensions for wayland but that seems less likely than making their own that work with their compositor's design.
Can you clarify what you mean by this? In the process of KDE implementing Wayland support I also have seen several issues and blog posts dedicated to accessibility features. In fact, I am fairly sure I saw KDE explicitly funding accessibility development in relation Wayland a while ago.
I am using KDE with Wayland and just had a look in my settings and the Accessibility menu is there and the features in there also appear to be working. Including the screenreader which worked on all windows I had open at the time.
Which makes sense as none of that goes through the display server but rather a D-Bus protocol implemented by Qt and GTK as far as my understanding goes.
There is a bunch of stuff that came with X11 "for free" like access easier screen capture for magnifiers, input injection, etc but as far as my understanding goes KDE (just like GNOME) has been working on DE specific implementations of each.
I am not saying things are perfect right now as far as accessibility goes. I am not someone who depends on these features. I also know that things are in fact not perfect across the board and there is still work to be done. But the claim that there is no support for accessibility seems like a rather large hyperbole to me.
I'm sure accessibility is far from perfect, but in this case, I doubt that's true. KDE has a blind developer working on accessibility: https://mastodon.social/@acidiclight
>As a KWin developer and KDE's accessibility engineer... >https://nocoffei.com/?p=451 >This is a problem. We need to solve it. Fast.
And this is a quote from the page intro,
> As the Linux Desktop transitions to a Wayland-only future, I will be locked out of my computer, as the accessibility software I rely on is left behind. The desktop environment I use, KDE Plasma, has announced that in early 2027, X11 support will be removed from the system. That means in about roughly 9 months, I will no longer be welcome on that desktop environment, being forced to cling to an older version or switch to a more niche environment that still supports it.
The problems described therein haven't been fixed. And mclassen's (of gtk) comments on the fedora bug tracker make it clear that even if KDE tries to implement GNOME's new AccessKit it still won't solve the problems. mclassen seems to think the people asking for things like getting and setting cursor position are just sealioning "accessibility maximalists". The core idea of his argument argument is valid, you can't get it working all at once and progress is incremental. But if that's true then don't remove X11 support that works while the waylands are still progressing towards working.
What is with KDE and releasing broken software? What's the rush to release when there are known issues?
At some point it needed a custom interface and the ability to reconfigure itself on the fly.
Adding in a GUI was not a reasonable option.
We ended up writing a GUI (in gtk) then using Xembed to embed the other process and communicate via a Unix socket.
What would have been a major rewrite (and likely a port to a different language) ended up being a few a days project and worked beautifully.
It really showed me how powerful X11 really was.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
I'm still on AwesomeWM for now because I have no real reason to incur the pain of switching, but still curious to know what path others are taking.
Vicious is getting quite old. We put tons of effort in AwesomeWM to be perfectly backward compatible all the way back to the 3.5.0 API (ok, 4.0 had documented breaking changes, but still had compat code to minimize the porting work), like bug-compatible level using a **ton of `if` in the code. I really can't blame any effort to implement wayland to nuke that compat code mess when it blocks them. The older Vicious most people use is also using blocking code in the main thread, it it locks the entire WM when its calling a shell command. AwesomeWM had async APIs for that kind of stuff for a decade now. IMHO, using some LLM call to port the widget to use the declarative widget API, which AFAIK SomeWM supports, is probably worth it for performance alone, even if you keep using AwesomeWM.
Thanks for all your work on AwesomeWM - whether I keep using it or not it has been a great experience!
If anything it reminds me more of the experience with using awesome v2(before lua); you generate a config file for the base WM, and then build up external tooling to drive it how you see fit. The experience has been quite pleasant, but I do enjoy twiddling.
¹ https://codeberg.org/river/river
Edit: I just checked my dotfiles. Awesome went in on 2008-06-09, and river on 2024-06-30. Happy and largely uneventful two years on river.
I'll give it a look - thanks!
For example, it has pluggable layouts where instead of pulling in a lua module(such as awful.layout) in awesome you'll run an external process which handles events. You can even run multiple managers and switch between them with bindings, or write a custom one to scratch that itch. If you're happy with just awful's .suit.tile.right and .suit.max then basically any backend will do.
This is why it feels like a reasonable path off awesomewm to me. I always considered awesomewm to be the WMConstructionKit, and while river changes how you interact there is still a nice route to extensibility. The newer direction even more so than the -classic offshoot.
Technically, it is a goal, though perhaps an optimistic one.
I won't support vicious widgets in the 2.x releases, but I should definitely add support for it in the release/1.4 branch that follows AwesomeWM master/4.4. Not that I think vicious widgets are the best, but technically if it runs on AwesomeWM, I should support it in 1.4.
I created an issue (https://github.com/trip-zip/somewm/issues/599), even if you decide not to use SomeWM. Thanks for trying it out.
I think they recently added support at the KWin level for reopening windows to the right desktops etc but as far as each individual apps, it seems to be up to them individually to get this working again. I would have thought that at least for the KDE apps, they could just have a compatibility layer from the X11 session management to make it work but it doesn't seem there yet.
Just like on x11 for the overwhelming majority of applications it's implemented in and handled by the applications framework like GTK, QT, electron, ...
But I have to use wayland because I've got nvidia and the force composition vsync hack is just too slow to game with reliably.
Oldschool KDE devs were better. Today's generation of David or Nate, are just killing KDE off. But no worries, on their blog they'll continue how everything is great. It is so great that they need a donation-widget to keep on pestering people to donate. So now you can pay for them ruining the legacy here.
Modern KDE is nothing like that, and i cannot see how this is a bad thing.
Good bye KDE. Good bye Red Hat. We're doin our own thang now.
I guess one cares less about DE's when my DE is a front for a terminal and a VM (my browser).
It's sad to see sidelining of KOffice, Konqueror (of course still exists), Amarok and other great apps.
A desktop environemnt is not just a WM + Panel + Decorations.
KDE3.5x has is own... well everything tied together.
This reminds me of the systemd folks - they also don't allow for discussions yet alone cite anything related to their claims. They just claim. If the earth is flat, they don't need evidence. Their word must be enough.
It is this image:
http://blog.davidedmundson.co.uk/wp-content/uploads/2026/06/...
David claims "internal metrics", but he also does not explain how those metrics were gained, is there bias in how they were gained, which time span and so forth.
I am not saying he is fabricating the graph, though this could be the case too. What I am asking for is to show (ALL of) the data and explain the graph and data. Otherwise this is simple propaganda, with a pre-set goal to cover-my-ass (aka explain why KDE devs try to eradicate all xorg users).
By the way, next step, as you guys may know: systemd-only. Both David and Nate also announced this before. I wonder if there are financial kickbacks.
But at the same time it makes me a little sad. Part of the draw of Linux was being able to understand what was under the hood and how to bend it to your will.
I’m hope the community doesn’t lose sight of that in trying to gain new users.
People often talk about the year of Linux or what success is, and in my opinion, Linux had achieved success by 1996.
Trying to pull a casual user from windows or Mac OS is a worthy goal, but that shouldn’t be the end all be all metric.
In software rendering, CPU only updates screen when changes are detected. And the change completes as fast as the computer can. So that's minimal latency + minimal resource consumed.
If you're on a compositor, the 3D accelerator in your computer has to update the screen 60 times every second. It's even worse when you have a higher refresh rate display. And compositors update the buffer as soon as the previous buffer is pushed after the v-sync signal, and then it just waits until the next signal comes in. So there comes the terrible input delay. As a result, it comsumes more power and has higher latency.
So in conclusion, fuck Wayland, and I'm going with xfce without compositor.
KRdp on Plasma/Wayland is still much more fragile. It depends on a logged-in Plasma session, has rough edges around unattended access, session startup, reconnection, display sizing, authentication/cert handling, and general automation. Those are exactly the things cloud desktops and disposable VM images need to be boringly reliable.
I’m not against deprecating X11 long term, but deprecating it before KRdp is a solid replacement leaves server/VM/remote-desktop users in a bad spot, hopefully now the team can focus solely on Wayland, KRdp will receive some much needed love.
/s (maybe?)
Linux Gaming is now better than ever, and ideological Linux dev community torpedoes it hard with Wayland.
I mean who Linux wants to be anyway? An OS for bleeding edge hardware? I think we have Windows for that. Because Wayland doesn't even work correctly on average-aged hardware.
Greybeards have created Linux, and cool new generation will shut it down (on Desktop).