[RFC PATCH] Handle hotplugged devices from xorg.conf

[Dan Nicholson]

On Thu, Dec 4, 2008 at 3:06 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Thu, Dec 04, 2008 at 09:31:07AM -0800, Dan Nicholson wrote:
>> > The problem we have now though is that it splits the configuration, and with
>> > this patch even more so. As you said, "there is something to be said for
>> > having a global configuration". I think we either need a way in xorg.conf to
>> > classify groups of devices, or a way to ease particular device configuration
>> > in HAL. Trying to unify them will just cause more problems.
>>
>> The people I was aiming at are the ones who have devices in xorg.conf right now.
>>
>> "My options are being ignored!"
>> "Oh, you need to write an fdi file now."
>> "But it was already working in xorg.conf."
>
> yeah, however there's an important difference hidden in there. The reason the
> configuration was even feasable was because you only ever had one device (most
> people, anyway). The kernel did the multiplexing for you into /dev/input/mice
> and that was the device you configured. Likewise with the keyboard.
> Now we see each device separately. If you do an xinput --list on a pre-1.4
> server and one now (same hardware setup), you'll notice the difference.
> For example, my laptop, without anything connected over usb, shows 10 input
> devices.

Yeah, I get something like 6 on my laptop and 3 on my desktop.
However, how many of those devices do you actually want to configure?
I wouldn't even know what to put for my power button or "Macintosh
mouse button emulation" (I still don't even know what it is). Having
these devices recognized by HAL and automatically added with defaults
is great.

Most likely, though, I have 2-3 input devices that I actually want to
configure. IMO, doing that in xorg.conf is reasonable.

> Most people claiming that their options are being ignored - they're trying to
> configure devices that don't actually exist anymore (like the
> /dev/input/mice).
> Want 3 button emulation? On which of the 3 mice you actually have?
> Having xorg.conf entries for each device isn't really feasable anymore.

I will definitely concede that if you're plugging in a lot of devices
that writing configuration in xorg.conf would be tedious. Here's a
case where someone has a totally acceptable looking (except for using
the non-persistent device file) InputDevice section:

http://lists.freedesktop.org/archives/xorg/2008-November/040247.html

Looking at evdev(4), I would expect that would work. And yet what he
got was bizarre behavior with VT switches.

> AFAICT, devices that traditionally needed configuration in the config
> (synaptics and wacom) still work fine when present in the config.
> Of course, having them in the xorg.conf means they're not hot-pluggable which
> makes the whole thing more interesting. I think your patch would solve at
> least this issue.
>
>> I'm not arguing against using HAL or dbus, and I think they make Xorg
>> much more useful. What I don't like is that the current implementation
>> breaks setups in bizarre (to the casual observer) ways. I mean it's
>> perfectly normal to configure output devices in xorg.conf. Until
>> recently, that was the case for input devices, too.
>>
>> >> >> +    /* Is the InputDevice specified as a core device in the active layout? */
>> >> >> +    for (devs = xf86ConfigLayout.inputs; devs && *devs; devs++) {
>> >> >> +        IDevPtr idp = *devs;
>> >> >> +        if (strcmp(idev->identifier, idp->identifier) != 0)
>> >> >> +            continue;
>> >> >> +        if (idp->commonOptions &&
>> >> >> +            (xf86CheckBoolOption(idp->commonOptions, "CorePointer", FALSE) ||
>> >> >> +             xf86CheckBoolOption(idp->commonOptions, "CoreKeyboard", FALSE)))
>> >> >> +            return True;
>> >> >> +        if (idp->extraOptions &&
>> >> >> +            (xf86CheckBoolOption(idp->extraOptions, "CorePointer", FALSE) ||
>> >> >> +             xf86CheckBoolOption(idp->extraOptions, "CoreKeyboard", FALSE)))
>> >> >> +            return True;
>> >> >> +    }
>> >> >
>> >> > you really really want TRUE as default here.
>> >>
>> >> You mean as the default arg to CheckBoolOption? I want it to return
>> >> FALSE unless it's actually set to TRUE in the configuration. From my
>> >> understanding, passing TRUE would mean that I would get that back if
>> >> the Option wasn't set. Then I would incorrectly match devices that
>> >> weren't marked as CorePointer/Keyboard.
>> >
>> > the server's default behaviour is to assume all devices as core devices unless
>> > specified otherwise. Makes sense, as non-core devices wouldn't actually move
>> > the pointer and couldn't interact with non-XI apps.
>> > Really, the whole is-core and not-core isn't really that important anymore
>> > since the rework for input-hotplug.
>> >
>> > So you need to assume true by default unless specified otherwise in the
>> > config.
>>
>> I think I'm misstating my intention with this function, and I think it
>> could be greatly simplified and rolled into the duplicate device
>> checking. What it should be called is
>> device_is_already_added_by_HandleConfigFile. :)
>
> Oh. Huge difference between "core devices" and "xorg.conf devices" :)

Yeah, sorry. I think I've made it abundantly clear that I don't really
understand the concept of "Core" devices very well.

>> But I think all the Core business can be ignored if we just check if that
>> identifier has already been added. So, iterate inputInfo.device, comparing
>> idev->identifier and dev->name. If they match, then it was handled as part
>> of the layout or whatever and can be ignored. Does that make sense? Does
>> dev->name get set from idev->identifier?
>
> dev->name for HAL devices is the input.product line which (usually) is the
> same for the same hardware. If you plug in three of the same mice, they'll all
> be called "Generic USB Mouse" or similar. That's why matching on "Synaptics
> PS/2 Touchpad" works, they're all called that way.
>
> Anyway, what I'm trying to say is that matching on dev->name only gets you so
> far before it becomes iffy.

Right. However, I'm not trying to match devices added by config/hal.
I'm trying to match devices that have been added from xorg.conf via
HandleConfigFile. In that case, idev->identifier is the Identifier
tag. My question is, does idev->identifier always become dev->name? It
seems that this is actually handled by the driver, who could set it to
anything they wanted.

Even so, it's still hacky because you could make your Identifier the
same as info.product. One reliable way to handle this is to make the
HandleConfigFile devices set config_info to something like
"layout:Identifier".

>> I'll resend the patch with these changes. If it's really not wanted,
>> then at least the archives will have it. :)
>
> Much appreciated, although I'm still not convinced that it's the real solution
> to our problems.

Thanks for looking it over. I already did all the hard work, so it's
only a little more effort to polish it up. I also don't think it
solves all our problems. Just some minor ones with the bonus that I
now have some sort of grasp on how input devices are setup. :)

--
Dan