<div dir="ltr">Unfortunately the proposal with a separate queue does not work for the use case.<div>i added the wl_seat object to is own event queue but dispatching this queue blocks the egl rendering</div><div>currently we are still using wayland 1.05 so my hope is that with the wayland 1.3 and </div> <div>wl_display_prepare_read and wl_display_read_events api's i can solve this issue:</div><div>so i maybe just repaid here my understanding how to use those api's in my input thread:</div> <div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.727272033691406px">while(!quit)//main loop { </div> while (wl_display_prepare_read(__display) != 0) wl_display_dispatch_pending(__display);<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.727272033691406px"> wl_display_flush(display); poll(fds, nfds, -1); //wait until new input event arrives </div> wl_display_read_events(__display); wl_display_dispatch_pending(__display);<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.727272033691406px"> }</div></div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.727272033691406px">would this sequence be correct?</div></div><div class="gmail_extra"> <div class="gmail_quote">2013/10/22 Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Oct 21, 2013 at 11:32:58PM +0200, Eugen Friedrich wrote: > Hello Kristian, > I'm don't using mesa, we have a Vivante driver stack on imx6 which also > uses a proprietary wayland protocol to send a buffer to the compositor > and it's EGL implementation don't creates a separate event queue it uses > the main wayland display queue and will call wl_display_dispatch function. > But thanks for the hint, i suppose the current mesa implementation should > answer all my questions above. </div>That explains it. The separate event queue feature is generally useful, but it was prompted by the requirement to make EGL threading work right under Wayland. As such, the Vivante driver really should use it to make sure it doesn't inadvertently block on the main thread. In the mean time you can probably work around it by creating a separate event queue for everything else you do in your application. Kristian <div class="HOEnZb"><div class="h5"> > 2013/10/21 Kristian Høgsberg <<a href="mailto:krh@bitplanet.net">krh@bitplanet.net</a>> > > > On Sat, Oct 19, 2013 at 10:31 AM, Eugen Friedrich <<a href="mailto:friedrix@gmail.com">friedrix@gmail.com</a>> > > wrote: > > > Ok! this sounds very promising this should decouple the rendering thread > > > and the input handling thread. > > > so i can set to the wl_seat client object a new queue and then pass this > > > queue to wl_display_dispatch_queue call in the input thread. > > > > > > but one question to this: the documentation of wl_display_dispatch_queue > > > says: > > > "For other threads this will block until the main thread queues events on > > > the queue passed as argument." > > > > > > So will pass the events in the queue or how to achieve this it the second > > > thread( rendering thread is sleeping)?? > > > > > > In my use case the input thread should wake up when input event arrives > > from > > > the compositor also when all other thread of the client are idle. > > > > None of this should be necessary. The EGL implementation already uses > > its own queue (if your mesa is new enough) and should be able to loop > > all by itself without the main event queue being processed. You can > > still use a custom queue for your input events, but if you only care > > about separating EGL into a separate thread, you shouldn't need to do > > anything. > > > > Kristian > > > > > 2013/10/19 Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> > > >> > > >> You can move a client-side wayland object to a queue using the function > > >> void wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue > > >> *queue). > > >> All the client-side objects are really wl_proxy, so you can safely cast > > >> them. > > >> If you move to a queue an object which creates new objects and > > >> dispatches them through > > >> an event those objects will be in the same queue too. > > >> > > >> > > >> 2013/10/18 Eugen Friedrich <<a href="mailto:friedrix@gmail.com">friedrix@gmail.com</a>>: > > >> > Hallo Giulio, > > >> > thanks a lot for the fast replay. > > >> > > > >> > if my understanding is correct the frame callbacks and the input > > >> > handling > > >> > events are coming from the compositor to the main wayland display > > queue > > >> > on > > >> > the client side. > > >> > So how i can get the different queues on the client site or is there a > > >> > possibility to get a separate queue for input events? > > >> > > > >> > > > >> > 2013/10/18 Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> > > >> >> > > >> >> Oh, I sent my mail before the second one arrived. > > >> >> > > >> >> Yeah, you need to use different wl_event_queues, and the relative > > >> >> functions like > > >> >> wl_display_dispatch_queue. > > >> >> > > >> >> 2013/10/18 Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>>: > > >> >> > And what is it that doesn't work? As a wild bet I'd say you > > probably > > >> >> > want to look at wl_event_queue. > > >> >> > See > > >> >> > > > >> >> > > > <a href="http://wayland.freedesktop.org/docs/html/chap-Library.html#sect-Library-Client" target="_blank">http://wayland.freedesktop.org/docs/html/chap-Library.html#sect-Library-Client</a> > > >> >> > > > >> >> > Giulio > > >> >> > > > >> >> > 2013/10/18 Eugen Friedrich <<a href="mailto:friedrix@gmail.com">friedrix@gmail.com</a>>: > > >> >> >> Hallo dear Wayland developer, > > >> >> >> > > >> >> >> I thing i have a very common use case and currently i don't now > > how > > >> >> >> to > > >> >> >> get > > >> >> >> it work in wayland. > > >> >> >> > > >> >> >> We have a wayland client application with 2 threads: > > >> >> >> > > >> >> >> thread1 - rendering thread - the eglSwapbuffer will call > > >> >> >> wl_display_dispatch internally: > > >> >> >> thread2 - input thread - this should wait for wayland input events > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> _______________________________________________ > > >> >> >> wayland-devel mailing list > > >> >> >> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > > >> >> >> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > > >> >> >> > > >> > > > >> > > > > > > > > > > > > > _______________________________________________ > > > wayland-devel mailing list > > > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > > > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > > > > > </div></div></blockquote></div> </div>