Input device design

[Waldo Bastian]

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

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

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

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

Cheers,
Waldo
-- 
Linux Client Architect - Channel Software Operation - Intel Corporation