Input device design

[Joe Krahn]

Waldo Bastian wrote:
 > 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.
The reason I like the idea of communicating via X is that input-device 
controls and core-input changing are already established as X client 
functions. The non-X communications are good at notifying the server to 
which devices are available via local hardware. I like the idea of 
client control as to which available devices actually get connected to 
the server, and which of those should act as a core device. This fits 
better with multi-server systems and connection of remote or virtual 
devices. It also allows the user to decide which devices it should trust.

 >
 >  > 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
 > meaningful way and I think that's something that should be taken
 > advantage of.

Yes, these are good, but they are oriented towards hardware knowledge. 
There may be a way for HAL to circumvent the need for hardware 
knowledge, but a HAL is still OS-specific, and the HAL information has 
to be managed centrally to allow for multiple X servers and/or virtual 
terminals. An external middle-man daemon can manage such things, as well 
as allowing for asynchronous updates of X and HAL.

Also, XListInputDevices should not simply list all current, local input 
devices. The device list should allow for "present but off-line" 
devices, which may be temporarily unplugged. This type of thing should 
(IMHO) be user-preference oriented, and not a system-level 
configuration. But, there also needs to be system level settings for 
local-device access control. That's why I'm thinking of a system daemon 
for local device management, as well as X client management of how those 
local devices get connected to the server.

Of course, it should also be possible to tell the server to dynamically 
and mindlessly include all local devices, for the common single-user 
single-server configuration. (i.e. more like MS Windows)

Joe Krahn