udev: gpio-keys input driver should have class kbd

udev: gpio-keys input driver should have class kbd

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Is this reasonable?

----- Forwarded message from Frans Pop <elendil@planet.nl> -----

From: Frans Pop <elendil@planet.nl>
To: udev@packages.debian.org
Subject: udev: gpio-keys input driver should have class kbd

clone 524505 -1
reassign -1 udev 0.140-1
retitle -1 udev: gpio-keys input driver should have class kbd
severity -1 wishlist
block 524505 by -1
thanks

With udev 0.140 (or rather: sometime after 0.125) we've lost the 
persistent device symlink /dev/input/by-path/platform-gpio-keys-event- 
due to the following change in 60-persistent-input.rules which no longer 
allows an empty ID_CLASS:

-KERNEL=="event*", ENV{ID_PATH}=="?*", \
+KERNEL=="event*", ENV{ID_PATH}=="?*", ENV{ID_CLASS}=="?*", \
        SYMLINK+="input/by-path/$env{ID_PATH}-event-$env{ID_CLASS}"

This means that qcontrol in Debian unstable is now broken (see: 
http://bugs.debian.org/524505).

It seems to me that the simplest solution is to let udev define a class 
for gpio-keys (kbd seems most logical), for example with the following 
change in 60-persistent-input.rules:

-DRIVERS=="atkbd",                      ENV{ID_CLASS}="kbd"
+DRIVERS=="atkbd|gpio-keys",            ENV{ID_CLASS}="kbd"

We can then adjust qcontrol to use the new persistent device link.

If that change is acceptable, please also push it for udev upstream.

Thanks,
FJP

----- End forwarded message -----

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: udev: gpio-keys input driver should have class kbd

[Kay Sievers]

On Sun, Apr 26, 2009 at 21:54, Marco d'Itri <md@linux.it> wrote:
> Is this reasonable?

> With udev 0.140 (or rather: sometime after 0.125) we've lost the
> persistent device symlink /dev/input/by-path/platform-gpio-keys-event-
> due to the following change in 60-persistent-input.rules which no longer
> allows an empty ID_CLASS:

> It seems to me that the simplest solution is to let udev define a class
> for gpio-keys (kbd seems most logical), for example with the following
> change in 60-persistent-input.rules:
>
> -DRIVERS="atkbd",                      ENV{ID_CLASS}="kbd"
> +DRIVERS="atkbd|gpio-keys",            ENV{ID_CLASS}="kbd"

I guess, this is any key on a system board, and is not like the usual,
pretty well defined "kbd".

For path links of platform devices, we should just create a:
  /dev/input/by-path/platform-gpio-keys-event
link, which should be fine as long as there is only a single interface
per platform device. USB devices should also be fine in having this
link, because they include the interface number in the path name.

I've committed a change along with some other pending changes to the
git repository.

Thanks,
Kay