cosmetic udev glitches

[Dan Nicholson]

On Tue, Mar 9, 2010 at 3:10 AM, Simon Thum <simon.thum at gmx.de> wrote:
> [switching to devel]
>
> Dan Nicholson wrote:
>> On Wed, Mar 3, 2010 at 4:59 PM, Thomas Jaeger <thjaeger at gmail.com> wrote:
>>> On 03/03/2010 07:48 PM, Dan Nicholson wrote:
>>>> On Wed, Mar 3, 2010 at 4:00 PM, Thomas Jaeger <thjaeger at gmail.com> wrote:
>>>>> The attribute 'name' might not exist (as in the case of serial wacom
>>>>> devices) and it's impossible to set it in an udev rule, I believe, so we
>>>>> should at least fall back to the NAME property if the attribute is not
>>>>> available.
>>>> Not for the parent, either? Does hal give you anything for
>>>> info.product/input.product?
>>> Sorry, I don't know, I don't have a working hal installation anymore.
>>> Here's what udev knows about the device, though:
>>>
>>> udevadm info --path=/sys/class/tty/ttyS0/ --attribute-walk
>>>
>>> ...
>>>
>>>  looking at device '/devices/pnp0/00:0a/tty/ttyS0':
>>>    KERNEL=="ttyS0"
>>>    SUBSYSTEM=="tty"
>>>    DRIVER==""
>>>
>>>  looking at parent device '/devices/pnp0/00:0a':
>>>    KERNELS=="00:0a"
>>>    SUBSYSTEMS=="pnp"
>>>    DRIVERS=="serial"
>>>    ATTRS{id}=="WACf004"
>>>
>>>  looking at parent device '/devices/pnp0':
>>>    KERNELS=="pnp0"
>>>    SUBSYSTEMS==""
>>>    DRIVERS==""
>>
>> But you do get NAME in the uevent? You can find this from "udevadm
>> info --export-db".
>>
>> Seems reasonable, though. I guess we need an additional:
>>
>> if (!name)
>>     name = udev_device_get_property_value(parent, "NAME");
> I'm having the gut feeling there is an underlying problem, that is, udev
>  maintains a graph (DAG w/root, I guess), but we're looking at
> individual nodes, thus ignoring connections (edges).

I think this particular problem is that we're expecting that the udev
data for all input devices is the same as that for usb devices.
Thomas' device clearly has a lack of information to identify it. I
think the right thing here is to work with the input/udev people to
see what we can do about identifying input devices consistently.
Whether that means there needs to be more information from the kernel
in sysfs or the uevent or that udev needs to do a better job
collecting data from non-usb input devices or both, I don't know.
Maybe they'll suggest a better way to identify the devices than
grabbing the parent's name.

The tree of devices may cause some other problems, but I think we can
be fairly naive about it just for the purposes of identification.

> IIR this also has other consequences, like trouble in the
> "native-driver-or-evdev" department. If the evdev device gets inserted
> first, how to figure we want to prefer a particular driver whose device
> is not yet known? Or ignore devices already handled, as was the case on
> my machine? Or can't this happen for some reason?
>
> Short of piling up exceptions in the evdev catch-all, I can't figure
> how. So maybe InputClasses should be cumulative, so one may create
> xorg.conf.d fragments which narrow the evdev catchall (or other
> competing classes already known) as well as advertise 'their' driver in
> one go?
>
> Essentially, I think something like this should work:
>
> General section somewhere:
>
> Section "InputClass"
>        Identifier "evdev catch all event devices"
>        Driver "evdev"
>        MatchDevicePath "/dev/input/event*"
> EndSection
>
> In another file (hypothetically dropped by driver package):
>
> # catch cool device
> Section "InputClass"
>        Identifier "we've got cool stuff"
>        Driver "uberdevice"
>        MatchProduct "Coolstuff*"
> EndSection

This is how it works today. As long as this section comes after the
evdev catchall, it will use the "uberdevice" driver. That's why on
fedora Peter has the evdev wildcard right at the beginning; something
like xorg.conf.d/00-evdev.conf. You may have been using an earlier
iteration where the first match was taken. We changed that later since
that behavior doesn't match any of the other tools.

> # make sure evdev doesn't play foul. If this section matches _and_
> # the parent class did actually match, we merge it, thus ignoring the
> # device as far as evdev is concerned. Note that ParentClass could be
> # implemented as just another match.
> Section "InputClass"
>        Identifier "don't mess with Coolstuff"
>        ParentClass "evdev catch all event devices"
>        Ignore "yes"
>        MatchProduct "Coolstuff*"
> EndSection

Likewise, Option "Ignore" is last match wins, so you could have a
section that ignores a whole set of devices only to have another class
remove that. Taking the fedora examples:

xorg.conf.d/10-quirks.conf
# Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable
# http://bugs.freedesktop.org/show_bug.cgi?id=22442
Section "InputClass"
        Identifier "ThinkPad HDAPS accelerometer blacklist"
        MatchProduct "ThinkPad HDAPS accelerometer data"
        Option "Ignore" "on"
EndSection

xorg.conf.d/50-accelerometer.conf
# Hypothetical hdaps driver that knows what to do with this device
Section "InputClass"
        Identifier "ThinkPad HDAPS accelerometer"
        MatchProduct "ThinkPad HDAPS accelerometer data"
        Driver "hdaps"
        Option "Ignore" "off"
EndSection

So, I think this can all be handled by properly created InputClass
sections right now.

--
Dan