https://youtu.be/Fm99TROo3LE
On Sat, Jan 17, 2026 at 2:35 PM Alberto Salvia Novella < [email protected]> wrote: > I believe that a bunch things criticized to Xorg are actually its greatest > strengths: > - A single code stack for all desktop environments. Standardization by > design. > - Separation of the mechanisms from the policies. Let the client decide. > - No isolation within components. Simple communication among them. > > > Following the same trend as Wayland, about the fork of SDDM, for deeper > integration at the expense of portability, I have to say that Zenned has > always avoided such integration. > > The very polished Zenned login screen > <https://gitlab.com/es20490446e/sddm-theme-dawn> is coded in pure QML, > and it only has the password prompt and two power buttons. Everything else, > like power indicators or notifications, is deemed useless in a screen which > is intended to be seen just a few seconds. > > > Coming back to Wayland, these are the reasons why currently Zenned hasn't > adopted it yet as the default session: > > The ugliest: Non-maximizable windows are broken with placement policy set > as maximized <https://bugs.kde.org/show_bug.cgi?id=499256>. Windows are > not decorated, and choppy when moved. > > Also X11 + Autocomposer <https://gitlab.com/es20490446e/autocomposer> has > noticeable lower latency than Wayland. It is specially noticeable with the > mouse cursor. It doesn't matter how much lightweight the window rendering > is, if the mouse movement is laggy or inconsistent. When gaming you > perceive full screen camera movements as laggy, even if the rendering has > decent latency. > > On Nvidia Optimus the mouse latency is only decent while installing Optimus > Manager <http://github.com/Askannz/optimus-manager>, which keeps the iGPU > at maximum clocks. Otherwise this bug > <https://bugs.kde.org/show_bug.cgi?id=513593> happens. > > I suspect these latency differences are not noticeable to most KDE > developers because they either don't have an NVIDIA GPU, a high polling > rate mouse, or a high frame-rate screen. But the three are currently > important for a quality gaming experience, and most gamers will gave them. > > Summarizing, from the current user perspective: why using Wayland, when > using X11 has lower more consistent latency on games? > > On Sat, Jan 17, 2026 at 2:00 PM Piotr H. Dabrowski <[email protected]> wrote: > >> Hi, >> >> > with Plasma 6.7 being the last version with X11 support >> > 6.7.7 2027-02-02 >> >> I think dropping support for an ACTUALLY WORKING, VERY STABLE, and >> BATTLE-TESTED environment like Xorg/XLibre in favor of a solution where >> even the underlying protocol design is still effectively in an alpha state, >> valid use cases are broken, and basic core features are still missing and >> still actively debated among developers, is pretty insane. Literally. >> >> I would like to hear a MERITORIOUS reply to these concerns: >> >> >> https://www.reddit.com/r/linux/comments/1pxectw/wayland_is_flawed_at_its_core_and_the_community/ >> >> >> https://www.semicomplete.com/blog/xdotool-and-exploring-wayland-fragmentation/ >> >> https://vas.neocities.org/wayland_shitware >> >> https://news.ycombinator.com/item?id=44301194 >> >> Namely: >> - no mouse-grabbing protocol; pointer-warp protocol is still broken >> (required by virtually every game) >> - screen sharing is still broken >> - color management is still broken >> - automation tools are broken (xdotool) >> - global hotkeys broken >> - accessibility features can’t be properly implemented >> - no sane capabilities system >> - no standard way to communicate with the window manager (like EWMH) >> - fragmentation hell: no DE is required to implement any protocol, no API >> can be considered reliable >> - every new feature requires a new protocol and multiple, DE-specific >> implementations, which will take years to become even remotely useful >> ...and much more. >> READ the actual articles; it's 10 minutes of work spent on actually >> listening to the community. >> >> Wayland is unusable for the majority of Linux users, based on the use >> cases described and the numerous comments above. >> Are you willing to take our voices into consideration, or will you >> continue to ignore us? >> >> Power-users, in particular, will be hurt by you ignoring our needs. KDE >> has always been the desktop environment that supported us. >> Do you remember "Simple by Default, Powerful when Needed"? With Wayland, >> it feels more like "Broken by Default, Powerful Never". >> >> I am fully in favor of replacing old X11 with something modern and >> better, but Wayland is either not that solution, or at the very least, it >> is not ready yet. >> >> That said, there should obviously be NO END DATE SCHEDULED FOR X11 >> SUPPORT. >> Maybe we can have this discussion again in 5 years or so, when Wayland is >> (hopefully) ready and actually usable. >> >> Once again: stop ignoring valid concerns and provide meritorious >> responses instead of avoiding the topic. Otherwise, this will end badly for >> the entire Linux community. >> >> Best Regards, >> Piotr H. Dabrowski >> >> >> >> Hi everyone, >>> >>> with Plasma 6.7 being the last version with X11 support [1] and the idea >>> that "6.7 would get support until 6.9 branches" (David Edmundson, [2] ), >>> I re-visited my proposed schedule and also created a draft schedule for >>> 6.8 and 6.9. >>> >>> This will be a bit of a longer e-mail, sorry, I'll try to keep it as >>> short as possible. >>> >>> +++++ [Plasma 6.7.] +++++ >>> 6.6.80 2026-04-30 >>> 6.6.90 2026-05-14 [Note1] >>> 6.6.91 2026-05-28 >>> TAR 2026-06-11 >>> 6.7.0 2026-06-16 >>> 6.7.1 2026-06-23 >>> 6.7.2 2026-06-30 >>> 6.7.3 2026-07-14 >>> 6.7.4 2026-08-04 >>> 6.7.5 2026-09-08 >>> 6.7.6 2026-11-10 [Note2] >>> 6.7.7 2027-02-02 [Note3, Note4] >>> >>> Versions: >>> Qt: Stay on 6.10 (as agreed upon in the last e-mail thread and on Matrix >>> discussion) >>> KDE FW: 6.26 >>> >>> Notes: >>> [General / CI] >>> I'm not sure how the CI situation will work out for one extra release of >>> Plasma 6.7. There were some concerns raised by Ben Cooksley [4], though >>> that was with my then drafted 6.7.8 bugfix release, which has been >>> dropped. The current proposal would end the 6.7 series with 6.7.7 . >>> >>> [Note1] This is the Thursday following the corresponding Frameworks >>> release ("expected May 8th"). It's also 2 days after 6.6.5, but that >>> should be OK? >>> >>> [Note2] Delayed by one week with regard to the Fibonacci sequence to >>> avoid conflict with 6.8.2 >>> >>> [Note3] As can be seen further down this e-mail, this is about 2 weeks >>> after tagging of Plasma 6.9 (scheduled for 2027-01-21) >>> >>> [Note4] Even though this is one extra release compared to other Plasma >>> versions, consesus so far seems to be to not call this an "LTS" release >>> publicly. >>> +++++ [/Plasma 6.7.] +++++ >>> >>> >>> >>> +++++ [Plasma 6.8.] +++++ >>> 6.7.80 2026-09-03 >>> 6.7.90 2026-09-17 [Note5] >>> 6.7.91 2026-10-01 >>> TAR 2026-10-15 >>> 6.8.0 2026-10-20 >>> 6.8.1 2026-10-27 >>> 6.8.2 2026-11-03 >>> 6.8.3 2026-11-17 >>> 6.8.4 2026-12-08 >>> 6.8.5 2027-01-12 >>> 6.8.6 2027-03-16 [Note6] >>> >>> Versions: >>> Qt: TBD (Staying with Qt 6.10 or Qt 6.11 would be possible, released >>> "March 2026"[3]) >>> KDE FW: 6.30 >>> >>> Notes: >>> [Note5] Thursday after corresponding Frameworks release ("expected Sept. >>> 11th") >>> [Note6] Delayed by one week with regard to the Fibonacci sequence to >>> avoid conflict with 6.9.1 >>> >>> >>> +++++ [/Plasma 6.8.] +++++ >>> >>> >>> +++++ [Plasma 6.9.] +++++ >>> 6.8.80 2027-01-07 [Note7] >>> 6.8.90 2027-01-21 >>> 6.8.91 2027-02-04 >>> TAR 2027-02-18 >>> 6.9.0 2027-02-23 >>> 6.9.1 2027-03-02 >>> 6.9.2 2027-03-09 >>> 6.9.3 2027-03-23 >>> 6.9.4 2027-04-13 >>> 6.9.5 2027-05-18 >>> 6.9.6 2027-07-13 >>> >>> >>> Versions: >>> Qt: TBD (Qt 6.11 and Qt 6.12 would probably both be available) >>> KDE FW: 6.34(?) - Not scheduled yet. >>> >>> Notes: >>> [Note7] I've delayed this by about 2 weeks from the "usual" schedule to >>> avoid a soft freeze right around Christmas. All other dates are delayed, >>> therefor, too (when comparing with earlier versions of Plasma). >>> >>> This might be a good time to re-think the 2-or-3-releases a year >>> situation. >>> >>> +++++ [/Plasma 6.9.] +++++ >>> >>> As always: this is just a quick proposal by me, trying to take into >>> account previous discussions and previous schedules. I'm happy to change >>> it. >>> >>> Best regards >>> >>> Martin >>> >>> [1] https://blogs.kde.org/2025/11/26/going-all-in-on-a-wayland-future/ >>> [2] >>> https://mail.kde.org/pipermail/plasma-devel/2025-December/123833.html >>> [3] https://wiki.qt.io/QtReleasing >>> [4] >>> https://mail.kde.org/pipermail/plasma-devel/2025-December/123826.html >>> >>
