Getting involved in XInput hotplug development?
daniel at fooishbar.org
Sat Feb 3 08:44:32 PST 2007
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.
> 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
> 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:
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.
: 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...
Size: 189 bytes
Desc: Digital signature
More information about the xorg