Wayland client library thread safety

Arnaud Vrac rawoul at gmail.com
Fri Apr 20 09:58:11 PDT 2012

On Fri, Apr 20, 2012 at 6:33 PM,  <darxus at chaosreigns.com> wrote:
> I guess you're not going to get a useful response here.
> That seems really unfortunate to me.  Please open a bug
> here, so we at least have a proper record of the problem:
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland

Thanks darxus, I don't mind posting a bug bug is anyone actually going
to use this bugtracker ? It's empty :)

> On 04/19, Arnaud Vrac wrote:
>> Hello everyone,
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backend. The problem is that Qt5
>> (QtQuick2 actually) renders in a separate thread, when the wayland
>> display has been created in the main thread. I know there is a patch
>> for "thread affinity" in qtwayland to solve this, but it is wrong and
>> breaks other clients.
>> Since it is required from the EGL spec to be able to render in
>> multiple threads, how can this be solved ? Does the wayland backend
>> for mesa support this properly ? I don't see how it can work since
>> even writes in the connection queue are not protected.
>> Here is a crude extract from my EGL backends where wayland can fail
>> because of thread concurrency:
>> - SwapBuffers:
>> while (!swap_done) {
>>   wl_display_flush()
>>   // wait frame callback
>>   wl_display_iterate(WL_DISPLAY_READABLE)
>> }
>> wl_surface_frame()
>> wl_surface_attach()
>> wl_surface_damage()
>> lock_back_buffer()
>> swap_buffers()
>> - GetBuffers (called on makeCurrent or at the first gl call after swap)
>> while (no_buffer_unlocked)
>>   wl_display_flush()
>>   // wait for a buffer to be released
>>   wl_display_iterate(WL_DISPLAY_READABLE)
>> }
>> Thanks for your help,


More information about the wayland-devel mailing list