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

[Dan Nicholson]

On Mon, Mar 21, 2011 at 5:01 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> 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.

Yeah, I really wanted to review that series, but was just too busy.
Glad to hear the drivers have more info since udev gives us most of it
for free.

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

Well, I have that one patch I've floated to you a couple times about
hotplugging with InputDevice. It's been a while since I looked at it,
but I think it handles two cases:

1. We added the InputDevice from xorg.conf because it's in a
ServerLayout and now udev is telling us about the same device.

2. We get a hotplugged device and realize there's an appropriate
InputDevice section and use the configuration there instead of merging
InputClass sections.

I never knew about the wacom case at the time. If I get sufficiently
motivated, I'll try to figure out a way for the server to manage it
and send a patch set.

--
Dan