Where input (hotplugging) methods might go - highly speculative (was: Re: Zapping the Xorg server)

[Wolfgang Draxinger]

On Thu, 26 Aug 2010 12:20:31 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> uhm. hotplugging works in that the X server receives an event when a
> device was added by the kernel. Then it opens the device file.

See, that's exactly what I meant: There's extra work to be done by X,
or any other program dealing with complex input. Why not place the
abstraction in the operating system core (i.e. kernel for monolithic,
or system daemons for microkernel). Have a special
devices /dev/input/consoleset<n>/allinput (or whatever you're going to
name it) which always refers to the abstract input device of current
VT. And all the input devices events are received through this single
channel. Of course the protocol used needs to be a little bit more
sophisticated than evdev. And all the devices configuration, keycode ->
symbol mapping, and all that stuff, it's all done by the kernel. Right
now there are two distinct input systems around: The text console. And
X input. Both need to be configured individually. Yes, I am aware, that
due to Xkb you've got an additional layer above the input.

Wrangling all the different devices, their nodes and configuration by a
plethora of deamons and more or less complicated communication
protocols looks somewhat, err, insane, if you need quite some
infrastructure working to do things, that by themself should be part of
the basic infrastructure. Ok, without much ado: I loathe ConsoleKit and
PolicyKit (and Network Manager and a few other things which have some
nice polish on the outside but are unnerving if you've to tame them,
your needs deviating from the usual, in this case how permissions on
user's stations are set).


Wolfgang