[PATCH] client: Add a way to get a pointer to the display's default queue

[Neil Roberts]

Hi,

Marc Chalain <marc.chalain at gmail.com> 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 don't think the new function adds any extra concerns regarding
threading. Even without the function it is still possible for a second
thread to use the main event queue indirectly via the normal
wl_display_dispatch function and friends.

> I read your patch about EGL_WL_create_wayland_buffer_from_image , it's
> simpler to use directly &display->queue , isn't it ?
>
> Or it may be inserted inside wayland_private.h , and to use this file
> inside mesa eglwayland. (The architecture is complex, with eglwayland
> outside wayland).

I think it is meant to be designed such that Mesa is just a user of the
Wayland API. Therefore if Mesa needs to start prodding into the
implementation that implies the API is missing something that upper
layers might need and we should try to fix it instead of working around
it. I think it could quickly get out of hand if we have to maintain a
copy of the internal Wayland headers outside of the Wayland repo.

Perhaps you could argue that Wayland should be using the default main
queue for all new proxy objects instead of copying it from the proxy
factory. The client can always set the proxy to whatever it wants later
anyway. Mesa doesn't seem to rely on this behaviour because it always
explicitly sets the event queue on its objects anyway. I guess it's too
late to break the client API though so that isn't really an option.

Regards,
- Neil
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.