[RFC] Input design
mailinglists at who-t.net
Thu Apr 19 17:12:08 PDT 2007
> * 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,
> having it enumerate input devices via HAL. This way, it always
> keeps a list of active input devices, and enabling them is just
> 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. 
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
> 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
> HAL won't let us trash someone's partition table by writing the
> 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
> users to steal other peoples' pointers with MPX, so that issue
> 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
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.
 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
Multi-Pointer X Server
More information about the xorg