Input device design
Waldo.Bastian at intel.com
Fri Aug 26 16:00:33 PDT 2005
On Saturday 27 August 2005 00:02, you wrote:
> > 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
I agree that it would be nice if the X clients had control over which devices
should send core events (as opposed the current function that only allows one
device to be a core device). Which devices get connected to the X server is a
task for a configuration deamon and not for the X clients IMHO. There is no
reason why the configuration deamon couldn't be/spawn an X client as well,
for those cases where user interaction is required, e.g. in order to have a
"Do you allow this remote device to be attached?" dialogs.
> 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
The X Configuration Client could remember previously plugged in devices. What
I wonder about is how the user should be able to communicate to the system
whether a device should be remembered or not. What would be the use cases for
> 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)
You could have two different X Configuration Clients, a simple one for the
common case of single user single server, and a complex one that talks with
some central decission making authority in case of many-users, many-servers.
Linux Client Architect - Channel Software Operation - Intel Corporation
More information about the xorg