cosmetic udev glitches

[Simon Thum]

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

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

# 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

Either I'm missing something (like udev guarantees I'm unaware of), or
this could greatly enhance deployment sanity, because evdev exceptions
can be distributed over files.

Cheers,

Simon