<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Generic dmabuf protocol"
href="https://bugs.freedesktop.org/show_bug.cgi?id=83881">83881</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>Generic dmabuf protocol
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>ppaalanen@gmail.com
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>weston
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr></table>
<p>
<div>
<pre>My branch at
<a href="http://cgit.collabora.com/git/user/pq/weston.git/log/?h=next">http://cgit.collabora.com/git/user/pq/weston.git/log/?h=next</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>