zwp_linux_dmabuf_v1 protocol
#318
Conversation
ids1024
force-pushed
the
dmabuf
branch
6 times, most recently
from
88d9e21 to
cd7e7f5
Compare
|
Okay, this should be pretty complete now. I've made it require version 3, since that's what Mesa currently requires. It expects the application to handle both version 3 and 4. |
|
Oh I guess this should in some way handle |
|
Actually it might make sense to just take a generic I guess the data could be stored with the |
|
Added a |
|
I'm generally happy with the API here now, or in any case can't think of ways to improve it. |
| /// | ||
| /// In version `4`, it is a protocol error if `format`/`modifier` pair wasn't | ||
| /// advertised as supported. | ||
| pub fn add(&self, fd: BorrowedFd<'_>, plane_idx: u32, offset: u32, stride: u32, modifier: u64) { |
There was a problem hiding this comment.
This brings up a question. Should Smithay's Dmabuf type be put into another crate to allow both Smithay and sctk to have a DmabufBuilder and the Weak/Strong dmabuf types?
Although if we do that, Smithay's current use of dmabuf is very graphics api dependent (remember a dmabuf is just a memory object that is given meaning by a format, stride, plane count and modifiers).
There was a problem hiding this comment.
In that case we could get rid of the DmabufParams type and have create and create_immed methods of DmabufState that take a Dmabuf. This could be useful in some cases. Though maybe not most.
These functions would still have to deal with the protocol error if the format/modifier wasn't advertised.
Normally on the client-side this is handled by Mesa, but an implementation is necessary for using screencopy, for instance. This required at least version 3, which seems reasonable since that is the same version Mesa currently requires. Applications using this will need to handle both version 3 and version 4.
An implementation of this protocol is useful with the screencopy protocol.
The implementation here is incomplete, in particular the dmabuf feedback code. Only implementing version 3, without that makes this simpler, but presumably that mechanism is useful if complicated where supported by the compositor.