Xlib must die

[notgull]

Xlib is the legacy strategy for interacting with the X server. It has since been replaced by libxcb, which is lighter and has fewer soundless holes. x11rb wraps around libxcb and reimplements the protocol parsing logic in safe Rust, further reducing the number of places where unsound logic can occur.

List of places in winit where Xlib still lurks:

• Event handling and IME (fixed in Use x11rb for event handling #3122)
• Cursor handling code (could use https://github.com/esposm03/xcursor-rs instead)
• SelectXkbEvents (cc Revert select_xkb_events to its previous impl #3087)
• Keymap querying

Discussion questions:

• I want to be able to replace x11-dl with tiny-xlib, is this possible?
• Do we want to add a feature to remove Xlib entirely and just use XCB?
• Going further, do we want to add a feature to remove these two external libraries from our X backend altogether and just use x11rb's pure-Rust backend?
  • Is this also available for Wayland?

[kchibisov]

Cursor handling code

isn't cursor being drawn on the server? Or we must submit a Xcursor theme to the server? How does it all work? I thought you just send names, it's not wayland with its client side cursors in the end of the day.

I want to be able to replace x11-dl with tiny-xlib, is this possible?

doesn't matter, but we don't need x11-dl that hard.

Do we want to add a feature to remove Xlib entirely and just use XCB?

yes

Is this also available for Wayland?

no.

[notgull]

Is this also available for Wayland?

no.

Can you elaborate on this? I know that wayland-rs has a pure-Rust implementation available.

[kchibisov]

Can you elaborate on this? I know that wayland-rs has a pure-Rust implementation available.

any API wants a wl_proxy from libwayland, so unless you write a EGL/Vulkan platform to use whatever wayland-rs provides, this won't change.

[bjorn3]

I believe Haiku has Xlib compatibility through the xlibe library, but not XCB compatibility. So without a native implementation of Haiku's GUI api, dropping Xlib support would mean dropping Haiku support.

[kchibisov]

dropping Xlib support would mean dropping Haiku support.

if they are interested they can send patches like redox did to even have their native platform working.

[ids1024]

Haiku apparently has some kind of Wayland support too. Which is better for running applications currently?

Native Haiku support in winit would be good.

[ids1024]

Going further, do we want to add a feature to remove these two external libraries from our X backend altogether and just use x11rb's pure-Rust backend?

Doesn't this run into rust-windowing/raw-window-handle#120?

[psychon]

Cursor handling code (could use https://github.com/esposm03/xcursor-rs instead)

x11rb's cursor feature could be used as well. I do not know Xlib's API, but this was modeled after what libxcb-cursor does. And from your link, xcursor-rs seems to at least try to do something similar (but it uses e.g. XDG env vars for finding stuff which libxcb-cursor and x11rb do not and I doubt a lot that libX11 uses anything like that).

isn't cursor being drawn on the server? Or we must submit a Xcursor theme to the server? How does it all work? I thought you just send names, it's not wayland with its client side cursors in the end of the day.

This is X11. Of course everything is horrible. ;-)

Like windows, pixmaps, fonts, cursors are objects. Once created, one can tell the server to use the cursor when the mouse is inside "your" window. For creating a cursor, there are many options, but besides the legacy ones, you basically update an image (or a list of images and a delay between them) to the X11 server. Everything else happens client side and is convention.