Le 09/01/2014 10:00, Pekka Paalanen a écrit :
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
This is indeed something that needs to be discussed independently
of any security concern.
On Wed, 8 Jan 2014 23:30:29 +0100
Maarten Baert <maarten-ba...@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.
There is a way to limit the memory consumption of apps that don't
consume buffers. We could have a small ring buffer of wl_buffer or
dma-buf (if we want 0 copy) on the compositor side. When the
ring buffer is full, the compositor should not copy or store any new
buffer. This way, it won't use up all the video memory.
Then, we need a way for the compositor to know when the user
consumes a buffer. Having a simple "get_next_frame()" function
returning the next wl_buffer or the next dma-buf fd would be
enough. We could also tell that the semantics of the call means
that the application should be done using a frame before
requiring a new one. If we really want to be conservative, we could
only use 2 entries in the ring buffer.
This way, I don't think we would need any other form of synchronization,
would we?
In order to reduce the frame rate, another function in the protocol
is needed to set the desired framerate otherwise a lot of copies will
be made for no good reason, as Maarten rightly suggested!
If you need some information about the window the user picked, you need
to embed that into the shooting and recording protocols.
This is why I think we should have different hot keys so as the compositor
can use the mouse cursor as an input of which window/screen should be
grabbed, before even launching the recording app.
Obviously, it will only work on devices with mice but I'm sure it could be
translated to touch screens by remembering which application / screen
received the last touch input.
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.
Yes, there was a short discussion like that at XDC2012. Binding
semantic events, not a key, is the way to go :)
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
