Support X11 systems that don't have extension libraries installed

[tomaka]

Original: rust-windowing/glutin#554

[Osspial]

Is there any practical way we could do this without stripping out all the functionality from Winit on those systems? If not, I'm in favor of closing this.

[notgull]

As of the latest master, xtrace tells me that the window example is using the following extensions:

• BigRequests, which is used to increase the size of the request that you're legally allowed to send. This is X11/x11rb internal and I think they should automatically fall back to being able to work without it.
• xkb, which is used to handle keyboards. It would be possible to fall back to xproto keyboard symbols in this case, although this would only be able to support Latin-1 keyboards IIRC.
• randr, which is used to query screen dimensions and properties. We can fall back to taking screen information from the Setup and assuming it doesn't change.
• xinput, which handles external devices. Getting rid of this would be the hardest bit of functionality to lose, as it means we have to fall back to xproto events to get input, which is seriously underpowered compared to xinput.
• shm, which is used to create a shared memory buffer for rendering. softbuffer is programmed to automatically fall back to normal xproto image requests if SHM isn't possible.

The only other real concern is the XIM protocol used to handle IME. There's a crate for that now, and barring that it's possible to just disable IME.

The question is if the work needed to run winit on xproto alone is worth it in comparison to the potential result. The original issue mentions that some extensions didn't run properly on the Raspberry Pi. I'm not sure if this is still the case; I have a Pi buried in my garage somewhere that I can probably check with.

[ids1024]

Looks like when this issue was originally opened, it was about libraries, rather than extensions. Which are somewhat separate issues. With x11rb we should be depending on xlib, xcb, xkbcommon, but not these other shared libraries, right?

For extensions, working without xkb and xinput sounds like it may be too much trouble unless there's some compelling use case for it. Working without shm is good for network transparency, and indeed is handled already in softbuffer. BigRequests and randr seem like they shouldn't be all that necessary either, though I don't know if there's any case they wouldn't be supported.

Would running without xkb or xinput extensions be relevant to anything other than communicating with ancient X servers? That's not something I'm opposed to the idea of and I've done stranger things (e.g. Smithay/wayland-rs#641) but it may not be relevant to any real use of the library.

[notgull]

Yeah, I'm not sure that the value proposition of removing these extensions is, especially once we move to x11rb and we don't need to link to anything aside from libX11 and libxcb. My general policy is "if the latest version of Rust doesn't support it, don't give special effort to get it working."

As of the time of writing the minimum kernel version is Linux 3.2, released in Jan 2012. xkb was released in 1996, randr came out in 2007 (although newer versions date back to 2015) and xinput2 was released in 2009. So the Venn Diagram of computers than can run winit and computers without xkb/xinput is practically two separate circles, with maybe a little sliver in the middle for weird hobbyists.

#2968 should take care of this for the most part.

[ids1024]

It could also be relevant if you're targeting an X server other than XOrg. An X server that runs on Windows or in an Android app or something might be more limited if it's not based on XOrg. But then I'd still expected xkb to be supported anyway.

If there's any case where this would be relevant, I think one would really want to test it and see if anything is an issue before trying to make any extensions optional.