1 |
2009/11/18 daid kahl <daidxor@×××××.com>: |
2 |
> Hello, |
3 |
> |
4 |
> After some recent updates, my keyboard shows some strange and |
5 |
> undesirable behavior. It is a MacBook (no previous keyboard |
6 |
> problems), with US mapping and UTF-8 mode. |
7 |
> |
8 |
|
9 |
It appears that the problem is some unholy alliance between |
10 |
hal-0.5.13-r2 and the 2.6.30 gentoo-sources. I was upgrading from a |
11 |
fairly outdated kernel (2.6.27). Somehow (perhaps because hal looks |
12 |
for configurations in /usr/src/linux), even my old kernel |
13 |
functionality for hotkeys was bungled by the new kernel. The old |
14 |
kernel functionality was regained by rebuilding tons of packages |
15 |
against the properly eselected kernel. However, I have now gotten the |
16 |
hot keys working again in the newer kernel as well. |
17 |
|
18 |
The only unresolved issue is the '@' sign at command prompt is still a |
19 |
line-delete (very queer), but I regained all hotkeys and other |
20 |
features. |
21 |
|
22 |
The basic problem resulted from a new kernel configuration for the |
23 |
Apple hotkeys. Previously it was called USB_HIDINPUT_POWERBOOK (up |
24 |
until at least 2.6.27), but as of 2.6.28 (and up to at least 2.6.30) |
25 |
this is now called HID_APPLE. Although this feature got enabled from |
26 |
doing oldconfig, somehow it 'missed' a dependency. So in the raw |
27 |
.config it's showing up as being activated, but it won't show up in |
28 |
menuconfig. Using the menuconfig search tool (/) then I could check |
29 |
the dependencies of HID_APPLE, which I was missing EMBEDDED (it also |
30 |
depends on HID_SUPPORT && HID && (USB_HID || BT_HIDP)). This is, I |
31 |
suppose, a problem because I didn't follow my own advice to avoid |
32 |
oldconfig from very different kernel versions, as it can result in |
33 |
funky half-baked transformation of rule-name changes like the above. |
34 |
|
35 |
Then once I loaded HID_APPLE as a module, I could add a module rule |
36 |
which I called /etc/modprobe.d/fn-key : |
37 |
|
38 |
options hid_apple fnmode=2 |
39 |
|
40 |
Function mode 2 means that the F1-12 keys should behave as normal |
41 |
function keys, and only act like special hotkeys if I press the 'Fn' |
42 |
key -- I expect most Linux users would want this behavior...unless you |
43 |
like making the claw-hand to Fn-Alt-F4 and close windows... |
44 |
|
45 |
Just for a full report (and Google hits for other unfortunates), in |
46 |
the past, this was done through the usbhid module like: |
47 |
options hid pb_fnmode=2 |
48 |
|
49 |
At some point the battery indicator in xfce4-battery-plugin was |
50 |
reading 0 (tested some other indicators such as the |
51 |
xfce4-power-manager and got the same results). I regained proper |
52 |
battery % display by taking out the battery, rebooting into Mac OS, |
53 |
putting the battery back in, and rebooting back to Gentoo; maybe just |
54 |
temporarily removing the battery alone or booting to Mac OS alone was |
55 |
good enough, but I just did both at once through intuition. It's not |
56 |
at all clear which package was responsible for this bungling, since I |
57 |
was variously upgrading and downgrading e2fsprogs, e2fsprogs-libs, |
58 |
util-linux (none of these three are recommended for switching |
59 |
versions, by the way -- you probably need the buildpkg feature enabled |
60 |
in portage), udev, xf86-input-evdev, hal, device-mapper, and lvm2. If |
61 |
I had to guess, I'd say it was udev since now when I pull the power |
62 |
cable the screen auto-dims, which sounds like a udev feature (but I |
63 |
didn't scan the udev rules.d directory yet) -- but it was almost |
64 |
certainly hal, udev, or evdev, since those were the upgrades when I |
65 |
noticed on reboot that the battery read 0%. |
66 |
|
67 |
pommed had to rebuilt as well to get back volume control features. |
68 |
This was somewhere in the annoyance with ALSA not doing things |
69 |
correctly for my volume. I didn't test it, but it's possible pommed |
70 |
hotkeys don't work correctly in the old kernel now, since alsa and the |
71 |
keyboard mapping changed a bit in the 3 kernel versions. Now that |
72 |
everything works in the new kernel, I don't care to test. |
73 |
|
74 |
I wish my report on the upgrade from 2.6.27 to 2.6.30 was more |
75 |
systematic, but after so much work to get things functional, I'm in no |
76 |
position to go break it all again and pin point exactly the issue. |
77 |
But it seems to have been almost entirely in the kernel. |
78 |
|
79 |
Regards, |
80 |
daid |