Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

181–190 of 392 posts

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

#181
post #45

Earlier quoted context omitted.

When I upgraded from Debian 12 to 13 on my personal laptop running KDE, I knew that the switch from X11 to Wayland would happen and was braced for all kinds of issues, like every other time I tried to switch to Wayland in previous years. 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.…

For the records, Debian 13 Gnome with Wayland works as well as with X11. The only reason I'm still using X11 is that backlight control doesn't work anymore with my old laptop (it did with Debian 11) and X11 can work around it with gamma correction and Wayland can not.

KWin can do dimming in hardware or by messing with the colors - not sure how.

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

#182

Slight tangent but has anyone moved from AwesomeWM to a Wayland-based tiling WM? Interested to hear what people chose. I tried Sway for a bit and while it's not bad by any means it's a bit too unlike what I'm used to. SomeWM is an attempt at "porting" AwesomeWM to Wayland and looks very promising but not quite there yet (I couldn't get Vicious widgets working and not sure if supporting them is even a goal). I'm still…

(one of AwesomeWM core dev here)

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.

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

#183
post #45
post #2

I think the KDE developers in particular have done a great job of pushing Wayland forward and getting features that people want and need added as new protocols. KDE feels a lot smoother and more responsive when using Wayland than when using X11, and by this point most stuff has been updated to work properly on Wayland so I don't notice any breakage or missing features in day-to-day usage. > Moving forward with a sing…

When I upgraded from Debian 12 to 13 on my personal laptop running KDE, I knew that the switch from X11 to Wayland would happen and was braced for all kinds of issues, like every other time I tried to switch to Wayland in previous years. 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.…

I recently installed Kubuntu 26.XX on my desktop, was worried about having to use workarounds and giving up on fractional scaling to use it with my NVIDIA gpus (previously had to do this), but was also pretty surprised that it has been smooth sailing.

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

#184
post #106

Earlier quoted context omitted.

On the other hand, I recently installed a system with debian 13, and it was really easy to distinguish between X11 and wayland sessions: if the session displays a plasma desktop, it's X11, if it crashes on login, it is wayland. YMMV if you try to switch to wayland.

What did you learn when you checked the logs to see what was wrong?

Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!

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

#185

Earlier quoted context omitted.

I don't really like Systemd neither - but Wayland and Systemd are pretty much opposites of each other. Systemd does (too) many things, many of them badly. Wayland does well what it does, but it (still!) does too little. Wayland is adding features and is pretty close to doing "everything necessary". Systemd keeps accreting worse replacements for existing services.

They're similar in that they're both new things that are worse than what they're meant to replace.

They are actually both much better than the things they replace, but a bunch of whiner babies can't stand the thought of anything changing and will claw and scream while being dragged into the future.

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

#187

Plasma/Wayland Known Significant Issues[1] 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 ap…

Pointer warp not generally supported so CAD programs fail in bizarre ways.

Although I think that there is FINALLY an actual spec for pointer warp. However, very few compositors support it.

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

#188

Trinity Desktop supports X11. If you liked KDE3.5 you might like Trinity. Good bye KDE. Good bye Red Hat. We're doin our own thang now.

Sorry to be dense. What does this have to do with Red Hat?

redhat, the NWO funders of many projects under the guise of freedom

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

#189
post #88

Earlier quoted context omitted.

I've paid for Talon beta access for years. I'm a heavy Talon+Cursorless user, and I'm dreading this move by KDE. 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…

I also think it's unfortunate that Talon is closed source. You see this even in the support practices adopted, where all support is routed through a slack chatroom which doesn't let you view history older than I want to say a few months but might be wrong on the length of time. The author seems to want to force all support requests to go directly through him, presumably because it increases his income if he can creat…

Hi, I'm the developer of Talon.

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.

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

#190

As someone who shipped my fair share of critical production features, I find this plan raising my eyebrows somewhat. Disabling a feature AND simultaneously removing the codebase for that feature almost never ends well. There will always be some use cases that people haven't thought of. In serious projects (read, your career is at stake) a much better strategy is to first make the feature unavailable by normal means w…

> a much better strategy is to first make the feature unavailable by normal means 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…

I was not aware of that and literally read into this particular article. Thanks for clarifying!
Post reply on HN