Input device design (2)

[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:

(1)
   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, and accelerations etc,
     configure keyboard, and numlock etc,
     configure screen properties such as size, scan-rate, gamma, etc,
     configure video card parameters,
     configure sound card parameters,
     paths for user font directories and font servers, 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.

(2)
   Instead of using a pop-up window, the user can run a program like xrdb
   (but is a gui) that sets all the options as in (1), as properties on
   the root window, which would cause X property-change events to be sent
   to clients. I've been thinking of implementing this method.

(3)
   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/properties is changed, an X event
can be sent to all the running clients so they can adapt.

As well as saving server state between sessions, the last used hardware
configuration can be read at the next session. At the command line, the
user could even start X using the hardware configuration they chose if
they have a few.