Input device design (3)

[Jim Gettys]

This is pretty much correct, except I claim there is a set of modules
that abstract input event types: e.g. serial, /dev/input, other platform
specific interfaces that exist, and some network protocol we design/use,
so your box X Config Interface is too simple. 
 
On some systems, we may need to be able to do more than one such input
module type at a time (e.g. serial, vs, /dev/input), unless /dev/input
manages to support all the legacy serial devices (a distinct
possibility, but I expect that this is unlikely to be true on all
systems).

But since we're in the long term going to likely need one for local
devices, and one for network based devices, we're at the > 1 case
anyway, and should just bite the bullet and believe there are multiple
input type modules that may be used concurrently and build it that way.
				Regards,
					- Jim

On Mon, 2005-08-29 at 15:01 -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.
> 
> 
> --Charles Johnson
> Intel Corp.
> charles.f.johnson at intel.com
> 
> >-----Original Message-----
> >From: xorg-bounces at lists.freedesktop.org [mailto:xorg-
> >bounces at lists.freedesktop.org] On Behalf Of Russell Shaw
> >Sent: Monday, August 29, 2005 9:45 AM
> >To: Discuss issues related to the xorg tree
> >Subject: Re: Input device design (3)
> >
> >Joe Krahn wrote:
> >> I have over the last several years made efforts to work with XInput
> >
> >All this has got me thinking a bit. It is desireable to try and keep
> >hardware specifics and policy out of the X server.
> >
> >I've disregarded my previous ideas. Now i thinK:
> >
> >   The X server could monitor a special device such as /dev/sysconfig
> or
> >   a known ip address or socket so that if the user was to unplug/plug
> >   mice, keyboards, or any other hardware, the kernel or user-space
> >   programs or a daemon could write notification messages to it.
> >
> >When any of these server parameters/properties is changed, an X event
> >can be sent to all the running clients so they can adapt.
> >
> >So to implement this:
> >
> >   1) define a message protocol for the X server to read hardware
> >notifications
> >      from the device or socket. Maybe dbus could be used, but i'm not
> >familiar
> >      with it
> >
> >   2) add some new X message protocols such as "hardware changed"
> events
> >
> >The actual programs for configuring hardware don't need to know about
> X,
> >but
> >they or the kernel or a daemon needs to write the notification to the
> thing
> >that the X server is listening to.
> >_______________________________________________
> >xorg mailing list
> >xorg at lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/xorg
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg