Input device design (3)

[Olivier Galibert]

On Mon, Aug 29, 2005 at 03:01:56PM -0700, Johnson, Charles F wrote:
> Russell's comments is exactly what I've been thinking of:
> 
> **********************
> *      X Server      *
> **********************         *******************
> * X Config Interface *  <----  * X Config Client *  -> DBUS -> HAL
> **********************         *******************
> 
> In this setup, the X Config Client (XCC) would handle:
> 
> 1. Input Device Discovery
> 2. Input Device Hot Plug & Removal Tracking
> 3. Notifications to X Server on Events in #2
> 
> This enables:
> 1. Removal from the X server knowledge of OS & platform specific 
>    hot plug mechanisms.
>    (Linux can have its own, Solaris its own, etc.).
> 2. Makes it possible that the X server may not have to run as root 
>    anymore.  (Assuming the XCC passes a fd to the server.)
> 3. Allows the X server to evolve independent of the 
>    OS & platform configuration detection mechanism.
> 
> Please let me know if this is too simplistic view of the world.

Well, I think both Russell and you are collapsing two things that
should be kept separate, and separating two things that should be kept
together.  These things are:

1- OS-dependant input device reading and writing[1]
2- OS-dependant static and dynamic input device discovery
3- Per-device use policy

I think that 1 & 2 should be kept together, simply because they have
the same os-dependencies, have race conditions between the two (you
should stop accessing a device as soon as the OS tells you it's gone
for instance) and are probably using the same or similar OS interfaces
anyway (/dev/input/event* on linux I think).  Whether that set is
within the server or in a different address space is of course open to
discussion.  But they should be together in one os-dependant module.

3, the usage policy, or in simpler terms "I have this device, should I
use it or not, and what configuration should I use for it?" is not
fundamentally os-dependant except for things like what device names
look like.  And even then, you often abstract it just enough to keep
os-dependant knowledge from the code.  On the other hand, that is
where the user and/or the admin have their word to say.  So for that
problem an os-independant interface to the rest of the world, whether
through X extensions with a client with a specific status (pretty much
like a window manager but for input devices and/or general
configuration) or through another mechanism, would allow to solve
these questions either automatically or through asking the user on the
fly.  Actions to take on monitor hotplug could use that too.

  OG.

[1] Keyboard leds, force-feedback mouse...