<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Generic dmabuf protocol" href="https://bugs.freedesktop.org/show_bug.cgi?id=83881#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Generic dmabuf protocol" href="https://bugs.freedesktop.org/show_bug.cgi?id=83881">bug 83881</a> from <a class="email" href="mailto:nicolas.dufresne@collabora.co.uk" title="Nicolas Dufresne <nicolas.dufresne@collabora.co.uk>"> Nicolas Dufresne</a> <pre>(In reply to Benjamin Gaignard from <a href="show_bug.cgi?id=83881#c6">comment #6</a>) > Which GStreamer video sink do you use as client ? > How do you allocate the buffers in this sink ? The GStreamer part should probably be discussed here. <a href="https://bugzilla.gnome.org/show_bug.cgi?id=711155">https://bugzilla.gnome.org/show_bug.cgi?id=711155</a> I'll try to comment base on what should concern wayland, adding a little context. In GStreamer there will is two possible display element working on Wayland, glimagesink and waylandsink. glimagesink uses client side EGL/OpenGL/GLES2 to render the video. It will most likely never allocated DMABUF, but will most likely be able to import them. This can already be implemented without any changes to current Wayland protocols. waylansink, uses wayland specific representation for wrapping video memory. It's a smarter choice, since it gives the compositor the choices of the smartest renderer. Adding DMABUF in this case requires protocols. The patches submitted at the beginning of the year were not merged because of open issues, including usage of driver specific APIs and that this new protocol was still changing very quickly. What has been proposed to Benjamin was to focus on getting importation of DMABUF first, and come back with allocation when this problem get resolved in a better way. The allocation of DMABUF remains an open issue for everyone. A small comment though, if we want this work to be usable in waylansink. By it's nature, the alignment of a DMABUF frame received might not match the required alignment by the GPU or HW mixer, or any HW involved. A miss-match should never prevent the rendering of a buffer unless the buffer is not mappable to user space. This is often not so simple as only kernel space can figure-out there is a miss-match (at least at the moment). It is important to handle this nicely and manage non-destructive fallback.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>