Input device design

[Russell Shaw]

Joe Krahn wrote:
> I have over the last several years made efforts to work with XInput, but 
> never had sufficient knowledge of the X server internal design goals, 
> and have been waiting for a LONG time for this to the top of Jim Getty's 
> work pile.
> 
> I've written some of my ideas to http://wiki.x.org/wiki/XOrgInputDriverSpec
> It seemed the interest has been too low. Maybe it's finally time to get 
> going.
> 
> Questions and more ideas:
> 
> Are people in favor of implementing the traditional core devices as 
> permanent virtual devices, with one or more real devices sending core 
> events through the virtual devices? The virtual pointer would always be 
> absolute, screen-resolution, and update with RandR.
> 
> There needs to be a system service that tracks available input devices. 
> Should there also be an X client device manager that maps in those 
> devices, sort of like a Window Manager? This would allow for user-prefs 
> of devices names, sensitivities, etc.
> 
> It is a good idea to avoid using the system level combined pointer-input 
> device /dev/input/mice, and let multiple devices be seen as multiple 
> devices by X. The X client can then decide if a newly plugged in device 
> should be accepted as a core-input device.
> 
> There's been a lot of discussion on how to map specific input devices. I 
> don't think the X server should have to think about USB HUB routes, 
> etc., to define a device. Input devices management should be a bit more 
> like IP address / routing management. Devices get a name, possibly a 
> generic DHCP-like name, and things like X that want to actually use them 
> should require minimal knowledge of the hardware. Good/Bad?
> 
> There also needs to be a generic client/server protocol for input 
> devices, which can be used to connect remote devices, emulate devices, 
> or provide a way to connect new hardware that does not yet have proper X 
> driver support. Something like UPnP is needed, but UPnP is overly 
> complex for simple input device purposes, and still incomplete. Also, MS 
> has a patent for device communication via XML. I was thinking of a 
> trivial UPnP-like protocol using ConciseXML. ConciseXML is less verbose, 
> and is IMHO a better fit to data than is regular XML, plus helps avoid 
> conflicts with the UPnP people and/or the MS patent.
> 
> Joe Krahn

The way i'd add hardware awareness is either:

   Have an X window that pops up in response to a special hotkey
   combination that has a menu of all the X server configuration
   options such as:
     configure mouse,
     configure keyboard,
     configure screen properties such as size, scan-rate, gamma, etc,
     configure video card parameters,
     configure sound card parameters, and
     anything else configureable in an X server.

   This is analogous to the Function keys used on a normal ascii terminal.
   It also minimizes complications by needing extra X clients.
   The pop-up window functionality is implemented entirely in the server.

   I'd also have a menu entry to save or load the X server state from disk
   so that the user can completely restore a session the next time the user
   logs in or if the X link is lost due to an unreliable line.

Or:

   The X server could monitor a special device such as /dev/sysconfig
   so that if the user was to unplug/plug mice, keyboards, or any other
   hardware, the kernel or user-space programs can write notification
   messages to it. There could also be a message to save and restore
   X server state.

When any of these server parameters is changed, an X configure event
can be sent to all the running clients so they can adapt.