[Xorg] XInput Hotplug Additions

[Joe Krahn]

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,
> etc...
> 
> 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
console?

> 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.

Joe Krahn