undefined | Better HN

0 pointsQUrprUd1nCeicw3y ago0 comments

No, that wasn't a mis-step and it wasn't the wrong policy. Wayland is primarily concerned with taking buffers and telling the GPU to put them on the screen. Buffer sharing between clients is more concerned with the opposite: taking GPU buffers and turning them back into CPU-readable pixels so software can do arbitrary processing on them. Those are two very different concerns.

And because screenshots are a privileged operation, this will always need to go through a back-channel anyway to handle the security aspect. Otherwise you'll end up with a repeat of X11 again where any Wayland client connected to the server can scrape the screen at all times. So for desktop use there's really no reason to ever put it in a Wayland protocol. The design from the beginning was to keep privileged operations (like screenshots and input grabs) out and that still holds true now.

0 comments

roenxi3y ago

That is the view they took; but that view involved a decade-long process to get a Wayland ecosystem to where we could reliably screenshot the full screen. Still isn't possible in Debian Stable if I recall correctly. Wayland is the future, but lets not put on too brave a face. The design for accessing the composited output was bad and it fell over in practice.

There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. If someone wants to "install Wayland", technically they might end up having to research which framework they have to work with to make a Zoom call and screen share, which could be incompatible with Google Meets and screen sharing. Indeed, that dynamic will force centralisation on a specific set of libraries just like X used to with drivers - for no particular reason other than they didn't feel like scoping out the original specification a little more practically. If all the Wayland compositors are going to be expected to use the same library, they may as well have included it as an appendix back in '08 and saved all the mucking around in the mean time.

This is hardly the end of the world and I do think the people involved in Wayland made a good attempt. But hindsight is 20/20 and the wart is now quite obvious.

QUrprUd1nCeicwOP3y ago

>Still isn't possible in Debian Stable if I recall correctly.

It depends on the app. Chances are older apps needs to be updated to use the portal.

>There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop.

No, there's only one way. Use the XDG screenshot portal. It's not a library, it's a standard API the desktop implements.

>for no particular reason other than they didn't feel like scoping out the original specification a little more practically

There was a reason. They didn't scope it out because they couldn't. Privileged operations need to be implemented using OS-specific security facilities. There's no way to make this work correctly just with Wayland. On Linux it needs a sandbox, and those are very different in scope and design from a window system.

>But hindsight is 20/20 and the wart is now quite obvious.

No, there's no wart. Or rather, if there is a wart, it's on the OS itself and how it does security. Linux didn't have a way to do this kind of sandboxing before, so someone had to invent that too. Efforts to hack sandboxing into X11 (see Qubes OS) have run into these same problems.

roenxi3y ago

Now I'm certainly no expert in this area (and I'm sure it shows) but xdg-desktop-portal was built to support Flatpak and is linked fairly closely to PipeWire.

"The protocol is great, you just need to rebuild your Audio/Visual stack to support it" is certainly a reasonable take when dealing with something as weird as X. But, and I say this with a certain level of sympathy, bit it showcases a deep inflexibility in the design of Wayland.

Taking screenshots is not that hard by default. I'm very glad that someone is taking on the mammoth task of improving the linux graphics stack, but it is obvious that they designed screenshots out of the system then had to work for a decade to design them back in by reworking the way multimedia is done, and de-facto we're only going to be able to use Wayland in conjunction with XDG standards making sure that implementing the light protocol in a light compositor is a mistake. That isn't the end of the earth, it is no worse than what we do now - but it is a glaring weakness in the Wayland protocol that could have found a way to be usable from 2008 -> 2018.

1 more reply

j / k navigate · click thread line to collapse

0 comments

roenxi3y ago

This is hardly the end of the world and I do think the people involved in Wayland made a good attempt. But hindsight is 20/20 and the wart is now quite obvious.

QUrprUd1nCeicwOP3y ago

>Still isn't possible in Debian Stable if I recall correctly.

It depends on the app. Chances are older apps needs to be updated to use the portal.

>There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop.

No, there's only one way. Use the XDG screenshot portal. It's not a library, it's a standard API the desktop implements.

>for no particular reason other than they didn't feel like scoping out the original specification a little more practically

>But hindsight is 20/20 and the wart is now quite obvious.

roenxi3y ago

Now I'm certainly no expert in this area (and I'm sure it shows) but xdg-desktop-portal was built to support Flatpak and is linked fairly closely to PipeWire.

1 more reply

j / k navigate · click thread line to collapse