[Xorg] Input device hotplug

[Egbert Eich]

Kristian Høgsberg writes:
 > Egbert Eich wrote:
 > > Kristian Høgsberg writes:
 > >  > The main idea behind keeping the discovery mechanism out of the server 
 > >  > was that different systems can use different mechanisms.  On GNOME or 
 > >  > KDE desktops I think it would make good sense to use HAL for detection 
 > >  > (which is generic and system-wide), but an embedded system may well want 
 > >  > to use something more lean.
 > > 
 > > It depends on if you want to implement different system specific mechanisms
 > > into the clients by adding them to the toolkits or if you want to abstract
 > > away things from the clients (and the toolkits) by putting the system
 > > dependent  functionality into one central place (the Xserver) which exposes
 > > a uniform interface to its clients.
 > 
 > It wasn't my intention that all clients should use the hotplug requests, 
 > only the input device hotplug daemon.  Toolkit support should not be 
 > necessary either, you would use the XInput Xlib API directly.   This way 
 > you still have system dependent functionality in one central place, it's 
 > just not in the X server but in the hotplug daemon.
 > 

OK, we are already talking about such a 'daemon' for programming output
devices. I guess it would make some sense to have one daemon for input
and another one for output.
What I worry about a little bit is an extra support burdeon as we have
to run start three processes to get X up and running. If due to some
misconfiguration or misinstallation one of them isn't working we have
a support nightmare. Something along the line of
" My KDE/Gnome doesn't start ....
...
... Cannot find font 'fixed'"

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

Right. This is completely broken. I've started to make a fix however havn't
checked all drivers yet.

 > 
 > i.e. it creates a atom for the device name and uses it as the type :-/. 
 >   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...

You mean the control type? Yes, that's what I've wondered, too.
It needs to be in the struct so you know how to interpret the remaining
parts of the struct. That it is passed as an argument may be a leftover
from some preliminary design that had been placed out in the wilde already
when it was discovered that it should really exist in the struct. So it
was kept for backward compatibility. (just speculating).

Cheers,
	Egbert.