Wayland panic with renderer

[rukai]

• OS: Arch Linux
• Compositor: Weston
• Graphics card (from lspci): Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445]
• Same error on both Vulkano and glium/glutin
• Running winit examples without attaching a renderer is fine, as expected, there is no window
• Introduced by: 8d5b23d
• Found by manually pointing vulkano/glium/glutin to use the latest winit commit.

Vulkano triangle.rs gives me:

    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `/home/rubic/Projects/RustExamples/vulkano/target/debug/triangle`
WARNING: radv is not a conformant vulkan implementation, testing use only.
wl_drm.device(/dev/dri/card0)
zxdg_surface_v6@20: error 3: xdg_surface has never been configured
thread 'main' panicked at 'Wayland connection unexpectedly lost: Error { repr: Os { code: 71, message: "Protocol error" } }', /checkout/src/libcore/result.rs:860
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:471
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:69
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:29
  10: <core::result::Result<T, E>>::expect
             at /checkout/src/libcore/result.rs:762
  11: winit::platform::platform::wayland::event_loop::EventsLoop::poll_events
             at /home/rubic/Projects/RustExamples/winit/winit/src/platform/linux/wayland/event_loop.rs:194
  12: winit::platform::platform::EventsLoop::poll_events
             at /home/rubic/Projects/RustExamples/winit/winit/src/platform/linux/mod.rs:377
  13: winit::EventsLoop::poll_events
             at /home/rubic/Projects/RustExamples/winit/winit/src/lib.rs:211
  14: triangle::main
             at ./triangle.rs:465
  15: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  16: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  17: main
  18: __libc_start_main
  19: _start

Maybe this is of interest to @vberger

[elinorbgr]

Hmm. Ok, I think I have an idea of what's going on. I'll investigate this.

[elinorbgr]

Ok, I can reproduce this with glium. Interestingly, this does not happen with glutin's examples. It must be why I didn't catch this issue at first.

[elinorbgr]

Okay. So. When using xdg_shell, we need to wait until the compositor sends an event basically saying "okay, you can draw now" before trying to attach any buffer to the surface (this includes doings some kind of swap_buffers and firends).

Looks like I've been a little too optimistic regarding when this event can be received. Apparently the real good answer to this question is "Just wait for it.".

I see mostly two ways to handle this:

• introduce a Ready event, and document that no drawing should be done before this event is received (initializing a context is fine though, I think, just no swap_buffers or its vulkan equivalent). This event would likely be directly generated at creation on most platforms.
• Add a is_ready() method to windows, and make glutin silently ignore .swap_buffers() calls as long as this flag is not true (and equivalently for the vulkan wrapper, if it is possible ?). This flag would likely be always true on most platforms.

The first solution is clean and direct, but requires adaptation from the users of winit/glutin/glium/vulkano. The second is a little hacky, but things would work "out of the box" in most cases.

Thoughts regarding this, @tomaka ?

[tomaka]

I suppose that blocking Window::new() until the event is received is a bad idea?

attach any buffer to the surface (this includes doings some kind of swap_buffers and firends).

Does that include creating an OpenGL context or a Vulkan surface/swapchain? Or is it just swap_buffers/queue_present?

[elinorbgr]

My understanding is that only the swap_buffers() or equivalent is problematic, I'm not 100% certain though.

Having Window::new() block can be an issue, because several unrelated events can be sent by the server before the event marking readiness arrives. Most of them are internal events that are not exposed by winit and would thus be properly handled.

However, any exposed event received during this process would be lost (this could happen in multiwindow setups for example), unless we introduce something to buffer the received events and release them the next time the user ticks the events loop, which is also entirely possible.

[Ralith]

unless we introduce something to buffer the received events and release them the next time the user ticks the events loop, which is also entirely possible.

If winit ever switches back to fn poll(&self) -> Option<Event> as has been discussed some, this will typically be necessary anyway.

[elinorbgr]

Fair point. I'll try this an see if it introduces any unexpected issues. If not, it would certainly be the less intrusive solution.

My main worry is that there is no real telly how long we may wait for this event to show up.

[xyproto]

I get a similar error message for simple use of SDL2 under Wayland, but only if SDL_VIDEODRIVER=wayland is set. After unset SDL_VIDEODRIVER, I no longer get this error.