[RFC PATCH] Handle hotplugged devices from xorg.conf

[Peter Hutterer]

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.

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.

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" :)

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

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

Cheers,
  Peter