QtWayland 6.6 Brings Robustness Through Compositor Handoffs(blog.davidedmundson.co.uk)
blog.davidedmundson.co.uk
QtWayland 6.6 Brings Robustness Through Compositor Handoffs
http://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/
61 comments
> (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.
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.
Accessibility software needs access to the window details like executable, new title, window size and so forth and to be able to emulate peripherals.
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.
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.
> unpaid volunteers
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...
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...
I didn't mean unpaid Gnome developers, I meant everyone else. People like this SDL developer: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...
He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience.
>This is also not true. GNOME has designs for tray icons in their GitLab repo.
Yeah, but every other wayland compositor seems to have gotten it to work already. This is what people mean when they talk about "splitting the linux ecosystem". If they're not able to manage the complexity of implementing stuff like tray icons, things that are really important for cross-platform apps, maybe they should pivot to using a library like wlroots.
He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience.
>This is also not true. GNOME has designs for tray icons in their GitLab repo.
Yeah, but every other wayland compositor seems to have gotten it to work already. This is what people mean when they talk about "splitting the linux ecosystem". If they're not able to manage the complexity of implementing stuff like tray icons, things that are really important for cross-platform apps, maybe they should pivot to using a library like wlroots.
I don't know about the "on Gnome" part, specifically, but I think Ryan has done work on SDL on contract, or contributed to SDL as part of contract work on e.g. game ports. He's a prolific guy with many stories to tell about the Linux desktop, see https://icculus.org/~icculus/
I do get your point, though, and it's true, there's of course a lot of manhours on e.g. app fixes and porting, and many other things, that happen on a volunteer basis in the community to make it all work.
I do get your point, though, and it's true, there's of course a lot of manhours on e.g. app fixes and porting, and many other things, that happen on a volunteer basis in the community to make it all work.
Yeah, Icculus' case is a bit odd but also one of the strongest showing this in action. Barrier/synergy/input-leap (or whatever they're calling themselves these days) is another good example, but I can't just link to one polemic thread to get the point across. They've more or less just given up, despite the like 3 grand bug bounty for getting it working on wayland. Waypipe works, but ironically you can't forward x11 apps so you get into this weird situation where you need to use different protocols for different apps and you don't know which ahead of time.
OBS seems to finally be working with linux/wayland again, semi-reliably, and of course most things continue to work via x11 shims. It's getting closer, especially as Gnome gets closer to actually implementing a full set of desktop app protocols, but it is just a lot of work for toolkit developers to port everything over.
I still don't know how you'd go about running GUI apps inside docker containers, something we do at work for a few complicated deployments of ROS stuff (yes I'd rather do it some other way, but we don't have the man power).
OBS seems to finally be working with linux/wayland again, semi-reliably, and of course most things continue to work via x11 shims. It's getting closer, especially as Gnome gets closer to actually implementing a full set of desktop app protocols, but it is just a lot of work for toolkit developers to port everything over.
I still don't know how you'd go about running GUI apps inside docker containers, something we do at work for a few complicated deployments of ROS stuff (yes I'd rather do it some other way, but we don't have the man power).
And Gnome is slow, with a completely limited UI that barely gives you anything of utility. The file selector is so bad (try selecting a file with the keyboard) and slow it's not even funny, it even has concurrency issues if you select things too fast!?, in Gnome applications, buttons keep changing places for no reasons, 30y olds shorcuts stop working an update to the next (like, press enter to validate), they refuse fractional scaling for... I don't know actually, etc, etx. I am sorry for the well intentioned people working on Gnome. But it's just a dumpster fire at this point.
And the tone in the Gnome issue tracker is insufferable. Everybody that suggest something or tries to help is a moron from their point of view.
I cannot help but think the people working on Gnome live in a weird bubble.
And the tone in the Gnome issue tracker is insufferable. Everybody that suggest something or tries to help is a moron from their point of view.
I cannot help but think the people working on Gnome live in a weird bubble.
>they refuse fractional scaling
Huh? I'm using Gnome instead of MacOS because I can choose the size of the text and the other UI elements. On MacOS, the only choices that aren't blurry are 100% scaling and 200% scaling, but Gnome lets me set the scaling to an arbitrary value without blurriness. (I had to fuss with Emacs and my web browser to get them to be non-blurry when the scale factor is something other than 100%.)
Are there stupid design decisions in Gnome? Yes, but I've found Gnome to be usable with a little research (i.e., on how to set keyboard shortcuts for switching between apps instead of the "activities view").
Huh? I'm using Gnome instead of MacOS because I can choose the size of the text and the other UI elements. On MacOS, the only choices that aren't blurry are 100% scaling and 200% scaling, but Gnome lets me set the scaling to an arbitrary value without blurriness. (I had to fuss with Emacs and my web browser to get them to be non-blurry when the scale factor is something other than 100%.)
Are there stupid design decisions in Gnome? Yes, but I've found Gnome to be usable with a little research (i.e., on how to set keyboard shortcuts for switching between apps instead of the "activities view").
Ok now I am not sure which is which, what it working and what isn't anymore:
https://wiki.archlinux.org/title/HiDPI#Fractional_scaling
> There are common desktop extensions that Gnome just isn't really interested in developing.
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
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
There is a really good technical reason for that, and honestly, I don't want to use extensions that aren't being maintained as new versions of Shell get released.
The reason Gnome doesn't have a stable extensions API is the same reason extensions are powerful: extensions are user code running in the same JS environment as Shell and can do anything. I think that's a decent tradeoff for a best-effort system without a ton of manpower and ecosystem involvement.
The reason Gnome doesn't have a stable extensions API is the same reason extensions are powerful: extensions are user code running in the same JS environment as Shell and can do anything. I think that's a decent tradeoff for a best-effort system without a ton of manpower and ecosystem involvement.
> expecting a bunch of unpaid open source developers to go and re-implement everything
We are really wondering why those "unpaid open source developers" would want to "re-implement everything". Fixing existing systems is hard, i presume. /s
We are really wondering why those "unpaid open source developers" would want to "re-implement everything". Fixing existing systems is hard, i presume. /s
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)
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)
X11 will continue to exist and be maintained for decades. I would not even be surprised if it lasts longer than Wayland.
It already appears to be effectively dead. Pretty much all the commits in the repo are wayland related.
I am still using X and it is still working fine for what I need. Why would I need it to continue to be maintained?
> X11 is dead. After decades of serving us well it's not maintainable
Why not ? Is the wayland "maintainable " ?
Why not ? Is the wayland "maintainable " ?
The X11 maintainers said as much, then created Wayland?
The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44
This is just FUD.
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.
You forgot the most important reason:
(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.
(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.
It seems to be what they're going for at KDE:
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.
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 more or less what we once dreamed of doing with Activities in KDE 4, but couldn't make it work on X11 - we were banking on the X11 session handling protocols to implement the suspend/restore, only to find that few if any toolkits and apps implemented them properly, and that fixing this wasn't going to be viable due to a lot of spaghetti all over the place.
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.
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.
Interesting. I played with Activities for a while when they were introduced, but I've never understood what value they provide. I still don't, to be honest. But perhaps it's because they weren't able to provide value?
This reminds me of Arcan where the goal number 1 is robustness, which is probably a good idea given the complexity of GUIs.
https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...
6 years ago and no toolkit modifications required.
6 years ago and no toolkit modifications required.
Apples vs. oranges, though. If I read the blog post right, he's demonstrating that he can restart the main Arcan process while an auxiliary process called "waybridge" lives on, which for the Wayland clients is the actual compositor. This still requires the same type of "reconnect and restore" dance, but internal to Arcan-proprietary bits, pushing the problem up one level from the native Wayland exchange.
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.
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.
That's an irrelevant distinction. In both cases, if there is a crash in the bridging logic, it'll fail. In the QT case, the bridging logic is just living in each app process.
Arcan has some really cool ideas.
> 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.
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.
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.
> 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.
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.
Xlib is peculiar in that it doesn't really expose you to the protocol very well. For starters, it doesn't immediately write every request. Partly because it saves bandwidth on slow networks to not send lots of tiny requests that might end up in separate packets.
Partly because the Xlib API is pathological in making it hard for you to minimize requests yourself. E.g. a lot of calls to modify graphics contexts can be batched up, but that requires Xlib to not worth requests immediately.
So hence there being some value on testing with different flush behaviour.
But this is Xlib specific, not really X.
Partly because the Xlib API is pathological in making it hard for you to minimize requests yourself. E.g. a lot of calls to modify graphics contexts can be batched up, but that requires Xlib to not worth requests immediately.
So hence there being some value on testing with different flush behaviour.
But this is Xlib specific, not really X.
Finally, save states for Minesweeper.
(This is genuinely interesting, I'm not sure how practical it is, but still very cool.)
(This is genuinely interesting, I'm not sure how practical it is, but still very cool.)
I think the really practical part of this is dealing with out of memory use cases. Iirc he mentioned that in the video too.
[..]
Compositors and displays servers are now the same process, doubling the space for errors
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?
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?
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.
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.
> But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered.
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.
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.
> 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.
How do you think Qt draws on the screen ?
How do you think Qt draws on the screen ?
Right, but Qt abstracts that interaction so KDE code doesn't have to care about it. The person you're replying to never implied X11 wasn't involved, just that it was abstracted away.
> Wayland has some widely-respected values around who gets to introspect what state and who acts as authority
And this is a main problem. These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates.
> But there's a lot of value in agreed-upon protocols, and X11 also needed many of them.
Depends on the protocol. Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!
And this is a main problem. These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates.
> But there's a lot of value in agreed-upon protocols, and X11 also needed many of them.
Depends on the protocol. Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!
> These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates.
I don't understand why they would need to for a DND operation (or why a custom protocol would be needed - X11 didn't need one for the same use case either).
> Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!
This comes across as very irate and emotional. I'm glad you care about the FOSS ecosystem this deeply. I do as well, and have spent 20 years of my career working on making it succeed. I'd rather we don't presume malice in each other.
I don't understand why they would need to for a DND operation (or why a custom protocol would be needed - X11 didn't need one for the same use case either).
> Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!
This comes across as very irate and emotional. I'm glad you care about the FOSS ecosystem this deeply. I do as well, and have spent 20 years of my career working on making it succeed. I'd rather we don't presume malice in each other.
> I'm glad you care about the FOSS ecosystem this deeply. I do as well
As member of KDE e.V. board of directors you were part of the cancel brigade against Richard Stallman which was clearly an OP against FOSS. This means you are either some useful idiot or an actively malicious actor. Either way it would be great if people like you would stop "caring" about the FOSS ecosystem.
As member of KDE e.V. board of directors you were part of the cancel brigade against Richard Stallman which was clearly an OP against FOSS. This means you are either some useful idiot or an actively malicious actor. Either way it would be great if people like you would stop "caring" about the FOSS ecosystem.
That's a typical view, but I see it as a lot less monolithic because it's using the kernel to do a huge amount of the things X used to do itself.
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
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
> to reinvent the wheel
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.
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.
> 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.
It sure looks like it's true, or did GNOME/KDE/wlroots manage to agree on a single screenshot API?
It sure looks like it's true, or did GNOME/KDE/wlroots manage to agree on a single screenshot API?
Yeah, XDG portals. Not something that's essential to the display protocol.
The idea that we need to be shoving tray icons and screen recording and permissions APIs into the display protocol is an Xism that folks need to let go. The display protocol should only deal with displaying things, meaning it's a standard way to give memory buffers to clients for them to draw into, and all the other crap can and should be handled elsewhere.
The idea that we need to be shoving tray icons and screen recording and permissions APIs into the display protocol is an Xism that folks need to let go. The display protocol should only deal with displaying things, meaning it's a standard way to give memory buffers to clients for them to draw into, and all the other crap can and should be handled elsewhere.
Yeah, I'm a fan of it being an optional standard that's separate from the core display protocol. The problem is that it needs to be a standard, not 3 different standards because it wasn't standardized so 3 different groups created their own things, and all of the standards needed to replace X11 as it was actually used should have had a 1.0 spec before the whole mess was shipped to end users, let alone before users were told that this was the future that they needed to get on already.
> They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem.
What Wayland advocates don't see as a problem is the one of the main problems. I see a pattern here.
> years of hard work.
The only thing that takes "years of hard work" is writing a simple native Wayland client that takes screenshots.
What Wayland advocates don't see as a problem is the one of the main problems. I see a pattern here.
> years of hard work.
The only thing that takes "years of hard work" is writing a simple native Wayland client that takes screenshots.
https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
Without knowing much about dbus, or freedesktop I was able to make it work on a lazy afternoon. And it worked for me in wlroots and on gnome, I am assuming kde also implements it. How were you trying to do it that it took so long?
Without knowing much about dbus, or freedesktop I was able to make it work on a lazy afternoon. And it worked for me in wlroots and on gnome, I am assuming kde also implements it. How were you trying to do it that it took so long?
Wayland sounds a bit like what Vulkan is to OpenGL? Am I anywhere close?
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.
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.
Rather the opposite. Wayland is a far more opaque abstraction layer than X11.
Also the "robustness" is achieved with KDE/Qt specific protocols and as such has nothing to do with Wayland. Similar functionality could be achieved with X11.
Also the "robustness" is achieved with KDE/Qt specific protocols and as such has nothing to do with Wayland. Similar functionality could be achieved with X11.
>Am I anywhere close?
It's close, but since the services are much simpler you don't run into the problem of needing an older of magnitude of more lines to draw a triangle.
It's close, but since the services are much simpler you don't run into the problem of needing an older of magnitude of more lines to draw a triangle.
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.
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.
[deleted]
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?