input handlig in separate thread
Eugen Friedrich
friedrix at gmail.com
Mon Oct 21 23:32:58 CEST 2013
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.
2013/10/21 Kristian Høgsberg <krh at bitplanet.net>
> On Sat, Oct 19, 2013 at 10:31 AM, Eugen Friedrich <friedrix at gmail.com>
> 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 <giuliocamuffo at gmail.com>
> >>
> >> 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 <friedrix at gmail.com>:
> >> > 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 <giuliocamuffo at gmail.com>
> >> >>
> >> >> 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 <giuliocamuffo at gmail.com>:
> >> >> > 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 <friedrix at gmail.com>:
> >> >> >> 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
> >> >> >> wayland-devel at lists.freedesktop.org
> >> >> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >> >> >>
> >> >
> >> >
> >
> >
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131021/13c3b8e7/attachment-0001.html>
More information about the wayland-devel
mailing list