[RFC] Input design

[Magnus Vigerlöf]

On fredag 20 april 2007, Daniel Stone wrote:
> 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.

Good, good. I think it's really time that X get proper hotplugging and an 
infrastructure defined around it so it can be used by everybody.

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

This works for simple and one-to-one mapped devices between kernel device and 
the X device. How we should fit the devices that require a more complex 
configuration into this has to be defined.

[...]
>   * 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? 

Shouldn't we define an infrastructure around this to handle the more complex 
devices that must be defined by a 'smart' hotplug client?

We have [xkg]dm that provides a graphical login (and I must admit that I have 
absolutely no idea what happends when a user does a logout), but will the 
input devices reset to some pre-defined defaults? What should we do with the 
more complex defined devices that are very much up to the user to define?

Mmm... When I think if 'more complex devices' I'm really thinking of my Wacom 
tablet which has its own driver, several tools (stylus, mouse, ...), and 
possibility to define a input device for a specific area. I.e. one of 
the 'worst' devices I can think of that I'd like to hot-plug.. I would be 
*very* happy if I after this work could hot-plug it :)

Cheers
  Magnus V