Screen shooting and recording protocols (Re: Authorized clients)

[Pekka Paalanen]

Hi,

what I'm replying to has nothing to do with security anymore, so I
changed the topic.

The security issue is what and when can use a specific protocol
interface, the below is about how to use the interfaces once you
already have access.


On Wed, 8 Jan 2014 23:30:29 +0100
Maarten Baert <maarten-baert at hotmail.com> wrote:

> 
> On 08/01/14 13:52, Martin Peres wrote:
> > I think the screenshot API and the video recording one should be
> > separate.
> Ideally that's true, but it creates extra work for the compositor
> developers. And I don't see a huge benefit, actually. On X11 I can
> simply take 30 screenshots per second and this works great, the
> performance is about as good as it can get (2ms for a 1920x1080 frame,
> that's almost as fast as a simple copy) and the only issue is tearing
> (which is something that a good screenshot protocol should already
> solve, obviously we don't want tearing in screenshots either). So I
> would be perfectly happy with a screenshot interface that works just
> like X11 minus the tearing. Do we really need a separate API for that?
> 
> There's another gray area here: what about timelapse videos? These are
> created by taking a screenshot every few seconds and then playing them
> back at much higher speed. Should such an application use the
> screenshot or the video API?

There are differences in the implementation details of shooting (stills)
vs. recording (videos).

Weston supports (though disabled atm, AFAIK) hw overlays in addition to
the GL renderer. To make a screenshot, the overlays are temporarily
disabled, so that GL can composite the whole image which can then be
sent to the shooting client.

If you do repeated shooting, you probably end up doing a lot of useless
back and forth work, enabling and disabling hw overlays. Also, shooting
has one frame latency, because you have to wait for a repaint after you
disabled the overlays. It will probably be quite hard to get a
stable framerate.

If the compositor knows we are doing recording instead of shooting, it
can disable overlays for the whole duration. You only have the latency
for the first frame, not all frames. There are probably other details
that can be optimized, too.

Shooting can easily be implemented like the current screenshooter
protocol: a client creates a wl_buffer, and tells the compositor to fill
it in. There is an inevitable copy, but since shooting is a rare action
and usually triggered by the user directly, that cost is acceptable.
The timing requirements are also very loose.

That scheme might not work too well with recording, and achieving a
zero-copy path to the video encoder will be hard. In that sense, the
compositor autonomously pushing buffers to the client would be more
performant, but then we have the problem of synchronizing buffer reads,
writes, and re-uses. In the opposite direction, the synchronization was
solved with the wl_surface.attach/commit and wl_buffer.release
messages, but here an accidentally malfunctioning client has a greater
risk to crash the compositor, if it does not return the buffers to the
compositor in time, so the compositor needs a failsafe mechanism.

Those are some reasons why screen recording (video) is easier to do as
a compositor plugin, like it is currently in Weston. A separate client
would need a non-trivial amount of new Wayland protocol to work well.

Which method timelapse recording should use depends on the desired
framerate and accuracy requirements.

> > For the configuration of the screenshot, I see two cases. Either we
> > just want
> > the compositor to grab the image and pass it to an application [1]
> > or we want
> > the screenshotting app to be able to be able to query the number of
> > screens and
> > windows and their positions. The first doesn't require a Wayland
> > protocol, the
> > second does however require a privileged protocol.
> The second is required for more all complex use cases, i.e. where the
> user wants to capture only a single screen (or part of a screen). I
> already support this under X11 and it seems to be a feature that many
> users use (simply because monitor resolutions are usually larger than
> the desired video resolution).

Exporting the window hierarchy is not a good idea, and I think we are
seriously trying to avoid it unless absolutely necessary.

Instead, a client could ask the compositor to ask the user which window
she wants to capture, and then the compositor would capture only that.
Capturing individual outputs is a lot easier: Wayland core protocol
already exposes all outputs, so the client can directly ask for a
certain output.

Asking the compositor to ask the user is really the only way to choose
a window, anyway. There are no global names for windows that you
could use from clients, and even if you did, you would not be able to
implement "pick by clicking the actual window" without asking the
compositor to do that. It would be a lot of new Wayland protocol to
have the window picking controlled by the client.

If you need some information about the window the user picked, you need
to embed that into the shooting and recording protocols.

In the part I cut out, there were some concerns about who and how
should decide what hotkeys may or may not start shooting or recording.
I think there was recently'ish a nice suggestion about a generic
solution to the global hotkey problem, so you can probably leave it for
that. I'm referring to the "clients bind to actions, server decides what
hotkey is the action" kind of an idea, IIRC. There is a myriad of
details to solve there, too.

> User interaction is something that can only be defined by the
> application, not by the compositor. The compositor can't anticipate
> what kind of GUI or CLI some application might decide to use. Maybe
> some users want the ability to start/stop recording using an IR
> remote! Actually that's not even that far-fetched with SteamOS and
> their 'big picture mode'. Should every Wayland compositor add support
> for IR remotes too?

I believe so, yes. An IR remote is an input device, and only the
compositor can know which client should receive which events, if any.
That way the normal users don't even need to access the device node
directly, so you make eavesdropping harder. Whether the remote is
exposed as a keyboard or triggering just actions or something else, is
just yet another detail. You may want to map different buttons of the
same remote to act on different programs, like volume always to the
mixer while numbers to the current app, and the compositor itself
handling the power button.


Thanks,
pq