Gentoo Archives: gentoo-user

From: daid kahl <daidxor@×××××.com>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: Keyboard Mapping Issues [solved]
Date: Wed, 18 Nov 2009 14:37:08
Message-Id: 3ac129340911180636h6380c393w4b4e15d57897f2fe@mail.gmail.com
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