* Two keys ( < ^ ) were incorrectly swapped for no apparent reason. * The F-keys stopped working to a usable level expected by a normal Linux user. Modify default FN key behavior on Apple keyboards. diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index 5c52a20..e659e9e 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -32,7 +32,7 @@ #include <linux/hid.h> #include <linux/hid-debug.h> -static int hid_apple_fnmode = 1; +static int hid_apple_fnmode = 2; module_param_named(pb_fnmode, hid_apple_fnmode, int, 0644); MODULE_PARM_DESC(pb_fnmode, "Mode of fn key on Apple keyboards (0 = disabled, 1 = fkeyslast, 2 = fkeysfirst)"); diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c index 1df832a..bf7d0ae 100644 --- a/drivers/hid/usbhid/hid-quirks.c +++ b/drivers/hid/usbhid/hid-quirks.c @@ -634,7 +634,7 @@ static const struct hid_blacklist { { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI, HID_QUIRK_APPLE_HAS_FN }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO, HID_QUIRK_APPLE_HAS_FN }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS, HID_QUIRK_APPLE_HAS_FN }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE },
lsusb Bus 006 Device 007: ID 05ac:0221 Apple Computer, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x05ac Apple Computer, Inc. idProduct 0x0221 bcdDevice 0.67 iManufacturer 1 Apple, Inc iProduct 2 Apple Keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 20mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 13 International (ISO) bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 75 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 47 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) Bus 006 Device 006: ID 05ac:1006 Apple Computer, Inc. Hub in Apple Aluminum Keyboard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x05ac Apple Computer, Inc. idProduct 0x1006 Hub in Apple Aluminum Keyboard bcdDevice 94.15 iManufacturer 1 Apple, Inc. iProduct 2 Keyboard Hub iSerial 3 000000000000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x008d Per-port power switching Compound device Per-port overcurrent protection TT think time 8 FS bits Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 200 milli Ampere DeviceRemovable 0x04 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0303 lowspeed power enable connect Port 3: 0000.0100 power Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered)
Created attachment 16318 [details] my tux got repetitive strain injury
Created attachment 16320 [details] vanila2.6.26_fix-apple-keyboard.patch
Adding Diego to CC, as this has been caused by his patch.
The Fx key behaviour is something that I think comes up over and over. In the mail thread started by Dag Bakke, which I was CCed on by Andrew Morton, Matthew Garret replied: > On Tue, May 06, 2008 at 12:54:06PM -0700, Andrew Morton wrote: > > > > -static int hid_apple_fnmode = 1; > > > +static int hid_apple_fnmode = 2; > > Regardless of anything else, we don't want this hunk. As for the swap, that's something that bothers me, but I didn't really "cause" it, it already was there on 2.6.25 before my patch. It's the usual behaviour of the Apple ISO keyboards. By the naming of < and ^ I suppose it's not an US keyboard, I'd suppose German? I'm not sure why Apple does it this way but it is true that the _US_ variant of the Apple ISO keyboards have the `~ key in the bottom left corner rather than in the upper left corner. Maybe this should become its own quirk with its own switch to enable/disable it? I can work on that, sincerely I dislike that choice too and have X remapped to put them back.
Created attachment 16322 [details] german layout
(In reply to comment #5) > The Fx key behaviour is something that I think comes up over and over. In the > mail thread started by Dag Bakke, which I was CCed on by Andrew Morton, > Matthew > Garret replied: > > > On Tue, May 06, 2008 at 12:54:06PM -0700, Andrew Morton wrote: > > > > > > -static int hid_apple_fnmode = 1; > > > > +static int hid_apple_fnmode = 2; > > > > Regardless of anything else, we don't want this hunk. Then somebody should tell Linus, that Andrew & co. are horribly wrong. Imagine Linus' daughter is sticking this Keyboard in any machine with recent kernel and it breaks his hands. > > As for the swap, that's something that bothers me, but I didn't really > "cause" > it, it already was there on 2.6.25 before my patch. It's the usual behaviour > of > the Apple ISO keyboards. By the naming of < and ^ I suppose it's not an US > keyboard, I'd suppose German? Right, see attachment. > > I'm not sure why Apple does it this way but it is true that the _US_ variant > of > the Apple ISO keyboards have the `~ key in the bottom left corner rather than > in the upper left corner. Maybe this should become its own quirk with its own > switch to enable/disable it? I can work on that, sincerely I dislike that > choice too and have X remapped to put them back. > Not mentioning Alice, the frame buffer hacker. It may be hard to convince this guy to fix his firmware http://www.lulehome.de/blog/media/mac_tastatur2.jpg so it will be great if we can somehow apply this quirk only to the us keyboard. Thanks Martin
Yep I see your point, the German layout is fine, just like the Italian one. I doubt it's possible to get the keyboard to let us know which layout it has, I don't think I have ever seen OSX doing that either (although it seems to know what the laptop layout is). That particular quirk could be moved from the kernel to the userspace though, I suppose, with either kbd or x11 doing the remap upon user request. Changing this might be a bit of an abrupt change, but making it optional now, making it default off in a further release, and then removing the option even further on, giving time to userspace to deal with the issue, could be a nice way to resolve the issue... I actually was thinking about that after I fixed the numlock issue, but then I thought it would probably have been just me. As for the Fx mode, it can be changed either as a module or kernel parameter or through a change to /sys/module/hid/parameters/pb_fnmode, so I wouldn't be that dramatic ;)
(In reply to comment #8) > Yep I see your point, the German layout is fine, just like the Italian one. > > I doubt it's possible to get the keyboard to let us know which layout it has, > I Are the us and the other layout HID descriptors exactly the same? > don't think I have ever seen OSX doing that either (although it seems to know > what the laptop layout is). That particular quirk could be moved from the > kernel to the userspace though, I suppose, with either kbd or x11 doing the > remap upon user request. > > Changing this might be a bit of an abrupt change, but making it optional now, > making it default off in a further release, and then removing the option even > further on, giving time to userspace to deal with the issue, could be a nice > way to resolve the issue... I actually was thinking about that after I fixed > the numlock issue, but then I thought it would probably have been just me. > > As for the Fx mode, it can be changed either as a module or kernel parameter > or > through a change to /sys/module/hid/parameters/pb_fnmode, so I wouldn't be > that > dramatic ;) -rw-r--r-- 1 root root 4,0K 2008-05-29 20:48 /sys/module/hid/parameters/pb_fnmode Well, maybe she is more clever than the daddy and knows some universal root exploit ;) BTW, I just don't grasp the reasoning here.
I think so: Bus 001 Device 004: ID 05ac:1006 Apple, Inc. Hub in Aluminum Keyboard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x05ac Apple, Inc. idProduct 0x1006 Hub in Aluminum Keyboard bcdDevice 94.15 iManufacturer 1 Apple, Inc. iProduct 2 Keyboard Hub iSerial 3 000000000000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x008d Per-port power switching Compound device Per-port overcurrent protection TT think time 8 FS bits Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 200 milli Ampere DeviceRemovable 0x04 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0303 lowspeed power enable connect Port 3: 0000.0103 power enable connect Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) as for the reasoning, quoting again Matthew Garret: > > Was my reasoning for this change off ("F-keys used more often that > > multimediakeys, ergo make that the default"), or is your resistance to > > this change due to some kind of policy? > > It's a change in behaviour of a wide range of keyboards, and it's in a > patch that is supposed to be fixing a single keyboard. Personally, I > suspect that the people who are going to want the F-keys by default are > the people who are easily able to change this behaviour and the ones who > aren't are the ones who are going to expect their keyboard to behave > like it did under MacOS. But that's a separate argument for a separate > patch :)
>Hub in Aluminum Keyboard We don't care here about this :-) > It's a change in behaviour of a wide range of keyboards, and it's in a > patch that is supposed to be fixing a single keyboard. Personally, I > suspect that the people who are going to want the F-keys by default are > the people who are easily able to change this behaviour and the ones who > aren't are the ones who are going to expect their keyboard to behave > like it did under MacOS. But that's a separate argument for a separate > patch :) Completely wrong. Show me somebody running linux kernel, expecting his keyboard to behave like under MacOS. On the contrary. All alu-keyboard users I know, are thinking the kernel dewelopers must be mad.
There is a endless count of bug reports/fixes like this one: "Belgian Keyboard As Belgian Mac's keyboard has never been correctly adapted, changes are bigger than the swapping keycodes as the canadian multitouch, we have to redefine @, #,€,`,[,],{,}. On Mac OS, to have {}, we use the CMD button with '(' and ')' , and for [ ], we use CMD + SHIFT + '(' and ')'. On linux, I've mapped it identically, but with ALT (left). So to write '{' we use ALT +'(' and for '[' we use ALT+SHIFT+'('." Maybe the kernel should load keyboard quirks via firmware mechanism or give the user space more sophisticated interface. Logically, I think, this all must be fixed inside the kernel (not in X11, not in console, not in frame buffer, ...) the question is _how_? Prove me wrong. Could somebody post lsusb -vvv from the us keyboard?
(In reply to comment #9) > > Changing this might be a bit of an abrupt change, but making it optional > now, > > making it default off in a further release, and then removing the option > even > > further on, giving time to userspace to deal with the issue, could be a > nice > > way to resolve the issue... I actually was thinking about that after I > fixed > > the numlock issue, but then I thought it would probably have been just me. Do it! :-) Found a hardware fix for all the us layout users: http://skeltoac.com/2007/10/22/apple-keyboard-aluminum-keycap-removal/
I sincerely think that it's userland's task to actually change the behaviour of the keys, rather than the kernel's. For once, if the quirk would be handled by X11, any system that supported X11 could have the quirk available at once. That said, I'm not much of an HID hacker so I'd rather hear something from Jiri at this point...
... but don't frighten thinking further ;) What about to kill all that Funny Keys as default and let the userspace tell the kernel to attach a FSM + key or string table to any key they want. And you must be not on X11 crack to get your keyboard working. What about the ps2, infrared, bluetooth, ... everybody is playing a quirk games in his sandbox. Yes, I have the bluetooth alu twin sister here. Trust me, it's just the same nightmare.
Jirko, co ty na to?
Another report of this: https://bugs.gentoo.org/show_bug.cgi?id=244824
I have the same problem and I also think that this is a device detection issue, hence a kernel thing. I had to do some hunting that I was able to map the keys almost the way I wanted *but* the Print Screen key. Kernel: 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux I have the same problem and I also think that this is a device detection issue, hence a kernel thing. I had to do some hunting that I was able to map the keys almost the way I wanted but the Print Screen key. Kernel: 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux I have mapped F14 to Print screen and after trying xev this is what I get when I press the F14: KeyRelease event, serial 34, synthetic NO, window 0x3400001, root 0x13b, subw 0x0, time 1661372, (-1801,207), root348,1599), state 0x12, keycode 192 (keysym 0xff61, Print), same_screen YES, XKeysymToKeycode returns keycode: 107 XLookupString gives 0 bytes: XFilterEvent returns: False On the other hand this is what happens if I press the Print Screen on another keyboard (that works as it should): MappingNotify event, serial 34, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 34, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 247 FocusOut event, serial 34, synthetic NO, window 0x3400001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 36, synthetic NO, window 0x3400001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 36, synthetic NO, window 0x3400001, mode NotifyNormal, detail NotifyNonlinear PropertyNotify event, serial 36, synthetic NO, window 0x3400001, atom 0x159 (_NET_WM_ICON_GEOMETRY), time 1670887, state PropertyNewValue FocusIn event, serial 36, synthetic NO, window 0x3400001, mode NotifyNormal, detail NotifyAncestor KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PropertyNotify event, serial 36, synthetic NO, window 0x3400001, atom 0x159 (_NET_WM_ICON_GEOMETRY), time 1675627, state PropertyNewValue FocusOut event, serial 36, synthetic NO, window 0x3400001, mode NotifyNormal, detail NotifyNonlinear **lsusb -vvv** Bus 001 Device 009: ID 05ac:0220 Apple, Inc. Aluminum Keyboard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x05ac Apple, Inc. idProduct 0x0220 Aluminum Keyboard bcdDevice 0.69 iManufacturer 1 Apple, Inc iProduct 2 Apple Keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 20mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 33 US bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 75 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 47 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) Bus 001 Device 007: ID 05ac:1006 Apple, Inc. Hub in Aluminum Keyboard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x05ac Apple, Inc. idProduct 0x1006 Hub in Aluminum Keyboard bcdDevice 96.15 iManufacturer 1 Apple, Inc. iProduct 2 Keyboard Hub iSerial 3 000000000000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x008d Per-port power switching Compound device Per-port overcurrent protection TT think time 8 FS bits Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 200 milli Ampere DeviceRemovable 0x04 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0303 lowspeed power enable connect Port 3: 0000.0100 power Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered)
Don't know if this is the right place to bring this up, but if it isn't perhaps someone can point me to a better spot ... as of 2.6.28 the function keys on my Annoying Aluminum Keyboard stopped working (makes shifting consoles a challenge). No problems through 2.6.27.9, then dead. XEV for F1 on 2.27.9 is a normal: KeyPress event, serial 29, synthetic NO, window 0x1000001, root 0x5d, subw 0x0, time 6638389, (909,-188), root:(1035,36), state 0x10, keycode 67 (keysym 0xffbe, F1), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False ... but on 2.6.28[1-4] I get: KeyPress event, serial 32, synthetic NO, window 0x600001, root 0x5d, subw 0x0, time 44288, (-276,81), root:(840,525), state 0x1c, keycode 101 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False Failure also happens in the root console (no X). An older Mac keyboard works fine, also a typical 104Key USB keyboard works fine -- the problem is confined to my aluminum keyboard. I tried fussing with the HID Devices and/or Special HID drivers and editing .config to see what happens if CONFIG_HID_APPLE=y is turned off, but I couldn't manage it! (Even editing .config doesn't work. Some script is outsmarting me). I'm using Ubuntu 8.4 with my own kernel; here's the ver_linux output: Linux tycho 2.6.27.9 #1 PREEMPT Wed Feb 11 13:54:04 PST 2009 i686 GNU/Linux Gnu C 4.2.4 Gnu make 3.81 binutils 2.18.0.20080103 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.3-pre11 e2fsprogs 1.40.8 reiserfsprogs 3.6.19 pcmciautils 014 PPP 2.4.4 Linux C Library 2.7 Dynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 6.10 udev 117 Glad to try out anything you can think up! Thanks, Dave
Created attachment 21357 [details] fix apple alu keyboard (>=.29) To celebrate the bugs anniversary I just post here for interested parties my patch updated for >=.29 kernels. It makes both (usb and wireless) german apple alu keyboards usable again. Tested up to 30-rc5, enjoy mc.
it seems a fix (54a6593d65e638ad7e1e8cc986159d76054dab4b) was committed to master to fix this bug, enabling people to enable/disable the ISO_LAYOUT using a module parameter. But it seems that this fix doesn't really work. On my powerbook G4 5,6 (alubook), changing the parameter doesn't change anything: keyboard works fine on console, not in X if I don't set the apple:badmap option (which needs to revert a patch in xkeyboard-config).
(In reply to comment #21) > it seems a fix (54a6593d65e638ad7e1e8cc986159d76054dab4b) was committed to > master to fix this bug, enabling people to enable/disable the ISO_LAYOUT > using > a module parameter. > > But it seems that this fix doesn't really work. On my powerbook G4 5,6 > (alubook), changing the parameter doesn't change anything: keyboard works > fine > on console, not in X if I don't set the apple:badmap option (which needs to > revert a patch in xkeyboard-config). I don't see any issues on Fedora 14 or Ubuntu 10.10. echo 2 /sys/module/hid_apple/parameters/fnmode echo 0 /sys/module/hid_apple/parameters/iso_layout works as intended and makes the keyboard usable. So this issue should by actually marked as FIXED.