<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-29 20:19 GMT+02:00 Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Tue, 29 Jul 2014 13:00:14 +0200<br>
Eugen Friedrich <<a href="mailto:friedrix@gmail.com" target="_blank">friedrix@gmail.com</a>> wrote:<br>
<br>
> 2014-07-28 12:29 GMT+02:00 Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>>:<br>
><br>
> > 2014-07-28 13:19 GMT+03:00 Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>>:<br>
> > > Hi Eugen,<br>
> > ><br>
> > > On 27 July 2014 22:16, Eugen Friedrich <<a href="mailto:friedrix@gmail.com" target="_blank">friedrix@gmail.com</a>> wrote:<br>
> > >><br>
> > >> Hi Daniel,<br>
> > >><br>
> > >> thanks, i understood we should add the wl_display_dispatch_pending call<br>
> > in<br>
> > >> the application<br>
> > >> there is currently no way to avoid this and basically it does not harm.<br>
> > >> I only wanted to understand if there is something missing.<br>
> > ><br>
> > ><br>
> > > Doing that is not enough. Firstly, it requires the application to do<br>
> > this,<br>
> > > or else EGL will break, which will make your stack appear broken with<br>
> > > different applications. Secondly, as an application may do this in any<br>
> > > thread, you could run into locking issues.<br>
> > ><br>
> > > wl_display_sync() does the following (paraphrased):<br>
> > > callback = wl_display_roundtrip(); /* creates wl_callback object on<br>
> > > default queue */<br>
> > > while (!callback_signalled)<br>
> > > wl_display_dispatch(); /* dispatch default queue until callback<br>
> > > processed */<br>
> ><br>
> > Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :).<br>
<br>
</div>Yeah. :-P<br>
<br>
So, wl_display_roundtrip() is the function you should never use<br>
inside an EGL implementation.<br>
<div><br>
> ><br>
> > ><br>
> > > This violates the rule that EGL must not intefere with the default queue<br>
> > -<br>
> > > meaning that the wl_callback object _cannot_ be placed on the main queue.<br>
> > ><br>
> > > In order to do this correctly, you will see Mesa does:<br>
> > > callback = wl_display_roundtrip();<br>
> > > wl_callback_set_queue(callback, internal_egl_queue);<br>
> > > while (!callback_signalled)<br>
> > > wl_display_dispatch_queue(internal_egl_queue);<br>
> > ><br>
> > > As with all objects created by your EGL implementation, the wl_callback<br>
> > > object must be moved to the queue immediately after it is created by<br>
> > > wl_display_roundtrip(). Doing this will ensure correctness and also not<br>
> > > require apps to be constantly dispatching the main queue. You can search<br>
> > the<br>
> > > Mesa codebase for uses of wl_display_roundtrip() to find some examples of<br>
> > > this pattern.<br>
> > ><br>
> > > Again - any object created by your EGL implementation that is not<br>
> > > immediately moved to your internal event queue is a bug.<br>
> > ><br>
> ><br>
> Understood and our driver is basically is very similar to mesa in this<br>
> respect but the wayland-compositor will send the delete_id event(delete the<br>
> wl_display_sync callback) which is always goes to the default queue which<br>
> is in some applications not dispatched, therefore the memory consumption is<br>
> increasing in those applications.<br>
><br>
> So as conclusion: each egl wayland client has to dispatch the default<br>
> display queue on there own!?<br>
<br>
</div>Obviously. See<br>
<a href="http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c" target="_blank">http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c</a><br>
for a stand-alone example that uses only libwayland-client, and not<br>
a toolkit.<br>
<br>
How did your app connect to Wayland and create the wl_surface that<br>
EGL then targets in the first place?<br>
<br>
It simply cannot do that without dispatching the default event<br>
queue. All properly written Wayland apps do that. Dispatching must<br>
also be part of the main loop.<br>
<br></blockquote><div>at the initialization app does dispatch the default queue but not during run time.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I get a feeling there is something strange going on. What kind of<br>
app is this? Does it use a toolkit, or does it call<br>
libwayland-client directly? Is it perhaps running in an endless<br>
loop calling just GL functions and eglSwapBuffers but never any<br>
wayland functions?<br></blockquote><div>yes, the last one, just calling GL and eglSwapBuffers, </div><div>for all input events it uses own queue and only this is dispatched.</div><div><br></div><div>So at the end we have a 3 queues:</div>
<div><br></div>
<div>- one for egl -> egl is taking care for dispatching</div><div><br></div><div>- one for input events -> app is taking care for dispatching</div><div><br></div><div>- one default queue -> no body, which is a bug since the wayland</div>
<div> display was created by the app and app is responsible to dispatch this</div><div> even the event on this are triggered by egl. </div><div><br></div><div>Will force application developers to include wl_display_dispatch_pending</div>
<div>in their main loop.</div><div><br></div><div>Thanks for the support, your comments are very welcome</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I suppose one could do that mistake and never dispatch the main<br>
event queue if the app never does anything with input, but that is<br>
quite a special case. And in fact, it would not work right.<br>
Xdg_shell protocol (only if you run a desktop, though) has a<br>
ping-pong event/request that must be reacted to, otherwise the app<br>
is deemed unresponsive and handled specially, e.g. the window could<br>
be grayed out completely.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div></div>