[RFC] Input design

[Peter Hutterer]

>  * Too much onus on the client
>    Right now, we rely on an intelligent config client to get things
>    done: you cannot simply have the server add all devices, or do
>    something otherwise sensible.  This, IMO, is a big mark against us.

> Here's the proposed new approach:
>   * More server-centric configuration
>     The server should at least be aware of which input devices are
>     around it.  We can do this by adding HAL support to the server,  
> and
>     having it enumerate input devices via HAL.  This way, it always
>     keeps a list of active input devices, and enabling them is just  
> one
>     step away from enumerating.  This provides for an xcompmgr -a type
>     situation where the server can just DTRT for us.

so how do we specify "all devices"? This is non-trivial.
The kernel puts all devices into /dev/input. that's nice, and we can  
get hal to send us events when a new device comes in. However, this  
falls short for at least two applications:
- bluetooth mice connected with hidd don't cause hal events.
this may be fixed in a newer release of hal (I'm still on dapper),  
but it's annoying nevertheless. In the worst case, this could mean  
that we can't enable bluetooth input devices because the server never  
heard about it. this is...not good.

- there are devices out there that are prototype hacks
physical devices (touch, pucks, visual recognition) usually have some  
non-standard way to send events. One system we hacked up simply pipes  
ps2 protocol into a named pipe. it never shows up as a device  
anywhere. it's a hack but it works for what we need. requiring proper  
kernel interaction for each new input device somebody comes up with  
is limiting. [0]

and in addition, if there's multiple servers running on one box  
(multiseat comes to my mind), we have two definitions of "all devices"

so in summary:
we need a restriction to only allow "sane devices"

One thing I could imagine is - by default - don't allow anything  
outside of /dev/input/ or HAL land. But you could explicitely state  
in your config file that you DO want to allow other devices, maybe  
with a regex to the possible paths. We then add new devices by  
sending the path over the wire.

>   * Move from D-Bus back to wire protocol
>     So, if we have a list of devices (optionally filtered by the  
> admin;
>     we'll have to provide some mechanism of filtering the list), our
>     interaction with the client moves from 'add/remove this device' to
>     'enable/disable' this device.  This is a relatively safe  
> operation:
>     HAL won't let us trash someone's partition table by writing the  
> PS/2
>     init sequence to /dev/hda.  Multi-user issues will require a
>     security policy; this should probably be dealt with via the
>     server-side security framework.  Right now, we already allow  
> random
>     users to steal other peoples' pointers with MPX, so that issue  
> needs
>     to be solved through the security framework anyway.

state of the dbus library aside, I found it quite odd to have a new  
way of adding input devices when all the clients have to go through  
the protocol.


i'm not qualified enough to comment on security. I know it's a  
problem, but I a) haven't thought about it and b) don't know what the  
different security policies (dbus, xauth, etc) do and don't do.


Cheers,
   Peter

[0] biased by personal interest: there's a lot of device research  
going on, but writing a new kernel/X driver for all of them is  
cumbersome. a lot of new devices don't even have linux drivers (e- 
Beam comes to my mind). I guess the easier it is to use a new device,  
the more likely it is going to be used under X. Also keep in mind  
that X (with mpx) is currently the only true multi-device windowing  
system. getting new devices to be used under X is good. think of a  
multitouch touch screens on a standard linux desktop and then change  
your pants.

--
Multi-Pointer X Server
http://wearables.unisa.edu.au/mpx