Input device design

[Waldo Bastian]

On Thursday 25 August 2005 19:37, 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.

I have read it with much interest :-)

> 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.

Yes, I think it's the best way to handle disappearing physical devices.

> 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.

Yes, I think there should although it should probably not be an X client, but 
instead use a separate communication channel with the X server.
I have attached a previous message on the topic, (the list archive doesn't 
seem to like it much) See also http://wiki.x.org/wiki/XHotplugProposal. 

> 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.

Yes, this seems to be a necessity in order to make proper use of more complex 
input devices like tablets.

> 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?

On Linux udev and HAL already provide functionality to identify devices in a 
meanigful way and I think that's something that should be taken advantage of.

Cheers,
Waldo

> 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
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

-- 
Linux Client Architect - Channel Software Operation - Intel Corporation
Attached some bright shiny pictures that reflect my current understanding.

The "X Configuration Client" asks "HAL" for available input devices, opens 
them, and passes the open file descriptor on to the "X server".

The "X Configuration Client" will be informed by "HAL" when a new device gets 
plugged in.

In the absence of "HAL" the "X Configuration Client" can fall back to a static 
configuration file. 

The "X Configuration Client" uses the DBUS² session bus to inform the "X 
server" about new devices (equivalent of XAddInputDevice)

Comments?

Can/should this be expanded to output devices as well? How would a modesetting 
library fit in?

Cheers,
Waldo

On Monday 01 August 2005 18:43, Johnson, Charles F wrote:
> This discussion seems to have wandered afield with the "multiseat"
> subject seeming to replace it.
>
> Going back to the "Input Devices" subject, as a summary it sounds to me
> like there is desire to move input device arrival and removal detection
> to a daemon external to the X server ??  Then it detection mechanism
> could be taylored to the specific OS/System it is running on with a
> standard interface to the X server ??  Or am I reading too much into the
> discussion so far ??
>
> Charles Johnson
> Intel Corp.
> charles.f.johnson at intel.com
-------------- next part --------------
An embedded message was scrubbed...
From: Waldo Bastian <bastian at kde.org>
Subject: Re: Input Devices
Date: Tue, 2 Aug 2005 12:41:10 +0200
Size: 58140
URL: <http://lists.x.org/archives/xorg/attachments/20050826/cd165b75/attachment.mht>