Add support for XCB

[tomaka]

No description provided.

[kvark]

Some machines don't support VK_KHR_xlib_surface but do support VK_KHR_xcb_surface, so this is a compatibility concern:

Instance Extensions     count = 3
        VK_KHR_surface                  : extension revision 25
        VK_KHR_xcb_surface              : extension revision  5
        VK_EXT_debug_report             : extension revision  2

[kvark]

Found this library as a potential workaround: https://github.com/Aatch/rust-xcb

[nicokoch]

Just a heads up for anyone searching a workaround.

The intel linux driver does indeed support xlib, but it has to be enabled at compile time.
You can compile the vulkan driver yourself with VK_KHR_xlib_surface enabled by enabling
-DVK_USE_PLATFORM_XLIB_KHR.

For anyone using archlinux, I have submitted a feature request to their bug tracker (https://bugs.archlinux.org/task/50160). It looks like they are working on it (or at least are aware of the problem). For other distros, you can try submitting a bug report to their corresponding bug tracker.

[kvark]

Thanks for the info @nicokoch

[mikedilger]

With xlib I'm experiencing (in vulkan) get_physical_device_surface_formats_khr() doesn't return until the window is focused. With xcb (in a separate C++ program - Sascha Willems demos) this doesn't happen, the window draws irrespective of focus. I can't be sure the reason for this behavioral difference is xlib vs xcb, but it is looking that way, in which case I prefer xcb and +1 this issue.

[francesca64]

Is this still relevant?

[tomaka]

This is still relevant, but not really a priority.

[mikedilger]

Just fyi:
https://crates.io/crates/ash exposes Vulkan's
https://docs.rs/ash/0.24.1/ash/vk/types/struct.XcbSurfaceCreateInfoKHR.html
which wants not only the connection (xcb_connection_t) but also the window (xcb_window_t). I notice that winit already provides the former with get_xcb_connection() but not the latter, so searching I found this issue and now I remember xcb isn't really supported yet.

[francesca64]

I don't believe adding a full-fledged XCB backend to be a good idea until winit stabilizes more. We have enough of a struggle keeping the existing backends synchronized.

That said, are you sure that using the return of get_xlib_window as your xcb_window_t doesn't work? I'd imagine it would work.

[mikedilger]

I did not know that get_xlib_window is the same for xcb. Thanks.

[Avokadoen]

This seems to be the cause of a UnsupportedWindowHandle error for my Ubuntu station on a "HP Prodesk 600 Small Form Factor"

[rib]

At least for reference it's probably worth linking this PR here which quietly includes a full port to xcb: #2088 :)

At least one notable concern is that a side effect of a full port to xcb (as opposed to more of a hybrid approach that just optimizes certain request sequences with xcb but keeps xlib for event processing) is that it would remove XIM based IME support.

XIM is arguable quite archaic and there should be better ways to support IMEs, like having direct support for ibus perhaps, but still something to consider.

[kchibisov]

It won't and it'll likely fixed it. We can't support ibus directly, since it's, you know, ibus, and other IMEs won't work.

At least one notable concern is that a side effect of a full port to xcb (as opposed to more of a hybrid approach that just optimizes certain request sequences with xcb but keeps xlib for event processing) is that it would remove XIM based IME support.

XIM is arguable quite archaic and there should be better ways to support IMEs, like having direct support for ibus perhaps, but still something to consider.

We can use this https://crates.io/crates/xcb-imdkit

[rib]

It won't and it'll likely fixed it.

Sorry I didn't quite follow this part of your reply, but yeah planning to integrate something like xcb-imdkit sounds reasonable, at least for compatibility.

I mainly just wanted to link the existence of an xcb port back to this issue and highlight that currently it would result in removing XIM based IME support.

[notgull]

This would be closed by #2614.