[Xorg] Input device hotplug

[Joe Krahn]

Kristian Høgsberg wrote:
> [ Joe, I'm cc'ing the list, I assume you meant to send to the list too ]
Ooops; REPLY to lists usually goes to the list email.

> 
>> 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?
Both. The XINPUT protocol looks like a somewhat unfinished work, and
was designed aroung the idea of dumb devices. As for XFree86, the XINPUT
server code has gotten mangled due to never having a real design doc.

> 
>> 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.
Agreed. I'm just pointing out that X in general is much more hotplug
friendly than XFree86, and I was always annoyed that XFree86 would
ignore a device config if it didn't happen to be available when X started.

> 
>> 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.
Yes, that's how it is, and that is definitely the wrong thing to do.

> 
> Another thing that confused me is PreInit() and DEVICE_INIT... are both 
> really necessary?  Couldn't DEVICE_INIT code be moved to PreInit()?
In my opinion, most or all PreInit code should be moded to DEVICE_INIT. 
In fact, PreInit is probably not needed. It is trying to do what
DEVICE_INIT was always designed to do. PreInit mainly exists because
it was put there for video drivers. IMHO, it would make sense to use the 
XINPUT concept for all drivers to have a single Control() function that 
is sent DEVICE_INIT, DEVICE_ON, etc.

> 
>> 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()?
Why not go with the well-defined X method? Why have a PreInit() at all?

> 
>> 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.
I think ASCII is good for most things, but I can think of cases where
binary is useful, such as a force feedback, or even program code for a 
smart device.

The things I'm thinking of are more like custom device controls, rather 
than things you would put into xorg.conf. The problem is that adding a 
custom control type means adding an X protocol data description and 
modifying the server. So, I'm thinking it would be good to add general 
use control types that can handle more than just ASCII.

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

Well, I've never gotten involved in wiki, but this is certainly an ideal 
case for wiki, since many people will have opinions about the best way 
to do it.

How do we start a wiki XINPUT page?

Joe