[Bug 711155] wayland: add wl_drm support to wayland sink

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=711155

--- Comment #27 from George Kiagiadakis <george.kiagiadakis at collabora.com> ---
As I understand it, after Daniel's comments here and on irc, this wayland-EGL
method is something private between mesa and the compositor *only*. So, we
don't have to consider this case, but this doesn't change anything in the
design actually.

The point that I see and needs discussion, though, is dmabuf allocation. There
are 2 potential ways to do this:

1) Use a hardware decoder or camera that gives us dmabuf (in gstreamer it would
mean bufers are allocated and pushed from v4l2dec/src)
2) Use "generic dumb buffers", which are allocated from DRM and according to
the graphics people, it's the client (gstreamer) that should allocate them.
Supposing we do this in waylanddmabufsink, then this sink would propose a pool
that allocates buffers using libdrm basically.

The problem is, you cannot mix dumb buffers with hw decoder/camera buffers, and
they are not the same in terms of acceleration. Dumb buffers are still not an
accelerated path, they just avoid the GPU upload that needs to happen in
glTexImage2D.

So basically there are 4 paths to consider when the platform is wayland:

1) if there is a hw decoder/camera (v4l2), upstream pushes dmabuf to
waylandsink and they are sent as is to the compositor
2) if this is not the case (or fails), allocate dumb dmabufs from the sink and
let upstream render into them (which is faster than using glupload /
glTexImage2D)
3) if dmabuf doesn't work, use glupload / glimagesink
4) if all else fails, use wl_shm (what the existing waylandsink does), which is
the worst method (equivalent to ximagesink)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.