Hi,
I have find myself needing this in order to make sure that wl_buffers
are destroyed when the wl_surface is, but not before the compositor
releases them.
So, the client app would be calling wl_surface_destroy, but as the
front wl_buffer is still in use by the compositor, the EGL
implementation
(I hope you don't remind me replying to the whole list.)
Marc Chalain writes:
> I'm not really agree about Mesa. In my mind it isn't a simple client,
> it's a library with parts of wayland. I'm not sur that simple clients
> need to know the main queue. But I agree with you about the headers.
I
Hi,
Marc Chalain writes:
> I wonder if there isn't a problem when some client application uses
> this function from a child thread. If I remember, only the main thread
> must use the main queue. If you give an API to use it, developers will
> want to use it, and may not understand the usage.
I
Hello,
I wonder if there isn't a problem when some client application uses this
function from a child thread. If I remember, only the main thread must use
the main queue. If you give an API to use it, developers will want to use
it, and may not understand the usage.
I read your patch about EGL_WL_c
Adds a function called wl_display_get_main_queue which just returns a
pointer to the default event queue. This will be useful in order to
implement the EGL_WL_create_wayland_buffer_from_image extension. The
buffers created within Mesa's Wayland platform are created using the
the wl_drm object as a
