wayland: how should dispatch the default wayland display queue?

Eugen Friedrich friedrix at gmail.com
Tue Jul 29 14:32:34 PDT 2014


2014-07-29 20:19 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:

> On Tue, 29 Jul 2014 13:00:14 +0200
> Eugen Friedrich <friedrix at gmail.com> wrote:
>
> > 2014-07-28 12:29 GMT+02:00 Giulio Camuffo <giuliocamuffo at gmail.com>:
> >
> > > 2014-07-28 13:19 GMT+03:00 Daniel Stone <daniel at fooishbar.org>:
> > > > Hi Eugen,
> > > >
> > > > On 27 July 2014 22:16, Eugen Friedrich <friedrix at gmail.com> wrote:
> > > >>
> > > >> Hi Daniel,
> > > >>
> > > >> thanks, i understood we should add the wl_display_dispatch_pending
> call
> > > in
> > > >> the application
> > > >> there is currently no way to avoid this and basically it does not
> harm.
> > > >> I only wanted to understand if there is something missing.
> > > >
> > > >
> > > > Doing that is not enough. Firstly, it requires the application to do
> > > this,
> > > > or else EGL will break, which will make your stack appear broken with
> > > > different applications. Secondly, as an application may do this in
> any
> > > > thread, you could run into locking issues.
> > > >
> > > > wl_display_sync() does the following (paraphrased):
> > > >   callback = wl_display_roundtrip(); /* creates wl_callback object on
> > > > default queue */
> > > >   while (!callback_signalled)
> > > >       wl_display_dispatch(); /* dispatch default queue until callback
> > > > processed */
> > >
> > > Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :).
>
> Yeah. :-P
>
> So, wl_display_roundtrip() is the function you should never use
> inside an EGL implementation.
>
> > >
> > > >
> > > > This violates the rule that EGL must not intefere with the default
> queue
> > > -
> > > > meaning that the wl_callback object _cannot_ be placed on the main
> queue.
> > > >
> > > > In order to do this correctly, you will see Mesa does:
> > > >   callback = wl_display_roundtrip();
> > > >   wl_callback_set_queue(callback, internal_egl_queue);
> > > >   while (!callback_signalled)
> > > >       wl_display_dispatch_queue(internal_egl_queue);
> > > >
> > > > As with all objects created by your EGL implementation, the
> wl_callback
> > > > object must be moved to the queue immediately after it is created by
> > > > wl_display_roundtrip(). Doing this will ensure correctness and also
> not
> > > > require apps to be constantly dispatching the main queue. You can
> search
> > > the
> > > > Mesa codebase for uses of wl_display_roundtrip() to find some
> examples of
> > > > this pattern.
> > > >
> > > > Again - any object created by your EGL implementation that is not
> > > > immediately moved to your internal event queue is a bug.
> > > >
> > >
> > Understood and our driver is basically is very similar to mesa in this
> > respect but the wayland-compositor will send the delete_id event(delete
> the
> > wl_display_sync callback) which is always goes to the default queue
>  which
> > is in some applications not dispatched, therefore the memory consumption
> is
> > increasing in those applications.
> >
> > So as conclusion: each egl wayland client has to dispatch the default
> > display queue on there own!?
>
> Obviously. See
> http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c
> for a stand-alone example that uses only libwayland-client, and not
> a toolkit.
>
> How did your app connect to Wayland and create the wl_surface that
> EGL then targets in the first place?
>
> It simply cannot do that without dispatching the default event
> queue. All properly written Wayland apps do that. Dispatching must
> also be part of the main loop.
>
> at the initialization app does dispatch the default queue but not during
run time.

> I get a feeling there is something strange going on. What kind of
> app is this? Does it use a toolkit, or does it call
> libwayland-client directly? Is it perhaps running in an endless
> loop calling just GL functions and eglSwapBuffers but never any
> wayland functions?
>
yes, the last one, just calling GL and eglSwapBuffers,
for all input events it uses own queue and only this is dispatched.

So at the end we have a 3 queues:

- one for egl -> egl is taking care for dispatching

- one for input events -> app is taking care for dispatching

- one default queue -> no body, which is a bug since the wayland
  display was created by the app and app is responsible to dispatch this
  even the event on this are triggered by egl.

Will force application developers to include wl_display_dispatch_pending
in their main loop.

Thanks for the support, your comments are very welcome

I suppose one could do that mistake and never dispatch the main
> event queue if the app never does anything with input, but that is
> quite a special case. And in fact, it would not work right.
> Xdg_shell protocol (only if you run a desktop, though) has a
> ping-pong event/request that must be reacted to, otherwise the app
> is deemed unresponsive and handled specially, e.g. the window could
> be grayed out completely.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140729/0aa3ee72/attachment.html>


More information about the wayland-devel mailing list