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 <ppaala...@gmail.com>: > On Tue, 29 Jul 2014 23:32:34 +0200 > Eugen Friedrich <fried...@gmail.com> wrote: > > > 2014-07-29 20:19 GMT+02:00 Pekka Paalanen <ppaala...@gmail.com>: > > > > > On Tue, 29 Jul 2014 13:00:14 +0200 > > > Eugen Friedrich <fried...@gmail.com> wrote: > > > > > > > 2014-07-28 12:29 GMT+02:00 Giulio Camuffo <giuliocamu...@gmail.com>: > > > > > > > > > 2014-07-28 13:19 GMT+03:00 Daniel Stone <dan...@fooishbar.org>: > > > > > > Hi Eugen, > > > > > > > > > > > > On 27 July 2014 22:16, Eugen Friedrich <fried...@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 >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel