Preparing for KDE Plasma's Last X11-Supported Release • Hacker News Board

Re: Preparing for KDE Plasma's Last X11-Supported Release

#361

Post by aniou » Thu, Jun 04, 2026, 2:06 PM UTC

anaisbetts wrote: post #311

No headless RDP solution is pretty unforgiveable in 2026 - right now I use Nomachine and indeed it requires X11. Why wouldn't Wayland have a solution for this? It is not a niche usecase. It is like, a headline, completely mainstream use-case.

Blind spot that comes from incompetence and arrogance. See https://lwn.net/Articles/553415/ for example and remember famous words of Daniel Stone that brought the need for remote work to - merely - launch xeyes.

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."

Re: Preparing for KDE Plasma's Last X11-Supported Release

#362

Post by redeeman » Thu, Jun 04, 2026, 3:31 PM UTC

gmueckl wrote: post #300

thesuitonym wrote: post #291

Earlier quoted context omitted.

I don't know man, everybody is fine with putting tabs, and searchbars, and a bunch of other shit in the titlebar, but god forbid we put one button that's actually incredibly useful.

Try to move a browser window when you have 20+ tabs open. This is an incredibly bad UX.

alt + left mouse button anywhere in the window (maybe win button or something is default now).

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

Re: Preparing for KDE Plasma's Last X11-Supported Release

#363

Post by redeeman » Thu, Jun 04, 2026, 3:38 PM UTC

foresto wrote: post #176

senfiaj wrote: post #8

What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. If I had a lot of time I could list how Wayland breaks many applications. Not saying that X11…

My Wayland pet peeve: 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.

assign yourself permission to the device(may or may not happen by default depending on your distribution), and you can actuate it in /sys/class/leds/inputXX::scrolllock/brightness.

probably also exists other tools to do it. this is then generic linux LED framework

Re: Preparing for KDE Plasma's Last X11-Supported Release

#364

Post by redeeman » Thu, Jun 04, 2026, 3:39 PM UTC

ranger_danger wrote: post #193

jimmaswell wrote: post #133

Earlier quoted context omitted.

Isn't it also impossible to spawn a window in the last place it was open (or any arbitrary point) because you're not allowed to know or change where your window is by design? Nonsense like that makes me dread having to eventually use it.

They "fixed" that by implementing multiple conflicting and optional experimental extensions that may or may not randomly be supported by your particular WM/DE, and may or may not be DE-specific protocols in the first place. https://wayland.app/protocols/

are there really multiple confliction extensions? I thought they finally actually agreed on a protocol to do it?

Re: Preparing for KDE Plasma's Last X11-Supported Release

#365

Post by redeeman » Thu, Jun 04, 2026, 3:49 PM UTC

aniou wrote: post #361

anaisbetts wrote: post #311

No headless RDP solution is pretty unforgiveable in 2026 - right now I use Nomachine and indeed it requires X11. Why wouldn't Wayland have a solution for this? It is not a niche usecase. It is like, a headline, completely mainstream use-case.

Blind spot that comes from incompetence and arrogance. See https://lwn.net/Articles/553415/ for example and remember famous words of Daniel Stone that brought the need for remote work to - merely - launch xeyes. 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 lapto…

this take is ridiculous, of course remote wayland will work, there are still some things missing, which are gonna come shortly in KDE atleast.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#366

Post by redeeman » Thu, Jun 04, 2026, 3:49 PM UTC

brooke2k wrote: post #83

in my mind unfortunately this basically destroys KDE's viability as a gaming platform. SO many older games just do not work properly unless run under X11 (hell, some newer ones too). XWayland is good for everyday applications but for games in my experience it too often falls flat.

everything I have on steam works fine with xwayland

Re: Preparing for KDE Plasma's Last X11-Supported Release

#367

Post by foresto » Thu, Jun 04, 2026, 6:28 PM UTC

redeeman wrote: post #363

foresto wrote: post #176

Earlier quoted context omitted.

My Wayland pet peeve: 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.

assign yourself permission to the device(may or may not happen by default depending on your distribution), and you can actuate it in /sys/class/leds/inputXX::scrolllock/brightness. probably also exists other tools to do it. this is then generic linux LED framework

I am aware of sysfs LED controls. They don't solve this problem, because access to them requires privileges (or permissions assigned by someone with privileges). It's not reasonable to expect that, just as it's not reasonable to expect a sysadmin to grant users permission to the keyboard device node before they can type anything.

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.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#368

Post by redeeman » Thu, Jun 04, 2026, 9:34 PM UTC

account42 wrote: post #264

superkuh wrote: post #49

Earlier quoted context omitted.

And the statistics are only from the latest release, not over all KDE users. They mention this in the text but the disengenuous plot is what people see. >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 abou…

Yeah, and considering how KDE developers have been introducing bugs for X11 as their main strategy for Wayland to reach feature parity I expect many X11 users are holding out upgrades as long as possible.

can you provide ANYTHING to back up that claim?

Re: Preparing for KDE Plasma's Last X11-Supported Release

#369

Post by MarsIronPI » Thu, Jun 04, 2026, 9:46 PM UTC

tuna74 wrote: post #341

setopt wrote: post #328

Earlier quoted context omitted.

What do you refer to as system utilities? All the stuff now subsumed by SystemD?

Things like input methods, certain accessibility functions, screen savers and similar things.

Huh? Fcitx and IBus both worked on GNOME and KDE as far as I'm aware. Now, Fcitx using QT and IBus using GTK helps them feel more native on KDE and GNOME respectively, but they would both work.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#370

Post by MarsIronPI » Thu, Jun 04, 2026, 9:48 PM UTC

chadgpt3 wrote: post #317

bayindirh wrote: post #270

Earlier quoted context omitted.

X11 is not dying because of Wayland, it's dying because it became an unmaintainable code mountain over the years since it has been tried to be converted to something which is not designed for in the first place. ...and I'm saying that as a person who likes X11.

That's Xorg. X11 is dying because Xorg is dying and Xorg is dying because all its developers quit and went to Wayland. There's Xlibre too but it's a shitshow. Any one of us here could continue Xorg maintenance but we're not.

I think Phoenix[0] is a promising project: it's an X11 server written from the ground up, with security and legacy feature removal in mind. It's basically what Wayland should have been IMO. We didn't need a new protocol, at most we needed a new implementation of X11.

https://git.dec05eba.com/phoenix