wayland: how should dispatch the default wayland display queue?

[Eugen Friedrich]

Hello Pekka,
now i have the complete picture,
the mentioned commit describes exactly the problem which was found by me.
we are still using wayland 1.3 version.

thanks a lot !!!





2014-07-30 8:38 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:

> On Tue, 29 Jul 2014 23:32:34 +0200
> Eugen Friedrich <friedrix at gmail.com> wrote:
>
> > 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
>
> Hmm, which version of libwayland are you using again?
>
> I am looking at wayland-client.c, and the client wl_display contains
> two queues: the default queue, and the internal display queue.
>
> All events on the wl_display object go to the internal display queue,
> and it seems that queue is dispatched always when any queue is
> dispatched. That means that wl_display.delete_id events would be handled
> regardless of which queue you dispatch.
>
> Before adding the internal queue for wl_display, libwayland-client
> indeed did rely on the app to dispatch the main queue regularly.
>
> So I'm not completely sure you absolutely have to regularly dispatch the
> default queue anymore, but if you want to be compatible with the older
> releases of libwayland, you definitely should dispatch it.
>
> Sorry I did not recall this earlier. For reference:
>
> http://cgit.freedesktop.org/wayland/wayland/commit/?id=b9eebce0aa5559855d835e403ba3bb5960baaadc
>
> This commit seems to have been put in after 1.4.0, so was released in
> Wayland 1.5.0.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140730/cae36c98/attachment-0001.html>