[RFC PATCH] Initial libudev input-hotplug support
pinglinux at gmail.com
Wed Oct 7 20:37:31 PDT 2009
Ok, I 'll take this opportunity to prove xf86-input-wacom is responsive and
give you all a break. I will also take care of both hal/libudev and
xorg.conf. The fix will be ready for xorg 1.8 if my driver can be
On Wed, Oct 7, 2009 at 7:14 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> On Wed, Oct 07, 2009 at 06:19:10PM -0700, Ping wrote:
> > On Wed, Oct 7, 2009 at 5:02 PM, Peter Hutterer <peter.hutterer at who-t.net
> > >
> > > not for the faint of heart.
> > >
> > > when cleaning up you have to make sure you're only cleaning up those
> > > devices
> > > that you've initialized yourself, otherwise you're going to top the
> > > i'm not sure if I can recommend the above at all, mjg59's HAL trickery
> > > a
> > > lot nicer but then again, udev.
> > Then, my question is: can we assume, with xserver 1.8 and later,
> > xf86WcmInit (the device initialization routine) will only be called by
> > libudev input-hotplug mechanism? Or in another phase: do you still allow
> > users to define input devices through xorg.conf?
> > If xf86-input-wacom will only be Init'ed by libudev input-hotplug, I can
> > "fix" my driver by creating all devices inside the Init. Then the driver
> > will cleanup itself in UnInit. I think I like this approach if you guys
> > willing to take the risk of Wacom blowing up the server :).
> I'd like to finally fix up our device API so these kinds of hacks are no
> longer necessary, but to be honest I'd suspect this may end up creeping
> into 1.9 rather than 1.8.
> NewInputDeviceRequest is completely fine to call from your driver: don't
> be scared by all the failure messages you'd find about it. :) Just
> construct a reasonable set of options lists (including 'Driver
> "wacom"'), and you should be fine.
> I don't think xorg.conf will ever die, but yes, you can safely do this
> by checking the option named '_source'. If it's server/hal or
> server/libudev (I think -- you'd have to check Julien's patch to make
> fully sure), then you're being called from either hal or udev. If not,
> then it's almost certainly xorg.conf.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg-devel