input handlig in separate thread

Thu Oct 24 23:51:32 CEST 2013

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 in that queue, then do

  while (!quit)
    wl_display_dispatch_queue(display, queue);

Kristian

On Thu, Oct 24, 2013 at 1:58 PM, Eugen Friedrich <friedrix at gmail.com> wrote:
> 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_display_read_events api's i can solve this
> issue:
> so i maybe just repaid here my understanding how to use those api's in my
> input thread:
> while(!quit)//main loop
> {
>       while (wl_display_prepare_read(__display) != 0)
>           wl_display_dispatch_pending(__display);
>
>       wl_display_flush(display);
>       poll(fds, nfds, -1); //wait until new input event arrives
>       wl_display_read_events(__display);
>       wl_display_dispatch_pending(__display);
>
> }
> would this sequence be correct?
>
>
> 2013/10/22 Kristian Høgsberg <hoegsberg at gmail.com>
>>
>> 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.
>>
>> 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
>>
>> > 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
>> > > >
>> > >
>
>