> (1) poor Wayland support in nVidia's proprietary drivers
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.
Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing.
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.
Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO
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)
One very stupid reason is the Qt itself, graphics application can't live without the QScreen instance. If user unplug every screen from the system, in order to prevent crash qt create the fake screen and hang in the headless state.
(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.
Could this potentially open up the possibility of implementing a user-level desktop session serialization and restoration feature? Similar to how Emacs handles per-directory sessions.
> 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.
> clients relied on memory stored by the Xserver, they made synchronous calls that were expected to return values, and multiple clients talked to multple clients.
Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.
Yeah, very little in the protocol is sync. E.g. when you create a window the client picks the id, and you just go on assuming it will be created until/unless an error arrives.
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.
The severely limited scope of Wayland forces all DE vendors to reinvent the wheel and basically recreate their own X11. But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered.
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.
What’s the difference between a display server managing frames from applications for display, and compositors.. managing frames from applications for display but possibly with fire and wobbling? That’s like a bad place to draw a line.
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.
CoastalCoder|2 years ago
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?
sho_hn|2 years ago
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.
traverseda|2 years ago
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.
pseudotrash|2 years ago
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)
tov_objorkin|2 years ago
sprash|2 years ago
(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.
jangid|2 years ago
p4bl0|2 years ago
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.
renox|2 years ago
throwaway1984s|2 years ago
6 years ago and no toolkit modifications required.
soupbowl|2 years ago
josefx|2 years ago
Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.
vidarh|2 years ago
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.
c-hendricks|2 years ago
(This is genuinely interesting, I'm not sure how practical it is, but still very cool.)
saidinesh5|2 years ago
PurpleRamen|2 years ago
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?
sprash|2 years ago
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.
kaba0|2 years ago
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.
unknown|2 years ago
[deleted]