[Xorg] XInput Hotplug Additions

[Joe Krahn]

With Jim Gettys finally getting time to look into XInput, it
was my turn to be unavailable for a while...

Jim Gettys wrote:
>>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.
> 
> 
> I presume you mean two servers on 2 different Linux virtual
> terminals.
> 
> Ugh.  Do we *really* need this complexity?
It is already sort-of part of DIX and XFree86, but currently
is only oriented to sharing between one server and several text
consoles. If the DIX DeviceControl function is used the way DIX
intended, it is not so hard. DEVICE_ON and DEVICE_OFF are sent
when switching the server's VT in/out.


> 
> Do USB devices provide ways to save/restore such settings?
> Or will the system have to shadow the state and try to
> keep it consistent? 
> 
> Or is an input device assigned to a particular X server
> statically?  This maps well to the situation of
> multi-head systems (e.g. 441, like we've (HP) started selling
> in South Africa).
> 
> You are helping stoke my head-ache ;-).
In some ways, this is like keyboard mapping and pointer acceleration.
Most of the state information can probably be saved in the driver
and used to convert raw data to XEvent data. For example, touch
screen input could always send raw device data, and let the driver
convert to screen coordinates. This might be useful for allowing
an application to get sub-pixel data directly from the device, and
have the same device send core events at pixel resolution.

There are a few things where this won't work, for example force
feedback joysticks. Something like that can be thought of as
holding data and complex state info, just like OpenGL textures.
So, management of that type of device data should be done similar
to the way OpenGL data is or will be done.


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

An important issue to get a plan going is to understand the goals
of moving video display stuff out of X and into the OS kernel.
Is the plan to let the kernel pick resolution, depth, etc., and
tell X, or is the plan just to put driver functions into the kernel
and let X manage the screen resolution via a HAL interface with
the kernel?

A few more points:

Look at the idea of the core devices being virtual-only devices
that are always present, and always at screen resolution. This
gets rid of the problem of core hardware devices being special.

As for managing the X device list, one approach is to let the
OS kernel/hotplug system tell X what devices are available, but
also have X client functions for managing these. For example,
X client functions could set options pertaining to interpreting
raw events into X events, such as the keyboard mapping. Besides,
we need client functions to install virtual or remote devices.

Someone may want to always have a given device listed, even
though it may not always be plugged in. A client can open the
device, but it just gets no events until the actual device
shows up. (IRIX works this way.)

... Joe Krahn