FS#28049 - udev 178-1: Wrong keymap
Attached to Project:
Arch Linux
Opened by TF (Johnny_Five) - Sunday, 22 January 2012, 14:12 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 24 January 2012, 23:33 GMT
Opened by TF (Johnny_Five) - Sunday, 22 January 2012, 14:12 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 24 January 2012, 23:33 GMT
|
Details
Since the upgrade from 175 to 178 udev does not load the
correct keymap file on my Samsung netbook.
Keys like BrightnessUp/Down and a bunch of others do not work. The correct keymap is samsung-other and it should be loaded from 95-keymap.rules, line 141: ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", RUN+="keymap $name samsung-other" $ cat /sys/class/dmi/id/{sys_vendor,product_name} SAMSUNG ELECTRONICS CO., LTD. N145P/N250P/N260P Manual loading of the keymap (# sudo /lib/udev/keymap -i input/event0 samsung-other) fixes the issue. |
This task depends upon
Closed by Tom Gundersen (tomegun)
Tuesday, 24 January 2012, 23:33 GMT
Reason for closing: Fixed
Additional comments about closing: udev-179 is in [testing]
Tuesday, 24 January 2012, 23:33 GMT
Reason for closing: Fixed
Additional comments about closing: udev-179 is in [testing]
95-keymap.rules line;
ENV{DMI_VENDOR}=="LENOVO*", KERNELS=="input*", ATTRS{name}=="ThinkPad Extra Buttons", RUN+="keymap $name module-lenovo"
$ cat /sys/class/dmi/id/sys_vendor
LENOVO
Manual loading, as in the original report, solves the problem until the next reboot.
https://bugzilla.kernel.org/show_bug.cgi?id=42633
Quick fix: change your RUN+="keymap $name keymap" to RUN+="keymap input/$name keymap"
It's a bug in $name. It's a very old bug, but exposed only in the
recent udev versions. I'll fix it.
Thanks,
Kay
http://www.spinics.net/lists/hotplug/msg05311.html
Sorry, but I put the description here: https://bbs.archlinux.org/viewtopic.php?pid=1046260 - seems similar, only in my case loading keymap manually or using udev-git doesn't solve the problem. :(
@ajax: if the new release does fix it for you please open a new bug report as this sounds like a different bug. Before you do, please check that there are no stale (not owned by any package) files under /lib/udev/. Or maybe following up on the ml message you posted and let them know the status after the upgrade would be more efficient :)