[PATCH 2/2] Add libudev input-hotplug backend

[Peter Hutterer]

On Fri, Oct 16, 2009 at 02:30:40PM +1000, Peter Hutterer wrote:
> On Wed, Oct 14, 2009 at 10:21:12PM +0200, Julien Cristau wrote:
> > If libudev is found, we use that for hotplug and disable the hal and
> > dbus backends.
> > We look for event devices with an "x11_driver" property.  XKB
> > configuration happens using xkb.{rules,model,layout,variant,options}
> > properties.  Arbitrary driver options can be set with a "x11_options."
> > prefix.
> > 
> > udev rules would look something like:
> > SUBSYSTEM=="input", KERNEL=="event*", ENV{x11_driver}="evdev"
> > SUBSYSTEM=="input", KERNEL=="event*", ENV{ID_CLASS}=="kbd", ENV{xkb.layout}="fr", ENV{xkb.options}="terminate:ctrl_alt_bksp,compose:lwin"
> 
> I think we should provide an example .rules file in xserver/config/
> seems the x11-input.fdi file from there was used as a template, at least
> initially, it'd be good to have a template again for those building from
> source.
> (I know I'd have preferred just copying that file when testing the lot :)
> 
> > ---
> >  config/Makefile.am              |   16 +++-
> >  config/config-backends.h        |   21 +++-
> >  config/config.c                 |   77 ++++++++++++-
> >  config/hal.c                    |   63 +----------
> >  config/udev.c                   |  247 +++++++++++++++++++++++++++++++++++++++
> >  configure.ac                    |   23 ++++-
> >  hw/kdrive/src/kinput.c          |    8 ++
> >  hw/xfree86/common/xf86Config.c  |   15 ++-
> >  hw/xfree86/common/xf86Globals.c |    2 +-
> >  hw/xfree86/common/xf86Xinput.c  |    4 +-
> >  include/dix-config.h.in         |    3 +
> >  11 files changed, 400 insertions(+), 79 deletions(-)
> >  create mode 100644 config/udev.c
> > 
> 
> Tested-by: Peter Hutterer <peter.hutterer at who-t.net>
> 
> I haven't tested for the chroot issue you pointed out though. Patch looks
> good though.
 
Follow-up on that, I hit send to early.
If we merge this patch into master, I'd rather have udev default to "no" for
now until we figured out how we can migrate user configurations from the fdi
files. If we provide udev support before solving this, we a) break existing
configurations and b) end up with users configuring everything in the udev
rules files again. Disabling udev for now gives us testing exposure by those
who want to test that particular feature while leaving all others in the
current state.

I think Dan's approach is not a bad one but I do think it needs the
xorg.conf.d patches first to allow a smooth migration.

Or, and this would be even better, we keep these patches on a feature
branch, wait for dan's xorg.conf.d and inputclass patches on top and then
merge the lot in one go.

Cheers,
  Peter