wayland: how should dispatch the default wayland display queue?

[Pekka Paalanen]

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.

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?

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