Screen shooting and recording protocols (Re: Authorized clients)

[Martin Peres]

Le 09/01/2014 14:41, Pekka Paalanen a écrit :
> On Thu, 09 Jan 2014 13:05:28 +0100
> Martin Peres <martin.peres at free.fr> wrote:
>
>> 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.
> Yeah, that would be part of the failsafe, except the implementation
> details and protocol get complicated as you probably do not want the
> compositor to depend on the client in allocating the buffers the
> compositor is rendering into, which means you cannot use wl_drm.
>
> Or maybe you could... compositor has its own 2-3 private buffers it
> normally uses, and the recorder client could give it some "empty"
> buffers. The compositor renders into client's buffers one by one if they
> are suitable and not busy, *and* flips them on screen. As the fallback
> it can use its own buffers. That way the client is the one that gets
> "killed on OOM". Maybe that'd work.
Oh, very interesting idea. I wouldn't have thought of that.

>
>> 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?
> Such a function would be higher level API than the protocol, since the
> wire protocol has no concept of a "return value".
>
> Yes, that should be all that's needed. "Here it is, just say when
> you're done."

Oh, ok, so we would need two events then:
- Compositor -> client: new image available in buffer index %i
- Client -> compositor: buffer index %i has been processed and can be 
re-used

That should be enough to map that to the PUT/GET pointers of a ring buffer.
However, the ring buffer would need to be implemented on both side 
(compositor
and client).
>
>> 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!
> Not really. We want zero-copy, and then it's ok to push frames
> at the compositor's repaint rate (which is variable!). If the client
> doesn't need some of them, it just acks them without processing. I'm
> assuming a frame is sent only when the compositor repaints, i.e.
> something on screen changes. That's how the current recorder works, too.

If we achieve 0-copy, then this is indeed what should be done.

If we have to do copies, then it would be nice not to slow down
memory by doing useless copies. It would thus need an indication
of how many frames per second should be sent (or how many frames
should be dropped).
>
> We do not want to cap the compositor's repaint rate with this in any
> case.

Sure thing, yeah ;)

Cheers,
Martin