[PATCH] man: list the drivers that are ignored when hotplugging (#35209)

[Peter Hutterer]

On Mon, Mar 21, 2011 at 05:59:47AM -0700, Dan Nicholson wrote:
> On Wed, Mar 16, 2011 at 5:14 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Wed, Mar 16, 2011 at 05:24:08AM -0700, Dan Nicholson wrote:
> >> On Tue, Mar 15, 2011 at 3:11 PM, Peter Hutterer
> >> <peter.hutterer at who-t.net> wrote:
> >> > On Tue, Mar 15, 2011 at 02:49:29PM +0100, Vincent Lefevre wrote:
> >> >> On 2011-03-15 13:21:16 +1000, Peter Hutterer wrote:
> >> >> > X.Org Bug 35209 <http://bugs.freedesktop.org/show_bug.cgi?id=35209>
> >> >> >
> >> >> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> >> >> > ---
> >> >> >  hw/xfree86/doc/man/xorg.conf.man |   13 ++++++++++---
> >> >> >  1 files changed, 10 insertions(+), 3 deletions(-)
> >> >> >
> >> >> > diff --git a/hw/xfree86/doc/man/xorg.conf.man b/hw/xfree86/doc/man/xorg.conf.man
> >> >> > index e3fd0ea..4bec316 100644
> >> >> > --- a/hw/xfree86/doc/man/xorg.conf.man
> >> >> > +++ b/hw/xfree86/doc/man/xorg.conf.man
> >> >> > @@ -814,11 +814,18 @@ Example: the MIT-SHM extension can be disabled with the following entry:
> >> >> >  The config file may have multiple
> >> >> >  .B InputDevice
> >> >> >  sections.
> >> >> > -Recent X servers employ input hotplugging to add input devices, with the HAL
> >> >> > -backend being the default backend for X servers since 1.4. It is usually not
> >> >> > +Recent X servers employ HAL or udev backends for input device enumeration
> >> >> > +and input hotplugging. It is usually not
> >> >> >  necessary to provide
> >> >> >  .B InputDevice
> >> >> > -sections in the xorg.conf if hotplugging is enabled.
> >> >> > +sections in the xorg.conf if hotplugging is in use. If hotplugging is
> >> >> > +enabled,
> >> >> > +.B InputDevice
> >> >> > +sections using the
> >> >> > +.B mouse, kbd
> >> >> > +and
> >> >> > +.B vmmouse
> >> >> > +driver will be ignored.
> >> >>
> >> >> Actually I was using the evdev driver, following the example in the
> >> >> evdev(4) man page (and probably other information found on the web).
> >> >> It was this one that was ignored in my case.
> >> >
> >> > evdev has duplication detection built-in so it doesn't add the same device
> >> > twice. going from the info in the bugreport it's hard to figure out what
> >> > exactly was wrong though. I thought it was just the usual bug that we've
> >> > seen before (but somehow never merged to the man page). please attach your
> >> > log file in the bug so we can narrow it down further.
> >>
> >> While I applaud this feature in evdev and recognize that it has fixed
> >> these issues for most people, I always wonder why we don't fix this in
> >> the server. Instead of creating another device with InputDevice and
> >> then hoping a driver cleans up the mess, we can just detect when
> >> there's an InputDevice that matches the hotplugged device and use that
> >> configuration instead. Doesn't that seem like a saner solution to this
> >> issue?
> >
> > doing it in the server is a bit more difficult. we can't always tell if the
> > device is the same. simplest example is where you don't get identical device
> > paths
> >
> > Section "InputDevice"
> >        Identifier "my mouse"
> >        Driver "evdev"
> >        Option "Device" "/dev/input/by-id/usb-blahblahblah-event-mouse"
> > EndSection
> >
> > evdev checks for major/minor to avoid duplicates but that's far from perfect
> > and doesn't work when there's more than one driver involved.
> 
> Yep, using stat(2) has it's flaws, but it's just as flawed in the
> server as it is repeated in each driver. The server has the most
> information about the source of the device, though. It can tell if the
> device was included in the layout, if it was hotplugged, if an
> InputClass was used to set the device options, etc. I believe you
> could put together all the useful heuristics in the server.

fwiw, with ABI12, most of this is available in the driver now too.
config_info and _source are are the two important ones here.
the InputClass information isn't, but the InputAttributes are.

> > for example, for wacom we must use the same device path for multiple
> > devices and it's valid to configure one device but let the others be
> > hotplugged.
> 
> This is the tricky part. Doesn't wacom handle this by just making
> another call to NewInputDeviceRequest? In that case, I think we could
> just add a flag to the call ignore_dupes or something. Or, you could
> make it an Option for anyone to use. Option "IgnoreDuplicates", which
> defaults to "True". When wacom wants to add it's extra devices, it
> just adds another InputOption { "IgnoreDuplicates", "False" }.

wacom only calls NIDR for automatically hotplugged devices, but not for the
ones in the xorg.conf. so you may have a static configuration for the stylus
and the eraser, but leave the pad, cursor, and touch hotplugged. this is a
rather exotic configuration but i've seen quite some interesting ones.

in this case, you have two xorg.conf sections pointing to a device that may
be a symlink along the line of /dev/input/wacom while at the same time have
a hotplugged device on /dev/input/event10. the driver knows they are the
same through stat(2), but the server? it could open the device but even then
it wouldn't know if the configuration is valid nonetheless. for some drivers
it is, for others it isn't.

but you're right, there's probably a way to do it right in the server, I
just never had the time or motivation to sit down and figure it out.

Cheers,
  Peter

> Maybe I'm missing something? I know you've probably time thinking
> about this before, but in my mind it seems like the server is the
> better place to handle these types of decisions.
>