[Wayland-bugs] [Bug 83881] New: Generic dmabuf protocol

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=83881

          Priority: medium
            Bug ID: 83881
          Assignee: wayland-bugs at lists.freedesktop.org
           Summary: Generic dmabuf protocol
          Severity: enhancement
    Classification: Unclassified
                OS: Linux (All)
          Reporter: ppaalanen at gmail.com
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: weston
           Product: Wayland

My branch at
http://cgit.collabora.com/git/user/pq/weston.git/log/?h=next
contains an experimental implementation of "zlinux_dmabuf" protocol (the "z"
means experimental).

This protocol allows clients to wrap a dmabuf into a wl_buffer, and push that
into the compositor for display. It is especially useful for video players
using hardware decoding, and we have code somewhere to use it in GStreamer. The
compositor then uses GBM to import that wl_buffer as a bo for compositing with
GL (via EGLImage) or direct scanout as a DRM FB object. We have demonstrated
this pipeline to work.

However, the protocol design is far far away from complete. Even the kernel
developers are still discussing, how cross-device support for dmabufs should
work, and what is the proper information split between the kernel and the user
space. How do you communicate, or even describe, things like tiling formats.

But, we should start from somewhere, and this task about pushing the user space
part forward a bit.

All the zlinux_dmabuf related patches, including some DRM backend stuff, should
be extracted from the 'next' branch and rebased on Weston master.

The next step is to add a round-trip to the wl_buffer factory protocol in
zlinux_dmabuf. The round-trip is needed, because there is no way to communicate
all dmabuf constraints from the compositor to a client before-hand. In fact,
there are existing APIs like EGL (the dmabuf import extension) that are based
on trial-and-error rather than knowing the constraints before-hand. The
constraints are simply too complicated and changing to be described in a
Wayland protocol extension.

When wrapping a dmabuf in a wl_buffer, the client should first send all dmabuf
data to the compositor. Then the compositor somehow (*furious hand-waving*)
determines if it can use the dmabuf at least in its fallback compositing path,
and sends a reply to the client. If the reply is "ok", then the client has a
wl_buffer it can use.

Note, that this round-trip happens only at the time the wl_buffer is being
created, and you can create multiple dmabuf-based wl_buffers with the same
round-trip, and do whatever else you want to do.

After that, we should try to get this into Weston upstream for more public
development, still as an experimental protocol that is subject to rewriting as
needed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20140915/c2ba7ae0/attachment-0001.html>