Bug 10818
| Summary: | [PATCH] fix apple alu keyboard | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Martin Capitanio (c4p7n2) |
| Component: | Input Devices | Assignee: | drivers_input-devices |
| Status: | CLOSED CODE_FIX | ||
| Severity: | high | CC: | alan, c4p7n, corsac, flameeyes, jikos, kernel, north, ronjd1234 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
my tux got repetitive strain injury
vanila2.6.26_fix-apple-keyboard.patch german layout fix apple alu keyboard (>=.29) |
||
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. |
* 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 },