[weston 1/2] linux-dmabuf: implement immediate dmabuf import

Pekka Paalanen pekka.paalanen at collabora.co.uk
Fri Jan 27 13:02:49 UTC 2017

On Mon, 21 Nov 2016 21:27:03 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Varad,
> On 11 November 2016 at 11:40, Varad Gautam <varadgautam at gmail.com> wrote:
> > handle create_immed() dmabuf import requests and support
> > zwp_linux_dmabuf_v1_interface version 2.  
> Same caveat about holding off on merging applies, but these two patches are:
> Reviewed-by: Daniel Stone <daniels at collabora.com>


yeah, the Weston patch v1 is probably good, considering my review on
the protocol patch v2 essentially asking to go back to the v1 with just
some wording added.

However, it would be good to check and ensure what happens in Weston
when a client uses a wl_buffer that has failed the dmabuf import. I
suspect you would need to add some checks somewhere depending on what
Weston will do.

I think we pretty much agreed that Weston will just send a fatal error
to the client if it commits a failed wl_buffer.

How to recognize a failed wl_buffer then... maybe NULL user data on the
wl_resource? Then there will be places that need to check for NULL: the
commit machinery and destructor come to mind.

Whatever Weston does, it cannot avoid creating the wl_resource. It must
be created, if the protocol XML says a new object is created. And for
'create_immed' request, a new object is created. This is probably
overlooked in patch v1.


More information about the wayland-devel mailing list