[RFC] Input design

[Daniel Stone]

Hi,
So, one of the reasons I've been very hesitant to put 1.3.99.0 out is my
dissatisfaction with the current design of the input hotplugging.  I
think I know how to fix it, however, and would appreciate comments from
the other people bored enough to hack on input.

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

 * Why D-Bus is not our ideal IPC system
   D-Bus is a very good idea, and there's not much wrong with the spec
   per se[0], but the client library is, well, abhorrent.  Its worst
   transgression is to repeatedly call assert() from a library, which is
   a design decision and will not be changed.  Its API is also quite
   horrible and awkward to use (see config.c and respeclaration).  The
   excuse for this is that no-one ever uses plain C anymore, so we
   should use the GLib/Qt bindings.  IOW, someone needs to write
   libdbus-desuckified.

 * Security issues not even solved properly
   Right now, we need someone to write a D-Bus authentication plugin to
   map X servers to users, in order to come up with a sensible security
   policy.  Plus, MPX kind of blows this out of the water.

To recap, the reason I went with D-Bus is because adding input devices
is a security concern.  Either you can steal someone's keystrokes, or
overwrite your partition table with the PS/2 init sequence.  The way
we've dealt with this previously has been to have security policy
out-of-band (i.e. config file), and keeping that way seemed an appealing
method of skirting the security issues that came with doing it over the
wire.  Also, D-Bus's security policies are fundamentally aimed at 'who's
sitting at the machine?', rather than 'who can access /tmp?', and this
is a good thing.

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.

  * Leverage synergies for the benefit of all market segments
    Just making sure you're still paying attention.

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

I think we can do this reasonably quickly, and once that's settled down,
we can start shoving the 1.3.99.x releases out.

Questions? Opinions?

Cheers,
Daniel

[0]: You can always find problems, but no more or less than if anyone
     else wrote their own IPC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070420/b0fc8fa8/attachment.pgp>