Add screencopy protocol #17
Conversation
emersion
changed the title
| If the frame is successfully copied, a ready event is sent. Otherwise, | ||
| an abort event is sent. | ||
| </description> | ||
| <arg name="buffer" type="object" interface="wl_buffer"/> |
There was a problem hiding this comment.
Not sure we want to use a wl_buffer for this - maybe a FD would be more appropriate.
I would like to see this get in, and I would like to see a timestamp added telling you the time the frame you got captured was presented. |
| </description> | ||
| <arg name="frame" type="new_id" interface="zwlr_screencopy_frame_v1"/> | ||
| <arg name="overlay_cursor" type="int" | ||
| summary="include custom client hardware cursor on top of the frame"/> |
There was a problem hiding this comment.
I don't think we need to get so specific here. summary="composite cursor onto the frame"
|
@ascent12 @atomnuker Comments welcome! I'm not sure if the format and stride should be enforced by the compositor or should just be preferred. |
|
I can't imagine a situation where I'm going to be willing to do format conversions in the compositor for the sake of a picky client. |
|
|
||
| The region is given in output logical coordinates, see | ||
| xdg_output.logical_size. Trying to capture a region spanning outside the | ||
| output extents is a protocol error. |
There was a problem hiding this comment.
This is racy against anything that changes logical size, resulting in a protocol error sounds sub-optimal to me.
The frame event has it's own size either way, is there a reason you don't want to clip it?
There was a problem hiding this comment.
Hmm, I just wanted to avoid frames with no content. But you're right, it's a bad idea.
That's true, but in the case of OpenGL, the real format used in the GPU buffer is opaque and driver-specific, so we need to do format conversions anyway. It does make more sense to force the client to use the format we pick though. |
|
Ping? |
|
👍 |
There was a problem hiding this comment.
Why are ready and flags two events? I couldn't figure that out from the commit message.
If there's a output transform in place would you return the transformed or untransformed output. Untransformed is IMHO o.k. since the client can get the transform from the output but it should be probably be noted in the protocol.
| <description summary="manager to inform clients and begin capturing"> | ||
| This object is a manager which offers requests to start capturing from a | ||
| source. | ||
| </description> |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
If we differentiate this it would probably be at the export-dmabuf level, since the latter is more specific. As for screenshooter I think we can consider screenshooter obsoleted by this protocol.
|
I don't get why you want clients to supply their own buffer. Just leave it to clients to get an allocated buffer and refcount it themselves if they have to. |
What do you mean?
I wanted not to pollute the ready event with flags.
Yeah, that's how clients are supposed to do. Same for scale. |
|
On Fri, Jun 29, 2018 at 01:46:56AM -0700, emersion wrote:
[..snip..]
Untransformed is IMHO o.k. since the client can get the transform from
the output but it should be probably be noted in the protocol
Yeah, that's how clients are supposed to do. Same for scale.
Thought so. I'd just add a note to the protocol description about it.
|
|
Can't clients directly get a wl_buffer without the request? |
No, they can't read a compositor-supplied wl_buffer. wl_buffer is designed to be client-side allocated. |
Capture views (waiting to know A DMA-BUF export protocol #11's approach)not yetCapture other stuff (e.g. sway workspaces/containers)Fixes #16