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