On Wed, 12 Sep 2018 08:30:55 +0200 Dirk Eibach <dirk.eib...@googlemail.com> wrote:
> Hi Pekka, > > > that would not involve Weston in any special way at all. Buffer > > allocation is usually done in the client any way the client wants. To > > ensure the buffer can be used by the compositor before you fill it with > > data, you would export your buffer as a dmabuf and use > > zwp_linux_dmabuf_v1 extension to send the buffer details to the Wayland > > compositor. If that succeeds, all is good and you can fill the buffer. > > After that, you have a wl_buffer you can attach to a wl_surface, and > > the compositor will just process it, even put it on a DRM plane > > bypassing compositing if possible. > > Thank you so much, that is exactly the information I needed. > Is the simple-dmabuf-v4l client an implementation of this principle? > So v4l2 offers an interface for passing the dmabuf. A v4l2 driver > would probably the right choice for my grabber anyway. Hi Dirk, yes, simple-dmabuf-v4l does exactly what I wrote in the above quote. However, it does not allocate from the GPU device or from the display device. Instead, it allocates from the V4L2 device and hopes that the compositor will be able to use the buffers. Quite likely the compositor can use the buffer, but they might not be fit for direct scanout which would mean that composite bypass is not possible in the compositor. FWIW, there is no general solution to the buffer allocation problem that would ensure the buffer is usable for all purposes you would hope it to be. There is work going on though: https://github.com/cubanismo/allocator Until that materializes, programs need to be smart about how to allocate and hope it will work. Thanks, pq
pgpUuCt3QOVe6.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel