10:31 <Vanfanel> !who

11:05 <Vanfanel> kennylevinsen: I have another small problem (the last one I hope). If I call wl_display_dispatch() after calling wl_display_prepare_read_queue(), then wl_display_dispatch() blocks forever.

11:05 <Vanfanel> As in: https://github.com/vanfanel/RetroArch/blob/8a28b469d952f89d6ab0ebab27e4b1aa2ab7be32/gfx/drivers_context/wayland_ctx.c#L536

11:05 <Vanfanel> In theory, wl_display_dispatch() blocks forever if there are no new events to process, but shouldn't the previous eglSwapBuffers() produce an event to be processed?

11:48 <daniels> Vanfanel: no because it uses a dedicated queue

11:49 <daniels> please see the wl_display_prepare_read_queue docs

11:49 <daniels> you can’t just use a random throwaway queue but you need a real queue and need to use it consistently, and you also need the loop in the code snippet in the docs

11:50 <Vanfanel> daniels: do you mean eglSwapBuffers() uses a dedicated queue?

11:51 <kennylevinsen> yes, in order to never dispatch your events as this would cause issues

11:53 <Vanfanel> Ok, what code snippet should I look at? This one? --> https://wayland.freedesktop.org/docs/html/apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0

11:56 <Vanfanel> My understanding is that the wl_display already has a queue, because wl_display_dispatch() doesn't block forever unless I call wl_display_prepare_read_queue() previously.

11:56 <Vanfanel> Isn't it possible to simply use that default queue?

11:57 <daniels> yeah, if you’re on the default queue then use wl_display_prepare_read with no queue arg

11:58 <daniels> and also do the read on the fd, and the loop, and the dispatch_pending

11:58 <daniels> either do that loop as in the docs, or just run wl_display_dispatch in a loop

11:58 <daniels> don’t mix and match the two things

12:09 <Vanfanel> daniels: First problem I am encountering is that passing NULL as second argument to wl_display_prepare_read_queue() causes a segfault. Of course, the wl_display is initialized and working. Any idea om why could that be happening? That should use the default wl_display queue, shouldn't it?

12:11 <Vanfanel> Maybe I understood it wring but, how am I supposed to use wl_display_prepare_read with no queue arg?

12:11 <Vanfanel> I mean, a second arg is needed.

12:14 <daniels> Vanfanel: no, I literally mean wl_display_prepare_read(), which does not take a queue arg. you use this if you are using the default queue. the _queue() variant is only usable if you have a queue you’ve created and your events are going to (you do not)

12:14 <daniels> but this is _still_ wrong, though less wrong. just call wl_display_dispatch() in a loop until you get your event. do not call prepare_read without reading from the fd

12:14 <Vanfanel> Ah sorry, thanks for your patience really

12:14 <daniels> np

12:21 <Vanfanel> daniels: I think I am doing exactly what you told me: I call prepare_read, then poll on the fd, then display_displatch() in a loop: https://github.com/vanfanel/RetroArch/blob/3c6c272c37d561f380a369c3c1b39323c4dc24df/gfx/drivers_context/wayland_ctx.c#L546

12:21 <Vanfanel> However, display_dispatch() still blocks forever. Can you see anything wrong, please?

12:52 <daniels> Vanfanel: missing wl_display_flush

12:53 <daniels> but also - just delete the prepare_read and the read - you don’t need those here, only dispatch

12:53 <daniels> so: add flush, remove prepare_read, remove poll/read, keep dispatch

12:54 <Vanfanel> daniels: that works, but I need the poll() to have a timeout. Maybe there's a better way to have a timeout?

12:56 <daniels> ok, in that case remove the dispatch, and copy the loop exactly from the prepare_read_queue doc

12:56 <daniels> you _must_ do those calls in that order

12:58 <daniels> like, exactly those

15:05 <Vanfanel> daniels: got it to work! Thanks a lot! :)

16:21 <daniels> Vanfanel: great! np