Input device design
krahn at niehs.nih.gov
Fri Aug 26 09:44:49 PDT 2005
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
> > 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
> > work pile.
> > I've written some of my ideas to
> > It seemed the interest has been too low. Maybe it's finally time
> > 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
> > 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
> > Should there also be an X client device manager that maps in those
> > devices, sort of like a Window Manager? This would allow for
> > 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
> 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
> > 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
> > should be accepted as a core-input device.
> Yes, this seems to be a necessity in order to make proper use of more
> input devices like tablets.
> > There's been a lot of discussion on how to map specific input
> > 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
> > like IP address / routing management. Devices get a name, possibly a
> > generic DHCP-like name, and things like X that want to actually
> > 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)
More information about the xorg