[Xorg] Input device hotplug

[Kristian Høgsberg]

[ Joe, I'm cc'ing the list, I assume you meant to send to the list too ]

Joe Krahn wrote:
> Kristian Høgsberg wrote:
> ...
> 
>> One thing I'ld like to discuss is where to add the add and remove 
>> device interface -- I dont think XFree86-Misc is the right place.  My 
>> first approach to this was that the new functionality should be an 
>> Xorg private interface, but I'm thinking that maybe it would be better 
>> if it was a standardized extension to XInput.  In that case, is the 
>> proposed interface too Xorg specific?
> 
> 
> OK... the big problem is a total lack of XINPUT design docs. (Or at
> least that's how XFree86 was designed. I hope X.org is more interested
> in fixing this.)

Are you talking about the protocol design or the server internal 
(implementation) design? Or both?

> Improving XINPUT is definitely the place to do it correctly. I worked on
> this for a while some time ago, then Jim Gettys accepted the task as
> XFree86 XINPUT manager. I knew he could do a much better job than I,
> so I put it off until he had time to get going, but that never happened
> do to his time investment in freedesktop.org and x.org.
> 
> First, XINPUT has always had hotplugging ability. If you notice,
> the reference X server implementation has a list of "OffDevices".
> These are devices the server knows about, but are not available.

Yes, I did notice that list, but I think it is important that
hotplugging will work also for devices that wasn't previously 
configured.  If I buy a new device I should be able to just plug it in 
and use it without editing xorg.conf and restarting the server.

> XFree86 should have been designed to allow a configured-but-absent
> driver load, but remain OFF until the driver sees that it has become
> available. The current driver loading scheme has gotten mangled in
> this respect, because XFree86's XINPUT never had a written design
> plan. I think that needs to be done before a release contains
> hotplugging.

The configured-but-absent concept is useful, i.e. I don't want to 
configure my spaceball everytime I plug it in.  But I'm not sure the 
server needs to know about those devices.  The overall approach I have 
in mind is that the device detection mechanism/daemon is outside the 
server, and when an input device is found, this daemon tells the server 
to load the appropriate driver and add the device with a given list of 
options.

> One big problem in the current design is that the main Control()
> function is not used correctly. Driver loading and unloading should
> never open/close the actual device. That is the job of Control().
> Why is this important? Because a server that is switched away
> from it's VT is told to close and reopen it's devices via Control().

Sounds reasonable, I think one side effect of this problem is that there 
now is some confusion about what to do on DEVICE_INIT and what to do on 
DEVICE_ON.  In the current implementation it doesn't really matter 
because all devices are DEVICE_INIT'ed and then immediately DEVICE_OPEN'ed.

Another thing that confused me is PreInit() and DEVICE_INIT... are both 
really necessary?  Couldn't DEVICE_INIT code be moved to PreInit()?

> Some stuff I wrote up before:
> ---------------------------------------------------------------------
> Control() is intended to be the primary access point to the driver,
> named <device_name>Control. Here are it's functions:
> 
> <Name>Control:
> To keep things confusing, this function is pointed to by
> local->device_control, is called "deviceProc" in Xi docs, and is
> NOT related to XDeviceControl (that's the local->control_proc)
> 
> This process is to enable/disable/open/close a device.
> 
> DEVICE_INIT: Here is where you should make sure the device
> is present and working. If this fails, the driver should
> remain loaded, but the devices stays in the "Device OFF"
> list. OFF devices should get DEVICE_INIT called
> some time later to poll for the devices existence, such
> as just before replying to a ListDevices request.

Again, couldn't this be merged into PreInit()?

> DEVICE_ON: This is the signal to actually open the device.
> If local->flags & XI86_OPEN_ON_INIT, or it
> is a core device, this is called at initialization.
> Otherwise, open when XOpenDevice is first called.
> It is also called when restoring a VT switch.
> 
> DEVICE_OFF: Called by XFree86 only when switching to
> another VT. If the device is stateful, be sure to
> save state information to restore when DEVICE_ON is called.
> 
> DEVICE_CLOSE: Ideally, this should get called when
> XCloseDevice is called. Current XFree86 keeps all devices
> open at all times.
> 
> ---------------------------------------------------------------
> 
> Now, back to client commands for device controls:
> 
> Client controls should be via XChangeDeviceControl and
> XGetDeviceControl. But, this is the most incomplete command
> in the XINPUT spec. It is not very extensible.
> 
> One fix for these is to add more enums for the obviously-missing
> stuff like DEVICE_RESET, and specify a range of enums
> for private device-specific controls.
> 
> Or, instead of device-specific enums, just add a few enums
> for generic control commands similar to XClientMessage, that
> can send an ASCII control name, and an ASCII parameter value,
> or char/short/long binary data.
> 
> That still does not address the issue server notification for
> loading/unloading a driver. That part is more complicated that
> sending device control parameters, and probably is worth
> adding some new functions to XINPUT, such as XAddInputDevice.

I dont think XChangeDeviceControl is appropriate for adding and removing 
devices, since it operates on an pre-existing XDevice.  It should also 
work if you plug in a device that isn't mentioned in xorg.conf.

Another thing, I think that the options you specify with 
XAddInputDevice() should be the same or a subset of those you can change 
with the new verion of XChangeDeviceControl().  This way there would be 
only one option mechanism to implement.  I think the ASCII parameter 
name is nice, but I'm not sure the binary data is so useful... ASCII 
values should be sufficient I think.

> There are other issues as well: Relative versus absolute events
> are not handled correctly in XFree86. XChangePointerDevice and
> XChangeKeyboardDevice need to be redesigned with the idea of
> simultaneous core devices. etc, etc.

Right, so you basically toggle wether or not to send core events and 
drop the idea of a single core pointer?

> Anyone feel up to collaborating on ironing out the XINPUT
> implementation design docs, and potential XINPUT additions??

Yeah, I'm in.  I think there are two efforts here: documenting/cleaning 
up the XINPUT implementation and extending XINPUT to deal with hotplug 
and better device control.  We should  probably set up a wiki page where 
we can flesh out the proposed extensions and modifications to XINPUT.

Kristian