Re: input handlig in separate thread

2013-10-24 Thread Kristian Høgsberg
Yes, this won't work property unless you have wayland 1.2. If you have a EGL driver that uses it's own queue, all you need to do is while (!quit) wl_display_dispatch(display); Otherwise, create a queue and move the wl_registry object to it so that you get all events from all other objects

Re: input handlig in separate thread

2013-10-24 Thread Eugen Friedrich
Unfortunately the proposal with a separate queue does not work for the use case. i added the wl_seat object to is own event queue but dispatching this queue blocks the egl rendering currently we are still using wayland 1.05 so my hope is that with the wayland 1.3 and wl_display_prepare_read and wl_

Re: input handlig in separate thread

2013-10-21 Thread Kristian Høgsberg
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

Re: input handlig in separate thread

2013-10-21 Thread Eugen Friedrich
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 fu

Re: input handlig in separate thread

2013-10-21 Thread Kristian Høgsberg
On Sat, Oct 19, 2013 at 10:31 AM, Eugen Friedrich 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 th

Re: input handlig in separate thread

2013-10-20 Thread Eugen Friedrich
2013/10/20 Bill Spitzak > On 10/19/2013 10:03 AM, Eugen Friedrich wrote: > > Basically i would like to implement a thread(input thread) that should >> only dispatch incoming input events from wayland compositor when the >> rendering thread is idle and the input thread should sleep in wait for

Re: input handlig in separate thread

2013-10-20 Thread Bill Spitzak
On 10/19/2013 10:03 AM, Eugen Friedrich wrote: Basically i would like to implement a thread(input thread) that should only dispatch incoming input events from wayland compositor when the rendering thread is idle and the input thread should sleep in wait for events function(i think poll on wl_d

Re: input handlig in separate thread

2013-10-19 Thread Eugen Friedrich
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_d

Re: input handlig in separate thread

2013-10-19 Thread Eugen Friedrich
Hi Bill, 2013/10/18 Bill Spitzak > Giulio Camuffo wrote: > >> 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 http://wayland.freedesktop.**org/docs/html/chap-Library.** >> html#sect-Library-Client

Re: input handlig in separate thread

2013-10-19 Thread Giulio Camuffo
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 dispatc

Re: input handlig in separate thread

2013-10-18 Thread Bill Spitzak
Giulio Camuffo wrote: 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 http://wayland.freedesktop.org/docs/html/chap-Library.html#sect-Library-Client This brings up some questions I have had about making a complete wayland client. The do

Re: input handlig in separate thread

2013-10-18 Thread Eugen Friedrich
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 t

Re: input handlig in separate thread

2013-10-18 Thread Giulio Camuffo
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 : > 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

Re: input handlig in separate thread

2013-10-18 Thread Giulio Camuffo
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 http://wayland.freedesktop.org/docs/html/chap-Library.html#sect-Library-Client Giulio 2013/10/18 Eugen Friedrich : > Hallo dear Wayland developer, > > I thing i have a very common use case an

Fwd: input handlig in separate thread

2013-10-18 Thread Eugen Friedrich
Hallo Dear wayland developers, 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 - th

input handlig in separate thread

2013-10-18 Thread Eugen Friedrich
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 - thi