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.