[RFC] Input design

[Nicolas "Ikke" Trangez]

On Fri, 2007-04-20 at 16:16 -0400, David Zeuthen wrote:
> (apologies if this breaks threading for folks, I wasn't subscribed to
> the list until I was pointed to this thread)
> 
> On Thu, 2007-04-19 at 16:16 +0000, an 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.
> > 
> >  * 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.
> 
> I can see why some people object to this. Still, I think an intelligent
> client is what most of the desktop projects (e.g. GNOME, KDE) wants to
> do - your thoughts on that?
This is what would have been my (GNOME) SoC.
> 
> (Just because I have this point of view doesn't mean I object to it
> being easy to use dumb clients or have the server do _some_
> autoconfiguration if that's what the user wants.)
> 
> >  * 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.
> 
> Well, Daniel, that's your opinion which both I and other D-Bus authors
> disagree with; suffice to say; the point, I think, is that as long as
> you write non-buggy code and don't pass garbage to libdbus you'll be
> fine (I'm sure I can find lots of functions in the X server that will
> crash if I pass a NULL pointer or garbage). It's no different from most
> other API's out there. For the record, this have already been
> extensively discussed on the dbus list... for reference to other
> readers, see
> 
>  http://lists.freedesktop.org/archives/dbus/2006-November/006415.html
> 
> for rebuttal and also surrounding messages. Anyway, I don't think it's
> useful to rehash that discussion, at least not right now. It's more an
> implementation detail at this point I think...
> 
> >  * 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.
> 
> There's things like ConsoleKit that is already shipped with Fedora 7;
> I've copied some docs here for consideration
> 
>  http://people.freedesktop.org/~david/ConsoleKit.html
CK seems sensible, indeed.
> 
> > 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.
> 
> 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.
> 
> (As the maintainer of HAL, I usually tell people _not_ to use libhal; I
> tell them to use native bindings (glib, Qt, Mono, Java, Python,
> whatever) for D-Bus instead. For the X server, I don't know; I guess if
> using libhal makes your life easier (and you don't mind blocking calls),
> then why not. But if it was me, I'd use libdbus directly and just make
> sure my code isn't buggy.)
I've never been convinced this is the "right" approach. When thinking
about C code (Python is another story), I think working with
(autogenerated) code which hides the low-level dbus calls and allows you
to add callbacks to signals defined in the interface, call methods as if
they're local methods (with correct signature, including compiler
signature checking) etc, ie autogenerated proxies based on the interface
definitions, would be a big gain.
This would force application developers to define strict interface
definitions for their services too, as otherwise the object methods
won't be called (unless the client got handcrafted dbus code inside),
which is currently somewhat an issue in at least one project (NM).

Writing libdbus or libdbus-glib code is, I think, somewhat suboptimal.
Proxy generation for clients would be a major gain.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070421/86b7ca94/attachment.pgp>