Getting involved in XInput hotplug development?

[Daniel Stone]

On Fri, Feb 02, 2007 at 02:37:37AM +0100, Enleth wrote:
> I've been looking into the input hotplugging functionality recently and I must 
> say that I'm very happy, as a laptop and graphic tablet user, with the 
> progress (well, it works!) and I'd like to thank you all for the time you put 
> into working on it. Moreover, I've decided that the best thing I can do to 
> make use of it as soon as possible is just to contribute.
> With some free time, quite a bit of C programming experience and UNIX 
> knowledge and good motivation, I think I can take on the task, the biggest 
> problem being finding information on what is currently in the TODO, other 
> than some wiki pages badly needing update.

Excellent, thanks.

> So my question is: where to look for something to do, or just, what to do?

There's no real list.  Right now, we haven't got a proper external
manager that integrates with desktops; I'm also thinking about moving
off desktop and just making it part of the wire protocol[0]

> From what I've found, it looks like the main problem now is inconsistent input 
> driver design, the D-BUS interface's "duct tape-like" implementation (it's 
> still extremely easy to crash the server with an incomplete input.add 
> request, so did I at first, by accident), and lack of an external device 
> manager for testing purposes (or did I just miss it?).

Hm, the server shouldn't crash: are you getting crashes, or assert()s
from within the D-BUS library?  Patches are, of course, welcome. :)

There's a testable device manager at:
git://anongit.freedesktop.org/~daniels/respeclaration

It's horribly incomplete, and basically needs to be started from
scratch; any implementation that's not part of your desktop environment
will, IMO, suck horribly.  As the comment in respeclaration.c says, it's
purely a proof of concept.  It _works_ (I use it on my primary machine),
but that's about it.

> As for the coding-related stuff, I've spent the afternoon setting up a sandbox 
> enviroment (bare-bones Linux system with just the compiler, git, gdb, 
> hal+dbus, sshd and libraries required to build X, all that inside a VMWare 
> virtual machine tweaked to allow direct USB HID device access), getting used 
> to the new X code structure (which is, BTW, *much* more comfortable to work 
> with than the monolithic codebase with its obscure build system...), making 
> some quick fixes to prevent bad requests from screwing the server up and 
> rigging up a simple device manager (er, well, a something to pass events from 
> hal to X) in Python. It tends to work, a sort of.

Excellent!  Thanks very much.  If you have any patches, send them to the
list and I'll get them merged ASAP.  For now, the implementation
generally works; the remaining problems are mainly in the client-side
manager, and mainly to do with integration.

Cheers,
Daniel

[0]: Your security problems basically go away if you only allow users to
     enable devices from a fixed server list, which can be got from HAL,
     built in, or whatever.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070204/31ee37a6/attachment.pgp>