diff --git a/xml/treeland-capture-unstable-v1.xml b/xml/treeland-capture-unstable-v1.xml index b39411e..1ed24ca 100644 --- a/xml/treeland-capture-unstable-v1.xml +++ b/xml/treeland-capture-unstable-v1.xml @@ -29,8 +29,9 @@ - Start session and keeps sending frame. + Start session and keeps sending frame with the given buffer. + @@ -45,9 +46,15 @@ + + Notify the client that a new frame is coming, client should copy or import dmabuf. + + + + - Main event supplying the client with information about the frame. If the capture didn't fail, this event is always - emitted first before any other events. + Main event supplying the client with information about the dmabuf frame. + If the capture didn't fail, this event is directly after the frame event. When mask is provided, x and y should be offset relative to mask surface origin. Otherwise offset_x and offset_y should always be zero. @@ -63,7 +70,7 @@ - + @@ -91,7 +98,6 @@ - @@ -104,22 +110,6 @@ - - - Inform client to prepare buffer. - - - - - - - - - - Inform client that all buffer formats supported are emitted. - - - Copy capture contents to provided buffer @@ -132,7 +122,7 @@ Provides flags about the frame. This event is sent once before the "ready" event. - + @@ -194,24 +184,71 @@ + + + This event notify the client what kind of shm buffer is supported. It may be sent several times after "capture" + or "create_session". If client receives dmabuf notification, it should use dmabuf instead. + + + + + + + + + + This event notify the client what kind of dmabuf is supported. It may be sent several times after "capture" + or "create_session". If client receives the notification, it should use dmabuf instead of shm buffer. + + + + + + + + + This event notifies the client that compositor supports exporting dmabuf. It should be sent just once + after "capture" or "create_session". Client should prefer export dmabuf over dmabuf or shm buffer. + + + + + + This event indicates an end of source_shm_buffer, source_dmabuf and source_export_dmabuf event + sequence. + + + - There could a lot of reasons but the most common one is that selector is busy + There could a lot of reasons but the most common one is that selector is busy indicated by "selector_busy". + Note that this event will still be sent after "source_ready" event. This is typically caused by destroying + source like user closes the captured window. Client will receive a "source_destroyed" failure then, it + should destroy the session and frame created from current source and re-select source by "select_source" + request. A user_cancel failure is caused by user canceling the selection before acknowledgement. It is up + to the client to determine whether destroies the session or re-select source. - + This event can be called just once. A second call might result in a protocol error cause - we just provide transient + we just provide transient capture for security reason. Invoking capture means that source + selected is acknowledged by client and will not change. Thus, source buffer information will + follows this request to inform the client about what kind of buffers are supported. - Often used by a screen recorder. + This event can be called just once. A second call might result in a protocol error. This is often + used by a screen recorder. Create a session receiving continuous frames. Invoking create_session + means that source selected is acknowledged by the client and will not change. Thus, source buffer information + will follows this request to inform the client about what kind of buffers are supported. Frozen clients + unfreeze after selection is acknowledged. Although capture is allowed to be invoked after create_session, + the image may not as expected.