[RFC] Input design
Magnus.Vigerlof at home.se
Sat Apr 21 14:12:08 PDT 2007
On fredag 20 april 2007, Daniel Stone wrote:
> So, one of the reasons I've been very hesitant to put 18.104.22.168 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 :)
More information about the xorg