Giter VIP home page Giter VIP logo

Comments (5)

Osspial avatar Osspial commented on September 13, 2024

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.

from winit.

notgull avatar notgull commented on September 13, 2024

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.

from winit.

ids1024 avatar ids1024 commented on September 13, 2024

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.

from winit.

notgull avatar notgull commented on September 13, 2024

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.

from winit.

ids1024 avatar ids1024 commented on September 13, 2024

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.

from winit.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.