Cannot integrate winit wayland backend into existing event loop

[mahkoh]

Description

To integrate, the event loop needs not only the wl_display but also the wl_event_queue used by winit so that it can call wl_display_prepare_read_queue before going to sleep. This requirement is described, for example, here: https://gitlab.freedesktop.org/wayland/wayland/-/blob/6137c8c21383d7ebb92cf3331be56ca0aecccd5d/src/wayland-client.c?page=2#L1863

But winit doesn't expose its wl_event_queue.

Debugging output

Window isn't shown unless you draw

• I understand that windows aren't shown on Wayland unless I draw and present to them.

Winit version

0.30.9

[kchibisov]

What stops you from creating your own queue and using non-blocking polling API in winit?

[kchibisov]

e.g.

loop {
  you_loop_logic(); // You enqueue into winit.
  winit.pump_events(Some(Duration::Zero));
  your_dispatch_pending(); // Dispatch whatever winit enqueued into your queue.
  // back to sleep.
}

[kchibisov]

As alternative, if you don't have a wayland event loop, but rather need to integrate its into some other loop that doesn't do any wayland, you can use as_fd on event loop, and integrate it into your own epoll. That's what smithay does for example. The FD is the winit's epoll.

[mahkoh]

This doesn't work. Please read the linked description as for why wl_display_prepare_read_queue must be used before going to sleep.

[mahkoh]

The FD is the winit's epoll.

My reply above was regarding your previous comments. I'll look into this as a possible solution.

[kchibisov]

I read and I don't understand why it doesn't work, since you just call to winit once you've done with the reading. It's the same as if you've polled it twice pretty much, just before going to sleep, you need to dispatch_pending and then call the prepare_read one more time, but yourself?

So you have your own queue, and then you have e.g. winit that you call occasionally and that it doesn't block, both are on the same thread. Like the logic is exactly:

 while (wl_display_prepare_read_queue(display, queue) != 0)
          wl_display_dispatch_queue_pending(display, queue);
  wl_display_flush(display);
 
  ret = poll(fds, nfds, -1);
  if (has_error(ret))
          wl_display_cancel_read(display);
  else
          wl_display_read_events(display);
 
  wl_display_dispatch_queue_pending(display, queue);
  winit.pump_events(); // Winit does all the logic you've mentioned again, but it doesn't block.
  wl_display_dispatch_queue_pending(display, queue); // In case winit enqueued something to you
  // You go back to YOUR `wl_display_prepare_read` and sleep.

Is there a flaw with that approach, it's essentially the same if you've just dispatched twice.

[mahkoh]

By the time your example code calls poll, there could be events in the winit wayland queue. Your use of wl_display_prepare_read_queue only ensures that my wayland queue is empty. Unless new events arrive on the file descriptor, poll will block indefinitely even though there are winit events to be dispatched.

I looked into the epoll suggestion and I believe it would fail for similar reasons. Polling the epoll fd will not signal readiness if the wayland fd is empty by the time I call poll on it.

[kchibisov]

Hm, yeah, if you integrate wayland event loop of winit into another wayland event loop on the same thread, I think it won't work, because you can not know about the state of the winit queue, so the option to either put winit into other thread or expose the queue so you can call the API yourself.

You can send a patch for that.

[mahkoh]

I don't believe the issue requires me to use wayland myself. AFAICT, winit already spawns a thread that reads from the wayland file descriptor for clipboard handling. This causes the same race.

You can send a patch for that.

AFAICT, smithay doesn't expose the queue pointer.

[kchibisov]

I don't believe the issue requires me to use wayland myself. AFAICT, winit already spawns a thread that reads from the wayland file descriptor for clipboard handling. This causes the same race.

It doesn't use clipboard, and that aside it would imply that all wayland code is broken (mesa/etc, since we all do the exact same thing, and yes no-one accepts the queue in any API).

The way winit uses the queue is exactly the way you've specified, and the clipboard uses the exact same loop, but on the other thread, so I don't see how it can fail, according to the link you've provided, since we use it exactly how it's documented.

[kchibisov]

The code for what you've described is located there and is used by both clipboard(I'd assume you mean smithay-clipboard of latest versions) and winit https://github.com/Smithay/calloop-wayland-source/blob/main/src/lib.rs#L183

If we do something wrong, let me know, but we call prepare_read before sleep, and if it fails, we instantly wake-up without blocking, dispatch everything and try again.

[mahkoh]

It doesn't use clipboard

Maybe it's being created by egui.

it would imply that all wayland code is broken (mesa

Mesa does not rely on events being dispatched immediately. Mesa is driven entirely in response to application actions and never in response to events that the application doesn't know about. E.g. it only needs to know about frame events when the client actually calls into mesa to acquire the next image. At that point is can dispatch its event queue.

The way winit uses the queue is exactly the way you've specified

The blocking winit API is fine. But if you integrate the winit epoll fd into an event loop, without any wayland, then, after winit returns and before you call poll, the clipboard thread might read events into the winit wayland queue.

[kchibisov]

The blocking winit API is fine. But if you integrate the winit epoll fd into an event loop, without any wayland, then, after winit returns and before you call poll, the clipboard thread might read events into the winit wayland queue.

And winit won't block in that way, since it tries to call prepare_read, fail, and dispatch instantly, since it fails if its queue is non-empty.