Udev loads wrong keymap

Udev loads wrong keymap

[Tobias Frilling]

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 (# /lib/udev/keymap -i input/event0
samsung-other) fixes the issue.

Other users reported similar bugs, see
https://bugs.archlinux.org/task/28049

Udev loads wrong keymap

[Tobias Frilling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 (# /lib/udev/keymap -i input/event0
samsung-other) fixes the issue.

Other users reported similar bugs, see
https://bugs.archlinux.org/task/28049
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPHGutAAoJEEDINPnaM7l+TUwH/3ugfyTQaqddHfNjE7K5+Yr0
4F2ZwORtGvdXGKtTWZNIj1lMuWxMpr4oNID9XScGYnIeaJnwokeeiIXpogZgTea3
EufWGpB9TTLKMHIUqlqmkuM4Thl+b8z5++xyf6O85mvDwfiwq9RSOx7XtXRf6cgq
TrZ6pUWdLBcvsvcr8w6K1p7zaF86L9ZogAGxTDRR9owaly+61G5AgEhQ44HxUsK2
satti7kJX8NWyyBm7Uq8tLnHTAoOidZrr918WjJdl7JCHlc5aiT3T54f+GKZWcwm
y1ssI79U0+WZy8qGAN4P0MjcPr/QBzH7MbRgScbbz60kaj5CyP/vEQtB9pvsCHA=9ZTt
-----END PGP SIGNATURE-----

Re: Udev loads wrong keymap

[Kay Sievers]

On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
<tobias@frilling-online.de> wrote:
> 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 (# /lib/udev/keymap -i input/event0
> samsung-other) fixes the issue.
>
> Other users reported similar bugs, see
> https://bugs.archlinux.org/task/28049

What does:
  $ udevadm test /sys/class/dmi/id
say?

Kay

Re: Udev loads wrong keymap

[Kay Sievers]

On Sun, Jan 22, 2012 at 21:08, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
> <tobias@frilling-online.de> wrote:
>> 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 (# /lib/udev/keymap -i input/event0
>> samsung-other) fixes the issue.
>>
>> Other users reported similar bugs, see
>> https://bugs.archlinux.org/task/28049
>
> What does:
>  $ udevadm test /sys/class/dmi/id
> say?

And find the keyboard number X:
  $ grep . /sys/class/input/input*/name

and run:
  $  udevadm test /sys/class/input/eventX

Kay

Re: Udev loads wrong keymap

[Kay Sievers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1617 bytes --]

On Sun, Jan 22, 2012 at 21:37, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 22, 2012 at 21:08, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
>> <tobias@frilling-online.de> wrote:
>>> 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 (# /lib/udev/keymap -i input/event0
>>> samsung-other) fixes the issue.
>>>
>>> Other users reported similar bugs, see
>>> https://bugs.archlinux.org/task/28049
>>
>> What does:
>>  $ udevadm test /sys/class/dmi/id
>> say?
>
> And find the keyboard number X:
>  $ grep . /sys/class/input/input*/name
>
> and run:
>  $  udevadm test /sys/class/input/eventX

The test run shows that it would execute the keymap tool:

  udev_rules_apply_to_event: RUN 'keymap $name samsung-other'
    /lib/udev/rules.d/95-keymap.rules:141
  ...
  USEC_INITIALIZED99737
  run: 'keymap event0 samsung-other'

If you run '/lib/udev/keymap event0 samsung-other', does it work?

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Udev loads wrong keymap

[Kay Sievers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 1912 bytes --]

On Sun, Jan 22, 2012 at 21:49, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Jan 22, 2012 at 21:37, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Sun, Jan 22, 2012 at 21:08, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>> On Sun, Jan 22, 2012 at 21:03, Tobias Frilling
>>> <tobias@frilling-online.de> wrote:
>>>> 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 (# /lib/udev/keymap -i input/event0
>>>> samsung-other) fixes the issue.
>>>>
>>>> Other users reported similar bugs, see
>>>> https://bugs.archlinux.org/task/28049
>>>
>>> What does:
>>>  $ udevadm test /sys/class/dmi/id
>>> say?
>>
>> And find the keyboard number X:
>>  $ grep . /sys/class/input/input*/name
>>
>> and run:
>>  $  udevadm test /sys/class/input/eventX
>
> The test run shows that it would execute the keymap tool:
>
>  udev_rules_apply_to_event: RUN 'keymap $name samsung-other'
>    /lib/udev/rules.d/95-keymap.rules:141
>  ...
>  USEC_INITIALIZED99737
>  run: 'keymap event0 samsung-other'
>
> If you run '/lib/udev/keymap event0 samsung-other', does it work?

We used the sysfs device name for $name substitutions, which does not
work correctly for device nodes which are in a subdirectory.

This but got exposed by other recent changes, and this should fix it:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h°a00806770a7443d1710d58190a65b4f9f4f60e

Thanks,
Kay

Udev loads wrong keymap

[ajaxas]

Good evening!

I'm sorry this mail is out of thread, I just subscribed so I can't reply.

There are people (including me) who report that fix doesn't solve the
problem: brightness keys on many laptops still don't work with the GIT
version of udev.

I will describe my problem down here, but it might be easier to read
my post on archlinux forums:
https://bbs.archlinux.org/viewtopic.php?pid\x1046260

-----

My specs:
Hardware: SONY VAIO VPC-EH2L1R
Linux distribution: archlinux, XFCE
udev versions: 177, 178 (core), udev-git 20120123-1 (AUR)
keyboard driver: evdev

At least a week earlier I had some of Sony Vaio Keys working: Volume
control (Fn+F2: mute, Fn+F3: down, Fn+F4: up) and Brightness control
(Fn+F5: down, Fn+F6: up). Other Vaio Keys (Fn+F1: touchpad switch,
Fn+F7: switch video mode, Fn+F12: suspend) never worked.
At some point (I think after updating to udev-177-1) Brightness
control keys stopped working. Volume control keys still work.
Brightness control still works directly via acpi.

I blame it on udev, however, downgrading to udev-175 doesn't solve the
problem. Neither does updating to GIT version of udev or loading
correct keymap (module-sony) manually.

I also observe some interesting quirks which may give a clue to
someone more adept in linux than me.

My keyboards are detected correctly:

> [ajaxas@r2d2 ~]$ /lib/udev/findkeyboards
> AT keyboard: input/event0
> module: input/event1

where input/event1 is Sony Vaio Keys, /proc/bus/input/devices lists it properly.

However, my Volume control keys seem to be mapped to input/event0
(keyboard itself):

> [root@r2d2 ajaxas]# /lib/udev/keynap -i input/event0
> scan code: 0xA0   key code: mute
> scan code: 0xAE   key code: volumedown
> scan code: 0xB0   key code: volumeup

and these scan codes correspond not to my keymap (0x06, 0x07, 0x08),
but to /lib/udev/keymaps/force-release/common-volume-keys. Manually
removing that keymap and even udev rule for force-release doesn't
change anything (!).

On the other hand, my Brightness control keys, mapped as 0x09 and 0x0A
in the keymap, are reported by udev as:

> [root@r2d2 ajaxas]# /lib/udev/keymap -i input/event1
> scan code: 0x10   key code: brightnessdown
> scan code: 0x11   key code: brightnessup

If I change my keymap file (0x09 -> 0x10, 0x0A -> 0x11) and load
keymap manually, nothing changes. And when I reboot with this changed
keymap, udev reports this for my Brightness control keys:

> [root@r2d2 ajaxas]# /lib/udev/keymap -i input/event1
> scan code: 0x10   key code: fn_f5
> scan code: 0x11   key code: fn_f6

Again, nothing works, and keys are not reported as Brightness control
keys anymore. Here's where I'm lost.

Could you please help me?

With best regards,
Vladimir

Re: Udev loads wrong keymap

[Martin Pitt]

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

Hello Ajaxas,

ajaxas [2012-01-24 20:28 +0700]:
> At least a week earlier I had some of Sony Vaio Keys working: Volume
> control (Fn+F2: mute, Fn+F3: down, Fn+F4: up) and Brightness control
> (Fn+F5: down, Fn+F6: up). Other Vaio Keys (Fn+F1: touchpad switch,
> Fn+F7: switch video mode, Fn+F12: suspend) never worked.
> At some point (I think after updating to udev-177-1) Brightness
> control keys stopped working. Volume control keys still work.
> Brightness control still works directly via acpi.

Note that between udev 175 and 179 the Sony rules and keymaps did not
change at all. The only bug I am aware of is the one you already
pointed out in your forum post, and you said that the fix [1] did not
help.

> I blame it on udev, however, downgrading to udev-175 doesn't solve the
> problem.

OK, this is consistent with what you and I wrote above.

On your forum post you say that keymap -i actually shows the right key
codes (brightnessup/brightnessdown) when you press the corresponding
keys. Can you confirm that this is still true with the latest udev?
Once that's working, all the udev rules, keymaps, etc. have already
been exercised.

Could it be that you upgraded something else in e. g. GNOME which now
fails to act on the key events? You could try "xev" to see whether you
get proper X11 events for these keys, and try a fresh user account to
ensure it's not some changed configuration of your's.

> However, my Volume control keys seem to be mapped to input/event0
> (keyboard itself):
> 
> > [root@r2d2 ajaxas]# /lib/udev/keynap -i input/event0

Funny "keynap" typo :)

> > scan code: 0xA0   key code: mute
> > scan code: 0xAE   key code: volumedown
> > scan code: 0xB0   key code: volumeup

It's a bit unexpected indeed, I had expected these to also come out of
the "Sony Vaio Module"; does anythign happen on keymap -i input/event1
if you press these keys?

> and these scan codes correspond not to my keymap (0x06, 0x07, 0x08),
> but to /lib/udev/keymaps/force-release/common-volume-keys.

This is a sheer coincidence. common-volume-keys is not applied on
Sony, so that's not relevant here.

> If I change my keymap file (0x09 -> 0x10, 0x0A -> 0x11) and load
> keymap manually, nothing changes. And when I reboot with this changed
> keymap, udev reports this for my Brightness control keys:
> 
> > [root@r2d2 ajaxas]# /lib/udev/keymap -i input/event1
> > scan code: 0x10   key code: fn_f5
> > scan code: 0x11   key code: fn_f6

This just double-confirms that the current keymap is correct and gets
loaded properly.

> Again, nothing works, and keys are not reported as Brightness control
> keys anymore. Here's where I'm lost.

Reported to where? keymap -i certainly seems to get them correct. Are
they lost in xev?

Did you happen to upgrade X.org recently? 1.12 introduces a completely
new input stack, and some distros might already use that (I know
Ubuntu's X.org 1.11 packages have that backported for the multi-touch
stuff, for example).

Thanks,

Martin

[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=e605cf7782fdf1dc2e13b95e906e731d61e6cf12

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: Udev loads wrong keymap

[ajaxas]

Thank you for your fast reply! And it was ultimately useful!

I should have known better than to trust XFCE, as I've already had my
troubles with it's stupid components interfering with xorg settings.
Following your instructions step by step I installed udev-179 from
testing repository (nothing changed), tried xev (it responded) and
then created new user only to find Brightness control keys working.

Now I have to find what XFCE component is responsible for this.

Although I still don't know why my Volume control scan codes differ
from those in module-sony keymap file.

>> > [root@r2d2 ajaxas]# /lib/udev/keynap -i input/event0
>
> Funny "keynap" typo :)

Yeah, well, I had to switch to the console and use |tee, which of
course didn't capture the command itself, so I typed it by hand only
to disgrace myself even more :)

> Thanks,
>
> Martin

Thank you very much, Martin!

--
With best regards,
Vladimir

Re: Udev loads wrong keymap

[Robby Workman]

On Wed, 25 Jan 2012 20:51:35 +0700
ajaxas <ajaxas@gmail.com> wrote:

> Thank you for your fast reply! And it was ultimately useful!
> 
> I should have known better than to trust XFCE, as I've already had my
> troubles with it's stupid components interfering with xorg settings.
> Following your instructions step by step I installed udev-179 from
> testing repository (nothing changed), tried xev (it responded) and
> then created new user only to find Brightness control keys working.
> 
> Now I have to find what XFCE component is responsible for this.


Probably xfce4-xkb-plugin - it doesn't inherit any current keyboard
settings when it switches a layout (note that this isn't necessarily
a bug in itself), so perhaps the layout that it applies is somehow
bad.


> Although I still don't know why my Volume control scan codes differ
> from those in module-sony keymap file.


Do you have xfce4-volumed (and its dep, keybinder) installed?  I don't
know what they might be doing (if anything), but perhaps that's a 
place to start looking...

-RW

Re: Udev loads wrong keymap

[ajaxas]

On Wed, Jan 25, 2012 at 9:18 PM, Robby Workman <robby@rlworkman.net> wrote:
> On Wed, 25 Jan 2012 20:51:35 +0700
> ajaxas <ajaxas@gmail.com> wrote:
>
>> Thank you for your fast reply! And it was ultimately useful!
>>
>> I should have known better than to trust XFCE, as I've already had my
>> troubles with it's stupid components interfering with xorg settings.
>> Following your instructions step by step I installed udev-179 from
>> testing repository (nothing changed), tried xev (it responded) and
>> then created new user only to find Brightness control keys working.
>>
>> Now I have to find what XFCE component is responsible for this.
>
>
> Probably xfce4-xkb-plugin - it doesn't inherit any current keyboard
> settings when it switches a layout (note that this isn't necessarily
> a bug in itself), so perhaps the layout that it applies is somehow
> bad.

No, I already have this removed for the greater justice.
I think I got it: when udev in archlinux updated to 177 and brightness
control stopped working, I (unaware of that being a udev problem)
started searching for solution and, well, broke something. F.e., I
found ~/.Xmodmap file with some strange instructions.

>> Although I still don't know why my Volume control scan codes differ
>> from those in module-sony keymap file.
>
>
> Do you have xfce4-volumed (and its dep, keybinder) installed?  I don't
> know what they might be doing (if anything), but perhaps that's a
> place to start looking...

Yes, I do. Also I tried disabling it and nothing changed. Perhaps, I'm
gonna try removing it form the system.
Also, Fn+F1 / F7 / F12 still don't work, though among these 3 I only
need Fn+F1 (switch touchpad on/off).
But that's how it was from the beginning! :)

--
With best regards,
Vladimir