Input device design (3)

[Joe Krahn]

Sorry if this is a duplicate -- I didn't see this message get to the 
list, and the network was being flaky...

> 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.
> 
This was sort of what I've been trying to promote all along, but there
was too many other people wanting to ti the X server directly to the
hardware/OS, forgetting that X lives separately, unlike the inferior
Windows world.

There needs to be X Client device control anyhow, so this avoids having
some sort of system-level device control separate from client controls.

And from James Cloos:
>In short an X input-device server, akin to the current X font servers.
This would be the OS-dependent admin-controlled server.

Russell Shaw wrote:
(mangled by word wrapping...)
/dev/XInput for global X device input
/dev/XOutput for sending controls/feedback back to devices.
> 
> All the configuration and hardware knowledge can be taken out of the X 
> server.
> The server only knows keypress/release etc, and knows nothing about 
> keycodes.
> 
> Changing a keyboard or mouse only causes a "hardware change" X event to be
> written to the /dev/Xinput fifo for the X server to read and act upon if
> neccessary, such as relaying the event to clients. The X server or clients
> could respond with a "hardware query" event that gets written to 
> /dev/Xoutput
> for the system interface agents to respond to if neccessary.

This is much more like IRIX: The underlying OS manages a sort of input
device HAL, and queues standardized device events to the X server.

IRIX also has these two functions for a client to talk back to a device,
which would go out through /dev/XOutput in Russell's view.

Bool XSGIDeviceControl(
        Display *display,
        int device_id,
        char *name,
        char *value
      )

Bool XSGIDeviceQuery(
        Display *display,
        int device_id,
        char *name,
        char *value
      )

I think they used char* instead of Atom because they are passed directly
back to the OS. The only deficiency is that they cannot handle binary
data, which could be useful for a device that requires a lot of output,
like a force-feedback joystick. The nice thing about strings is that
they can easily handle the usual param/value pairs as in the current
config file.

And of course, this all sort of urges the idea of moving from XInput to
XInputOutput (XIODevice), and handling video cards the same way.

Having kernel-level multi-device I/O like /dev/input/mice is too OS
dependent, so I/O device abstraction should (I think) be done outside of
the kernel, at the "Xiods" level, and should go through a socket, which
provides the possibility of connecting to a remote hardware service.

SO:

********************    socket   **************
*     X Server     * <---------> *   Xiods    *
********************             **************
    ^  |   XDeviceQuery            ^ |  DBUS+HAL
    |  v   XDeviceControl          | v  /dev/mouse, etc.
********************             **************
* X Config Client  *             *   Kernel   *
********************             **************


I have not necessarily been promoting the idea of IO event abstraction,
I think the overhead would be small, and it would mean getting all of
the over-hacked device I/O code out of the server.

For time-critical I/O, there could be a "Direct Input" API that allows a
client program to talk directly to Xiods, and receive the same
abstracted data packets that would go to the server.

Joe