[Xorg] XInput Hotplug Additions
krahn at niehs.nih.gov
Wed Aug 4 09:56:49 PDT 2004
Jim Gettys wrote:.
> If you look at the porting document for XInput, it looks as though
> the X server can be educated about pretty arbitrary input devices, with
> pretty arbitrary combinations of keys, buttons, locators, displays,
> It is an incremental process.
> You say: Here's a new device.
> It has some buttons,
> it has some keys,
> it has N axes,
> and so on....
> to allow pretty arbitrary devices to be described. I'm actually
> reasonably impressed at the ideas behind the design.
> I don't understand how to do this in a one step process.
One idea I had is that that X client code that manages the Input devices
gets access to new devices in a Grabbed state, and has a chance to
configure the desired options before it gets listed for general access.
Krisitan preferred a single event "load device X with option-list".
But, a grabbed-open for new devices gives client code a way to find
out info about a device before applying initial options.
> To set up a device, we may have to do a whole sequence of
> operations. E.g.
> a) load the correct device driver
> b) set it into a known sane state
> It isn't clear to me that we want both/either of those in
> the module loaded into the X server.
> So we can let hotplug get things into a state that
> X can use, and, rather than X having to reopen the device,
> and thereby potentially have to reinitialize it, pass the
> file descriptor to the X server when it is ready to go.
One thing that should be possible is for two servers on one VT
to be able to use the same device, but with different settings.
That means X needs to keep device state info and re-instate it
when X gets it's VT switched active and it regains devices.
> If you detect the idea to keep as little as possible in the
> X server, you're right.
> This is analogous to the work we want to do to get display
> mode setting *out* of the X server.
It seems strange to me for X not to be in charge of display-mode
settings. Does this mean that an OS with VT switching will have
to track display mode states for each server on one multi-VT
> Yeah, I have to scratch my head some. It also looks like some stuff
> is missing (e.g. control for force feedback joysticks.
The BIG design problem here is the lack of extensibility of Controls
and Feebacks in a way that doesn't require an X protocol changes.
Another really useful thing is an Atom to describe individual
control items, rather than just axis 1 through n.
More information about the xorg