3 ms·

I don't see how screen shots/sharing is really that hard of a problem. Wayland's model doesn't give the ability to arbitrarily capture these things the way X di

I don't see how screen shots/sharing is really that hard of a problem. Wayland's model doesn't give the ability to arbitrarily capture these things the way X did, but surely it couldn't have been that difficult to add an escape hatch for common use cases like this to the base protocol. Remote desktop is a harder problem to be sure, but it is also a pretty common use case (window remoting less so). If you're setting out to modernize and replace such a fundamental component of Linux Desktop then you should probably have a plan for that. If not in the first spec, at least a statement to the effect that it will be part of a future spec instead of just punting to "implementation defined".

shadowgovt 6y ago
I'm not a developer on Wayland and I haven't looked at the code, so I can't comment directly on their situation. A hypothetical I can come up with is that if they've tried to implement a very secure architecture, they may have painted themselves into a corner if there's no easy way to capture pixels post-composite... Then no one piece of the system has enough authority to see all the pixels to capture an arbitrary screenshot, and oops. An unsecured screenshot escape hatch can be used by malicious software to scrape information shown in windows on your system, and with modern OCR being what it is (or, hell, a shady Mechanical Turk transcription job), that could be an attack vector for surfacing people's private information.
- cycloptic 6y ago
  Security is one of the major reasons, and this is indeed a privileged operation that should not be accessible by all clients. The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots.
  - irishsultan 6y ago
    > The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots. I'm unsure what kind of graphical environment you can imagine where screenshots are not useful at all (if only to capture the screen when something weird is going on).
    - cycloptic 6y ago
      There are numerous other graphical environments that Linux runs on where screenshots don't make sense: https://en.wikipedia.org/wiki/Linux_on_embedded_systems https://en.wikipedia.org/wiki/Linux_on_embedded_systems For debugging purposes, the display server can just dump the screen to a file or a serial port itself. The only reason you would need this in the protocol is so other arbitrary applications could capture the screen.
      - drran 6y ago
        Screenshots on embedded is very useful in some cases, like debugging, or information sharing or archiving, which often performed by smartphone camera today.
        cycloptic 6y ago
        Yes, that's why I said you can have the display server dump it to a file. No protocol support is needed for that.
    - kaba0 6y ago
      Car navigation panels where Wayland is already used? Also, screen sharing is not that easy of a problem if done properly (eg. allowing another app to act on the buffer and directing it here and there)

shadowgovt 6y ago

I'm not a developer on Wayland and I haven't looked at the code, so I can't comment directly on their situation. A hypothetical I can come up with is that if they've tried to implement a very secure architecture, they may have painted themselves into a corner if there's no easy way to capture pixels post-composite... Then no one piece of the system has enough authority to see all the pixels to capture an arbitrary screenshot, and oops. An unsecured screenshot escape hatch can be used by malicious software to scrape information shown in windows on your system, and with modern OCR being what it is (or, hell, a shady Mechanical Turk transcription job), that could be an attack vector for surfacing people's private information.

cycloptic 6y ago
Security is one of the major reasons, and this is indeed a privileged operation that should not be accessible by all clients. The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots.
- irishsultan 6y ago
  > The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots. I'm unsure what kind of graphical environment you can imagine where screenshots are not useful at all (if only to capture the screen when something weird is going on).
  - cycloptic 6y ago
    There are numerous other graphical environments that Linux runs on where screenshots don't make sense: https://en.wikipedia.org/wiki/Linux_on_embedded_systems https://en.wikipedia.org/wiki/Linux_on_embedded_systems For debugging purposes, the display server can just dump the screen to a file or a serial port itself. The only reason you would need this in the protocol is so other arbitrary applications could capture the screen.
    - drran 6y ago
      Screenshots on embedded is very useful in some cases, like debugging, or information sharing or archiving, which often performed by smartphone camera today.
      - cycloptic 6y ago
        Yes, that's why I said you can have the display server dump it to a file. No protocol support is needed for that.
  - kaba0 6y ago
    Car navigation panels where Wayland is already used? Also, screen sharing is not that easy of a problem if done properly (eg. allowing another app to act on the buffer and directing it here and there)