Hacker News Reader

Comment by shadowgovt | Hacker News Reader

And that punting is indicative of the problem. The reason the stacks we have are hot garbage is because they didn't have the luxury of punting on hard problems, and hard problems solved quickly make your stack hot garbage.

It does give you a garbage stack that solves problems though.

View on HN

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".

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.

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.

> 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).

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

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.

Screenshots on embedded is very useful in some cases, like debugging, or information sharing or archiving, which often performed by smartphone camera today.

Yes, that's why I said you can have the display server dump it to a file. No protocol support is needed for that.

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)

Reply on news.ycombinator.com