[arch-general] Apple keyboard broken in [testing]
Hi all. I'm experiencing a strange problem with my Apple aluminium keyboard: a few days ago the F1-F4 keys stopped working, and the ` and < keys were swapped (meaning: pressing one of the keys gives the output of the other). If I changed my layout the same two keys were swapped, even though they now mapped other carachters, so it should be a scancode problem. This happens in both X and in console, the keyboard was working fine before and it works fine if plugged to any other machine. Hard to say which package broke the whole thing, since it happened after a 600MB upgrade, but I suspect the usual udev... Trying to fix the problem I plugged another usb keyboard to the same port, but everything was ok, so I began playing with showkey and xev. Result: the Apple keyboard returns different scancodes and keycodes from the other one. The same kayboard is broken on the two Arch machines I own, which both run testing, and I was able to find a user on IRC with the very same keyboard working outside of testing. Downgrading xorg-server did not work (as I expected, since the console is broken, too) and I'm starting to run out of ideas. Any help will be greatly appreciated. Corrado
As it always happens after sending an e-mail, there's an update a few minutes later... On Sun, Mar 9, 2008 at 3:28 PM, bardo <ilbardo@gmail.com> wrote:
few days ago the F1-F4 keys stopped working, and the ` and < keys were swapped
I found out how to make F1-F4 work again: it seems the Fn button is needed to generate the correct code with those keys, but also with F7-F12. These keys have in common a special function, like triggering expose, changing backlight, changing songs and muting sound. Still I don't get why they worked before, and I haven't found anything about the swapped keys. C.
On Sun, Mar 9, 2008 at 3:39 PM, bardo <ilbardo@gmail.com> wrote:
I found out how to make F1-F4 work again: it seems the Fn button is needed to generate the correct code with those keys, but also with F7-F12.
This can be fixed quite easily if you know how: echo 2 > /sys/module/hid/parameters/pb_fnmode Only the two swapped keys remain. Setkeycodes didn't work, I think it's because the keycodes I'm trying to use are already registered to something else, so I just created a custom keymap which swapped the two keycodes, 41 and 86, and now everything works fine. Wandering through the gentoo forums I found out that aluminium keyboards aren't properly detected until 2.6.25rc2, the strange thing is I had the keyboard working before... I'll see when 2.6.25 is released. Corrado
2008/3/9, bardo <ilbardo@gmail.com>:
Hi all. I'm experiencing a strange problem with my Apple aluminium keyboard: a few days ago the F1-F4 keys stopped working, and the ` and < keys were swapped (meaning: pressing one of the keys gives the output of the other). If I changed my layout the same two keys were swapped, even though they now mapped other carachters, so it should be a scancode problem. This happens in both X and in console, the keyboard was working fine before and it works fine if plugged to any other machine. Hard to say which package broke the whole thing, since it happened after a 600MB upgrade, but I suspect the usual udev...
Trying to fix the problem I plugged another usb keyboard to the same port, but everything was ok, so I began playing with showkey and xev. Result: the Apple keyboard returns different scancodes and keycodes from the other one. The same kayboard is broken on the two Arch machines I own, which both run testing, and I was able to find a user on IRC with the very same keyboard working outside of testing. Downgrading xorg-server did not work (as I expected, since the console is broken, too) and I'm starting to run out of ideas. Any help will be greatly appreciated.
There was a bug in kernel related to defkeymap, now fixed in the latest kernel package, but it was related mostly to accents, not to normal keycodes. -- Roman Kyrylych (Роман Кирилич)
On Sun, Mar 9, 2008 at 3:45 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
There was a bug in kernel related to defkeymap, now fixed in the latest kernel package, but it was related mostly to accents, not to normal keycodes.
Thanks for the input, Italian accents are working fine though: àèéìòù. C.
participants (2)
-
bardo
-
Roman Kyrylych