Limitations of Weston's screenshooter / Are there any plans to create an official screenshot protocol?

[Giulio Camuffo]

2013/12/13 Maarten Baert <maarten-baert at hotmail.com>:
> I'm trying to add Wayland support to a screen recording application, but
> I'm running into a few issues:
>
> - There is no official protocol. I'm using the weston-specific
> 'screenshooter' interface now, but I don't want to use a different
> interface for every possible Wayland compositor in the future. Are there
> any plans to create an official screenshot protocol?

I don't think so, but you don't need to wait anything to start working on it. ;)

>
> - Permissions were an issue, but I hear this is being taken care of. The
> current solution is to drop the restriction completely for all clients -
> wouldn't it be safer to add a third mode where only local clients
> running as the same user are allowed to capture the screen? I think this
> mode would be more suitable for a typical Linux desktop (local
> applications can already do far more damage in other ways).

I think the best solution would be to have a way to configure in the
shell/compositor the trusted clients, and maybe a way for any client
to ask the permission to bind to a restricted interface, which would
pop up a request to the user.

>
> - There is no way to take a screenshot of a part of the screen. Some
> people only want to record a small area (usually one window), so it
> would be a lot more efficient if I could capture only the part I need,
> like I can do with X11.

I think the protocol in weston was made just to showcase the way such
a protocol would work, the "official" one would allow that.

>
> - There is a potential race condition where the size of the output
> changes after the application sends the screenshot request but before
> the Wayland server receives the request. In this case the buffer would
> be the wrong size. How does the compositor handle this? I would prefer
> something similar to what glReadPixels does, i.e. capture the valid part
> and make the remainder black, because this minimizes interruptions in
> the video. From what I can tell, the current implementation will ignore
> the screenshot request and never send the 'done' message, so the client
> will hang (unless the client implements a timeout).

Another thing to add in the "official" protocol.

>
> - The 'done' message doesn't tell the client whether the screenshot was
> successful, or what screenshot request (output and/or buffer) it is
> actually referring to. I don't think I can assume the screenshots will
> complete in the same order as they were requested (in a multi-monitor
> configuration).

I see two possible solutions:
- the screenshooter_shoot request could carry a serial which the done
event sends back later
- the screenshooter_shoot returns a screenshoot object which has the done event

>
> - How does the compositor deal with rotated/mirrored screens? Most
> applications won't care about the physical orientation of the screen,
> they just want a screenshot where things on the screen (windows, text,
> ...) aren't rotated or upside down.
>
> - Why can the protocol only capture one screen at a time? I expect this
> will result in tearing because the screenshots won't correspond to the
> same point in time. Can this be avoided somehow? I realize that
> different outputs can have different pixel formats, but I thought
> compositors used a single big surface for all of them anyway, making it
> trivial to capture all of them at once.
>
> I am not familiar with the Weston codebase, but I would like to help
> where I can to add the thinks I need to add full Wayland support to my
> application.
>
> Maarten Baert
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel