3 ms·

> The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as

> The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well. The required negotiation for that to happen is taking/going to take years and delay Wayland adoption. Linux fragmentation is a real thing, but if the community is going to take multiple years to reach a consensus on the right way to approach screenshots, that does at least somewhat suggest to me that leaving it out of the base protocol may be a good decision. My understanding is that the point of Wayland is to be a semi-permanent solution to the problem of X11. Any mistakes we make in the protocol will haunt us for decades, not just years. That concern makes me more likely to err on the side of reaching consensus before core logic is implemented, even though I admit that the fractured nature of the Linux community is likely to make process take a lot longer. I'm not saying that nothing should be standardized, just that if it looks like there's disagreement over implementation, it might be a good idea in this specific case to bias towards delaying a final decision.

roenxi 7y ago
The protocol mistake might easily be that they didn't include a security policy mechanism for coordinating Wayland buffers or something similar. It sure looks from the peanut gallery looks like they have a security model (graphical output is completely secret except to the compositor) that is insufficient in practice and users really want applications to be able to snoop on each other when required. That is going to be more difficult to tack on afterwards than it would have been to design in at the start. Security is exceedingly difficult to do after the fact. Maybe they did consider all this and have a plan. But I havn't seen anyone write a "this is how you target arbitrary compositors with your toy screenshot program" article yet.
- glennpratt 7y ago
  > Security is exceedingly difficult to do after the fact. This is an odd application of that idea to me. In my experience it's not to terrible to punch holes in a system after the fact. Exceedingly difficult is patching the holes in a project that starts as Swiss cheese.
- deleted 7y ago
  [deleted]
- arghwhat 7y ago
  I think this is a misunderstanding of how screenshots work, and how Wayland has always intended to deal with the issue. First of all, note that as with any window system, application buffers are not the final version of what you see on the screen. A normal desktop has wallpapers, transparency, task bars, multiple windows and window occlusion. This means that apart from a few special cases, only the compositor knows how the full scene currently looks, and is the only entity capable of producing a buffer containing the entire thing. For this reason, the only way to do screenshots is to have a way to ask the compositor for one. This is the case for any windowing system, and nothing related to buffer management will change that. > ... that they didn't include a security policy mechanism for coordinating Wayland buffers Depending on what you mean, this is either slightly or very untrue. Basically, when you try to present to screen, a client takes a buffer (which is private) and commits it to a surface. This temporarily borrows it to the server. Should the server wish to share the buffer, this is when this would be done. Before doing so, the server would enforce any security restrictions as necessary. This is how all client-to-client communication happens in wayland: With the server as mediator, when it permits it. A screenshot of a window or direct-scanout application could be implemented by simply having the server further borrow the buffer to a recording application, with appropriate restrictions in place. > users really want applications to be able to snoop on each other when required. I don't understand why you would think that this is a problem under Wayland. They only difference is that while X11 implicitly allows everyone to snoop on everything without any way to control it, snooping in Wayland is explicit, and servers can prompt users to permit it per application. Or not, it's up to the server.

roenxi 7y ago

The protocol mistake might easily be that they didn't include a security policy mechanism for coordinating Wayland buffers or something similar. It sure looks from the peanut gallery looks like they have a security model (graphical output is completely secret except to the compositor) that is insufficient in practice and users really want applications to be able to snoop on each other when required. That is going to be more difficult to tack on afterwards than it would have been to design in at the start. Security is exceedingly difficult to do after the fact. Maybe they did consider all this and have a plan. But I havn't seen anyone write a "this is how you target arbitrary compositors with your toy screenshot program" article yet.

glennpratt 7y ago
> Security is exceedingly difficult to do after the fact. This is an odd application of that idea to me. In my experience it's not to terrible to punch holes in a system after the fact. Exceedingly difficult is patching the holes in a project that starts as Swiss cheese.
deleted 7y ago
[deleted]
arghwhat 7y ago
I think this is a misunderstanding of how screenshots work, and how Wayland has always intended to deal with the issue. First of all, note that as with any window system, application buffers are not the final version of what you see on the screen. A normal desktop has wallpapers, transparency, task bars, multiple windows and window occlusion. This means that apart from a few special cases, only the compositor knows how the full scene currently looks, and is the only entity capable of producing a buffer containing the entire thing. For this reason, the only way to do screenshots is to have a way to ask the compositor for one. This is the case for any windowing system, and nothing related to buffer management will change that. > ... that they didn't include a security policy mechanism for coordinating Wayland buffers Depending on what you mean, this is either slightly or very untrue. Basically, when you try to present to screen, a client takes a buffer (which is private) and commits it to a surface. This temporarily borrows it to the server. Should the server wish to share the buffer, this is when this would be done. Before doing so, the server would enforce any security restrictions as necessary. This is how all client-to-client communication happens in wayland: With the server as mediator, when it permits it. A screenshot of a window or direct-scanout application could be implemented by simply having the server further borrow the buffer to a recording application, with appropriate restrictions in place. > users really want applications to be able to snoop on each other when required. I don't understand why you would think that this is a problem under Wayland. They only difference is that while X11 implicitly allows everyone to snoop on everything without any way to control it, snooping in Wayland is explicit, and servers can prompt users to permit it per application. Or not, it's up to the server.