> -Original Message-
> From: Derek Foreman
> Sent: Wednesday, August 25, 2021 3:54 PM
> To: Hoosier, Matt ; wayland-
> de...@lists.freedesktop.org
> Subject: Re: Discrepancies in object IDs printed by $WAYLAND_DEBUG
> output
>
> CAUTION - EXTERNAL EMAIL: Do not click any links or open any
On 2021-08-25 3:08 p.m., Hoosier, Matt wrote:
I observe that the IDs used to denote some wl_buffer protocol objects
created by a server-side factory in the $WAYLAND_DEBUG trace, differ
between the moment they're first announced in the callback event and
the later use-sites when the objects are
I observe that the IDs used to denote some wl_buffer protocol objects created
by a server-side factory in the $WAYLAND_DEBUG trace, differ between the moment
they're first announced in the callback event and the later use-sites when the
objects are passed to subsequent Wayland protocol method in
Thanks.
On 8/25/21, 11:16 AM, "Simon Ser" wrote:
CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments
unless you trust the sender and know the content is safe.
Yeah, you should be able to just destroy it right after create or
create_immed.
__
Yeah, you should be able to just destroy it right after create or
create_immed.
It's not totally clear from the documentation on linux-dmabuf-unstable-v1.xml
whether there's any need to keep the buffer-params object alive past the time
that create_immed() is used. The example programs in the Weston repository
don't bother to deallocate it at all in this case, but there does
