[Xorg] Input device hotplug

[Joe Krahn]

Egbert Eich wrote:
> Kristian Høgsberg writes:
>  > ...
>  > 
>  > > What I remember right now:
>  > > 1.a. Clearify meaning of device type and device name in the XDeviceInfo 
>  > >      struct. Type is an Atom form a fixed list. 
>  > >   b. A device type touchpad is meaningless as it doesn't describe what 
>  > >      device (stylus, eraser, mouse etc.) is attached.
I have always thought that the concept of a touchpad being multiple
devices is a problem. Really, it is a single device, with a single X,Y
valuator mechanism. The additional info is really an enum for which
stylus is in use. I would have designed the driver to have X,Y
valuators and one "stylus enum" valuator. But, I can see how this could
also create problems if you want the mouse stylus to emit pointer
events.

It does bring up the point that multi-device devices need to be
considered in updating the XINPUT design.

>  > 
>  > Yeah, this bit from xf86Xinput.c:xf86ActivateDevice() doesn't help:
>  > 
>  > 	local->atom = MakeAtom(local->name,
>  > 			       strlen(local->name),
>  > 			       TRUE);
>  > 	AssignTypeAndName (dev, local->atom, local->name);
>  > 
>  > i.e. it creates a atom for the device name and uses it as the type :-/. 
> 
> Yes, that is completely bogus.
> 
>  >   Here's output from a modified xsetpointer -l:
>  > 
>  > "Mouse0"        XID=3, type=Mouse0 (115) [XPointer]
>  > "keyboard"      XID=4, type=NULL (0) [XKeyboard]
>  > "stylus"        XID=2, type=stylus (114) [XExtensionDevice]
>  > "eraser"        XID=1, type=eraser (113) [XExtensionDevice]
>  > "cursor"        XID=0, type=cursor (112) [XExtensionDevice]
>  > 
>  > > 2. Make device controls more flexible. A device control currently 
>  > >    is an XID. Make it an Atom.
>  > 
>  > Can this be done in a backward compatible way or would we need a new 
>  > request?  Btw, why is the device control both in the 
>  > XChangeDeviceControl() argument list and in the XDeviceControl struct? 
>  > That's redundant...
>  > 
> 
> control is an XID in the XDeviceControl structure which is pretty much 
> an unsigned long. This would match an Atom which is also an unsigned
> long. However in XGetDeviceControl() and XChangeDeviceControl() it is
> an int :-/ On the wire its a 32bit container. This would not create 
> problems.
> 
Changing the XDeviceControl id from XID to Atom should not be a problem,
although it is officially "Bad" to make an inconsistent change to an
established X function. However, backwards compatibility should be also
be easy since the only defined type, DEVICE_RESOLUTION, is essentially
guaranteed not to conflict with another device control atom.

The bigger problem with device controls is how to encapsulate the
device control data over the wire. If we don't use some standard data
packets, then new control types require server changes, which means it
is still not very extensible.

Given this, I think a better approach is to go ahead and keep the
compatible XID for control types, and define a set of well defined
private control types, which send an identifier (string?) along with
a fixed or variable length packet of char, short, or long data.
The event would be similar to XClientMessage, or XChangeProperty.

Variable length data is better, I think, unless variable length
data packets have more overhead. Maybe it is best to have both types.

Joe