As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been:
(1) poor Wayland support in nVidia's proprietary drivers
(2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible.
Does QtWayland 6.6 address either of those (and/or some other) barriers?
This has improved quite a bit with nVidia eventually implementing GBM support (so compositors no longer need an nVidia-specific codepath, which is nice). I use Plasma on Wayland on my nVidia-powered ThinkPad, and it's generally fine and has been for some time. That said, the nVidia stack does still feel a bit more hit and miss than some others.
> (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible.
These largely have been addressed by newer protocols and infra, although application support and maturity for those protocols in deployed systems is still trailing behind X11. Still, the fundamentals have been worked out, and there's steady progress on spreading the solutions through the ecosystem.
And no, this blog post has nothing to do with either topics but is about unrelated technical innovation in the Wayland space.
The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support but it's still all unpaid volunteers.
There also used to be some more leeway about protocols and extensions. For a long time now Gnome has been saying "you're either a gnome app or you're not" when they deprecated stuff like tray icons. But there was generally a way back, a way to run your non-gnome app cleanly on Gnome. With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. There are common desktop extensions that Gnome just isn't really interested in developing.
This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else.
> With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now.
This is also not true. GNOME has designs for tray icons in their GitLab repo. The thing that is blocking better tray icons in Linux is a lack of interest in finishing the protocol proposal. The ticket hasn't seen much traction in the last couple of months.
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
In GNOME 45 all current extensions will loose backward compatibility, that's one of the yet more changes that will force many to migrate to other desktop environments
We are really wondering why those "unpaid open source developers" would want to "re-implement everything". Fixing existing systems is hard, i presume. /s
What issues are you facing with screen recording?
Can't say anything about NVIDIA because I avoid these chipsets like the plague (even for windows)
Why not ? Is the wayland "maintainable " ?
(0) zero community mind share as a result of extremely cumbersome and developer hostile APIs and the lack of standardization of essential functionality.
QtWayland won't be able to address this because vendor lock-in for a de-facto proprietary toolkit won't generate any community mind share either.
https://floss.social/@kde/111051338968313784
> Plasma developer David Edmundson demonstrates how a desktop using Wayland, Qt6 and KWin can recover from a catastrophic crash as if nothing had happened.
> You will lose no data, the video you were watching will not skip a frame, and the contents of your clipboard will remain intact.
> The same principles can be applied to jumping from one desktop environment to another, for example, from Plasma to Gnome...
> ... And can provide a way to save _the state_ of an application to disk, stopping the app in its tracks and removing it from memory, so that later you can restore it just where you left off.
This is partly why Activities ended up feeling somewhat redundant to Virtual Desktops. But if you go back to those early 4.x releases, you will find that the Pause/Unpause buttons etc. on Activities were featured rather more prominently.
As David describes in the blog post, things in Wayland are a lot more nicely layered. In part, toolkits have also seen architecture cleanup as a side effect of having to support multiple backends during the transition, and code has become more hackable and modular as a result.
6 years ago and no toolkit modifications required.
The blog post being discussed here is about handling a crash in "waybridge" instead, so to speak, and having this ability in Wayland itself instead of requiring an additional abstraction and protocol.
Arcan can use multiple waybridge instances, e.g. one per client, to get some isolation between the clients (from the post), but it does start to sound a bit heavy perhaps (I don't know much about the inter-Arcan IPC though).
Cool stuff, though.
Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.
Only things explicitly querying for information is "somewhat" sync, but then too the reply will arrive back with a sequence number, so the client API can just keep returning events and hold on to the replies until you ask for them.
X has many warts, but it being synchronous isn't one of them.
I seem to remember that there was a command line switch to run X (or some clients) in syncronous mode. It was mostly used for debugging.
(This is genuinely interesting, I'm not sure how practical it is, but still very cool.)
The wayland security model means the compositor absorbs even more functions from global shortcuts to screencasting and input-method handling [..]
Doesnt that mean, Wayland becomes everything that X11 was, just worse? I thought, Wayland was created to break up the monolithic X-Server?
Also X11 was never "monolithic" but in reality completely modular. It allows for example to change the window manager or even compositor at runtime without affecting running programs. For this to work your API hast to provide more functionality than your typical Wayland compositor. This is often mistaken for "monolithic" when in fact is actually the complete opposite of monolithic.
On this one: It's not really that different. Very little if any KDE code made any direct calls to Xlib or xcb past the very early years. Most of this was also hidden by Qt abstractions, and toward app/shell devs most certainly by further KDE library abstractions. Directly interacting with X11 was an almost-never occurence.
Fairly similar in other toolkits, since most of them have some sort of cross-platform strategy and infra.
People sometimes have kind of odd notions of how exactly X11 development was different. X11 had its fair share of "fragmented implementations" immaturity. It had its fair share of "this new standard is not widely implemented yet" phases that people just don't remember because they started using it after things had settled down (e.g. NetWM and EMWH protocol extensions did not always exist, and also got interpreted quite differently sometimes, or e.g. the clipboard spec). DEs also did plenty of DE-specific things on X11 using proprietary window hints or DBus-based side channel protocols.
If there's one broad philosophical difference, it's Wayland has some widely-respected values around who gets to introspect what state and who acts as authority, that mean that things that X11 apps could monkey-patch may now require a protocol to be agreed on. But there's a lot of value in agreed-upon protocols, and X11 also needed many of them.
There's a lot of other concerns (input handling, screen shots, etc cetera) but at the heart Wayland is mostly just a management later for *nix dmabuf's. Mode setting concerns are done by the kernel too. Libwayland mostly uses egl, is my understanding. It invents so much less than X, where-as when X was made, the OS had none of these abstractions to reply on. X was basically the kernel, part 2. Wayland has none of this baggage; in almost all implementations leverages a world of great ready made stuff rather than implementing itself. Source: https://wayland-book.com/surfaces/dmabuf.html
Libraries are a thing
> because the APIs are DE/Toolkit specific
That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem.
> standardization that X11 offered
What standardization? A single implementation that does its thing is not a standard, by definition.
> Also X11 was never "monolithic" but in reality completely modular
But let me guess, you think that systemd is a huge monolith, right? Also, a wm is very trivial compared to the rest, they can easily be a lua extension and that’s it.
X is monolithic, because they had to pry printing and shit out of it over years of hard work.
I'm a novice when it comes to the implementation of compositors and display servers, but as a user it's been a far better experience than X11/Xorg ever was. Seeing this robustness video just proves it to me even more.
There is no problem with monoliths in itself, if you needlessly introduce IPC at boundaries that don’t need it, you make your life just harder (also, tell that to those who make everything into a microservice). Also, people can use libraries to create better, different implementations, e.g. see wlroots - isn’t that the spirit of open-source instead of a single de facto monolith?
The important thing is that the public API is well-defined.
Also, X has problems and needs replacing because its fundamental architecture got outdated in the last 30 years.
