[RFC] Input design

[David Zeuthen]

Hi,

sorry for the lag,

On Sat, 2007-04-21 at 02:46 +0300, Daniel Stone wrote:
> Right.  For a few usecases (embedded/consumer devices in particular, as
> well as minimal systems, LTSP-type setups, et al, not to mention systems
> which are merely misconfigured or incomplete -- it's kind of hard to fix
> that without input), we really want the server to be able to bring up
> our devices.

Right. And if (in 10,000 years) it's feasible to run with e.g. Linux
in-kernel virtual consoles you need this too for emergency shells and
the like...

> > Adding HAL support to the server means it needs to talk to HAL - this
> > can only be done via D-Bus (the system bus specifically) so your
> > complaints about libdbus may apply here. It's true, however, that
> > there's a C library, libhal, that does this for you (via libdbus) and it
> > checks everything (or tries to) to make sure it doesn't send garbage to
> > libdbus. And this works fine.
> 
> Sure, but if libdbus is effectively an implementation detail of libhal,
> then that's not something I'm bothered with, as you say.

Well, libdbus is a bit more than an implementation detail today.. libhal
isn't really a well-designed library; it kinda grew organically.

> For us, our native binding is libdbus.  GLib is unacceptable due to the
> whole abort()-on-malloc()-failure thing, and for obvious reasons we're
> not about to start requiring Qt/C++, Mono/C#, Java, or Python.  So we're
> stuck with the low-level lib (which no-one is ever supposed to use, but
> we lack for alternatives), and its incredibly awkward API.

Yeah, no disagreement there... but you only have to go through the pain
once or so they say. 

> > For the record, whether you use D-Bus or X protocol to do this both
> > works as long as you can get the information you need about the client
> > (e.g. uid, pid whatever) to make a security decision. It's not like I'm
> > religiously attached to D-Bus; I just don't think your complaints about
> > libdbus are valid.
> 
> Sure.  The benefit here isn't in getting rid of D-Bus, but in reducing
> the number of client/server interfaces from two to one.  I'm not
> convinced that the benefits brought by doing things out-of-band outweigh
> the downsides of making sure everyone has D-Bus, requiring relatively
> complex setups to manage it from a remote machine, and doubling the
> number of communication channels that need to be doubled and deal with
> authentication.

Right. But isn't it a problem that you can't get the UNIX user id of the
X client that requests to hotplug something? I mean, you really want to
only allow hotplug add devices the X client requesting the hotplug add
have access to, yes?

> > Btw, I don't see why it's useful to let the server keep this list; I'd
> > just stick it in a library and let the client use it; I mean, what
> > really is the big win between
> > 
> >  1) client using X protocol to enumerate devices AND select device; vs.
> > 
> >  2) client using some library to enumerate devices AND then use X
> >     protocol to select device
> > 
> > Maybe there's something I don't get?
> 
> 3) Server adds all input devices in the absence of a client, is the
> killer feature here.  I don't really want to have to run a full config
> client on the N800, and I'm pretty sure quite a number of others don't
> want to, either.

Is the thinking that this is achieved by passing a special option to the
X server and only acknowledge this option if the user starting the
server is root? Then that option would just add all input multiplexers
(e.g. /dev/input/mice + friends on Linux) or manually add each and every
input device that exists at server startup time...

(Because otherwise, it seems like a security hole... for example, a user
can gain access to all input devices and this would break for e.g.
multi-seat and maybe other things.)

> >  3. Keep in mind that access to the device may be revoked at any point
> >     in the future for the user that added the device; Since the server
> >     (currently) runs as root, perhaps that means you want to run your X
> >     input driver in a child process with  the uid of the user that added
> >     the device... and then handle ENXIO or SIGBUS [1]. 
> 
> We're not going down the child user path, nor are we going to strongly
> tie users and servers (see, e.g. MPX, which gives you one display for
> multiple seats; you might say ConsoleKit here, but think of display
> walls and shared collaborative systems).
> 
> We can catch the signals and just shut down the device.  That's not a
> problem.

I guess we'll have to wait and see how this actually works out when
revoke() lands in the kernels people use and people/distros actually
start using it... either way, as you say, there are nicer ways to do
this than having the driver code run in a child process.

    David