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

[Dan Nicholson]

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.

> 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" }.

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.

--
Dan