macbook3,1 and apple aluminum keyboards fn key does not work

Bug #162083 reported by Chris Irwin
54
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Mactel Support
Fix Released
Medium
Chris Irwin
linux (Ubuntu)
Fix Released
Medium
Tim Gardner
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: linux-image-2.6-amd64-generic

fn key is required on apple keyboards to do common functions (delete, pageup/down, home/end, volume, etc). The apple aluminum keyboard and new macbook3,1 ("Santa Rosa") are both affected.

Attached is a patch from the mactel-linux-devel list by Martin Szulecki <email address hidden> that adds the aluminum keyboard. I have modified the patch to include the macbok3,1 keyboard as well as additional keycodes that were present on "powerbook" keyboards (delete, pgup/down, home/end).

This patch has been tested on a macbook 3,1 by myself on an amd64 kernel.

Tags: macbook3.1
Revision history for this message
Chris Irwin (chrisirwin) wrote :
Revision history for this message
cleentrax (cleentrax) wrote :

I can confirm that this patch works, at least for the fn key.

Revision history for this message
sidgalt (sidgalt) wrote :

I tried installing this patch on both i386 and amd64. This patch works for me on both for the fn key but the brightness controls aren't working (with or without the patch/with or without pommed v1.11).

Revision history for this message
sidgalt (sidgalt) wrote :

udpate: the patch seems to have changed the functionality of my ` key. Whenever I press the ` key, I get the character <. Whenever I press <shift> to along with ` to get ~, I get >.
Also the F5 and F6 keys are producing ~ character in the terminal.

Revision history for this message
Chris Irwin (chrisirwin) wrote :

sidgalt, what kind of keyboard do you have? can you please attach the output of `lsusb` to this ticket?

The brightness keys send the correct key codes, but being detected by HAL requires the patch in bug #163725. Having HAL do something when these keys are detected depends on bug #162560.

Attached is an updated patch that adds IDs for several keyboards. Included are the ANSI, ISO, and JIS variants of the macbook3,1 keyboard, and both the wired and wireless Apple Aluminum keyboards ("2007" variant according to apple's kext). It also adds a fix needed for ISO keyboards as two keycodes were reversed. The code for handling this already existed for powerbook iso keyboards.

Revision history for this message
Mario Limonciello (superm1) wrote :
Revision history for this message
Chris Irwin (chrisirwin) wrote :

Note that the git packages referenced are lacking the wireless aluminum + macbook3,1 IDs

Revision history for this message
Mario Limonciello (superm1) wrote :

Chris,

Additionally, the patches posted here don't seem to work with my wireless variant. Note that they are patching the hid-quirk's in the usb* devices only. Shouldn't they be applied elsewhere for the wireless version?

Revision history for this message
Chris Irwin (chrisirwin) wrote :

Mario

I had thought that the wireless devices would still go through the usbhid as there seems to be no other applicable quirks file. I did not have an apple bluetooth keyboard to test, and it never occurred to me that it may not.

Do you know what driver handles your keyboard then?

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 162083] Re: macbook3, 1 and apple aluminum keyboards fn key does not work

Chris Irwin wrote:
> Mario
>
> I had thought that the wireless devices would still go through the
> usbhid as there seems to be no other applicable quirks file. I did not
> have an apple bluetooth keyboard to test, and it never occurred to me
> that it may not.
>
> Do you know what driver handles your keyboard then?
>
Chris,

I want to say it's just directly handled by the normal input driver interface
for the kernel.

The only relevant things that I'll see crop up are these in dmesg:

[ 44.100775] input: Apple Computer, Inc. Mighty Mouse as /class/input/input12
[ 45.108663] input: Apple Inc. Keyboard as /class/input/input14

Obviously neither of those ends up loading usbhid, usbkbd, or usbmouse.

Lots of bluetooth modules begin to load too, but its hard to determine if they
were intended for usage by the devices or because of the usb bluetooth receiver.

Also, I do have an additional hald process running for this device, and a
bluetooth input service running

107 29123 0.0 0.0 2164 900 ? S 06:44 0:00
hald-addon-keyboard: listening on /dev/input/event7
root 6021 0.0 0.0 2772 1080 ? S Dec11 0:00
/usr/lib/bluetooth/bluetoothd-service-input

So with all that being said, i'm pretty confused myself as to who is actually
responsible for the fact that the keyboard works as much as it does :)

--
Mario Limonciello
<email address hidden>

Revision history for this message
Chris Irwin (chrisirwin) wrote :

Set to Confirmed and assigned to Ubuntu Kernel Team.

Some (but not all) devices discussed in this bug appear to be fixed upstream, but are not yet in Hardy's 2.6.24 kernel

Changed in linux-meta:
assignee: nobody → ubuntu-kernel-team
status: New → Confirmed
Revision history for this message
keans (keans) wrote :

After doing some research on this topic I found the following patch http://www.unionofopposites.com/tech/applebtkb.shtml, which at first does not work for me; however, after doing some further research I realised that "hidd" is showing 05ac:022d for my keyboard (perhaps a new version of the keyboard?) so I adjusted the address in the patch and now everthing is working fine ;-)

keans

Revision history for this message
Mario Limonciello (superm1) wrote :

Well the more interesting part is that it is showing the same revision as the poster for my keyboard.

00:1B:63:FC:42:88 Apple Wireless Keyboard [05ac:022c] connected.

Where did you come across that post? According to:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;h=4bbacddeb49d4d4425177cf972b921bd195ec92f;hb=decbedde11cdda33533828757df87494b7ab1961;f=net/bluetooth/hidp/core.c
It appears that this hasn't been added to 2.6.24 even yet.

I'll do a test build of the module for 2.6.22 (which i'm still on)

Revision history for this message
Mario Limonciello (superm1) wrote :

Indeed that patch works perfectly for me on my aluminum wireless keyboard. (05ac:022c)

Revision history for this message
Mario Limonciello (superm1) wrote :

Well scratch the *perfectly*, it works well enough to re-enable the fn key, but all the mappings for the fX (f1 f2 f3 etc) keys are thrown off. Additionally the fn lock is on at all times, and turned off when i hold it down.

Revision history for this message
Chris Irwin (chrisirwin) wrote :

Mario,

You should still be able to set /sys/module/hid/parameters/pb_fnmode to 2 and switch the fn key.

You would still need the patch included for the other keyboards to get the proper function mappings. however, There may be some other changes required to get those IDs to use the new mappings.

Revision history for this message
keans (keans) wrote :

I am glad it is working. I found this patch just by coincidence by googling for the apple aluminum keyboard...

If you see the first posts, this patch seems to be published a while ago in this newsgroup gmane.linux.bluez.devel
http://search.gmane.org/?author=Dean+McCarron&sort=date
However, I have neither a clue how long it will take to go into the kernel nor if it ever will. Nonethesless, the question still is how many revision there are for this keyboard... Furthermore, for the fn-problem you could give pommed a try, which originally should help with the apple laptops hotkeys handling (I have not try it myselft until now)

Revision history for this message
Filippo Giunchedi (filippo) wrote :

Hi,
is there any change this patch will eventually end in the HID tree? looks quite harmless to add a few ID and quirks

thanks

Chris Irwin (chrisirwin)
Changed in linux:
status: New → Confirmed
Revision history for this message
Robert Nasiadek (robzon) wrote :

C'mon, let's add this to Hardy. It's a small and harmless patch that will save a lot of trouble for many people.

Revision history for this message
Chris Irwin (chrisirwin) wrote :

This is the current patch that applies to 2.6.24-8.31

Chris Irwin (chrisirwin)
Changed in mactel-support:
assignee: nobody → chrisirwin
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Robert Nasiadek (robzon) wrote :

Oh come on, don't tell me we'll have to patch hardy kernel just to get the keyboard working as expected. This really IS a small patch.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Guys,

I looks like there are some patches in the upstream mainline kernel that may help resolve this bug. They appear to have gone in upstream after the 2.6.24 release which explains why they didn't make it into the Hardy kernel by default. I'm adding the upstream git commit id's for the kernel team to reference. Thanks.

commit a45d82d19a6c2a717bcc33cff243199b77fa0082
Author: Michel Daenzer <email address hidden>
Date: Wed Oct 24 16:30:37 2007 +0200

    HID: Add support for Apple aluminum USB keyboards.

    Reuse the existing quirks for Apple laptop USB keyboards.

    Signed-off-by: Michel Daenzer <email address hidden>
    Signed-off-by: Jiri Kosina <email address hidden>

commit 5906a0448208024d140e1ee0e65f9168a405fb94
Author: Tobias Mueller <email address hidden>
Date: Wed Feb 13 17:08:04 2008 +0100

    HID: add USB IDs for MacBook 3rd generation

    Add support for Macbook 3rd generation special mappings.

    Signed-off-by: Tobias Mueller <email address hidden>
    Signed-off-by: Jiri Kosina <email address hidden>

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Confirmed → Triaged
Stefan Bader (smb)
Changed in linux:
assignee: ubuntu-kernel-team → stefan-bader-canonical
status: Triaged → In Progress
Stefan Bader (smb)
Changed in linux:
status: In Progress → Fix Committed
Revision history for this message
Robert Nasiadek (robzon) wrote :

Yay! Fix committed. Thanks a lot for taking this in!

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Just adding a note that against 2.6.22 this fix will not be backported as it does not qualify for a stable release update. I'm closing the 2.6.22 task as a result. Thanks.

Changed in linux-source-2.6.22:
status: Confirmed → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.6 KiB)

This bug was fixed in the package linux - 2.6.24-12.18

---------------
linux (2.6.24-12.18) hardy; urgency=low

  [Amit Kucheria]

  * Move Marvell 8686 and 8688 to LUM
  * Poulsbo: Sync patches with moblin/ume-hardy tree
  * Break if a patch fails to apply
  * SAUCE: implement smarter atime updates support
    - LP: #199427
  * Enable USB_PERSIST to allow devices with /root on usb to work with
    suspend
  * Enable USB_PERSIST across the board

  [Ben Collins]

  * build/config: Really fix ide on smp ppc configs
  * build/configs: Enable relatime config option for all flavors
  * build/abi: Ignore ide-core module for ppc, moved to built-in

  [Colin Ian King]

  * fix reversed logic for bbuild check leads to -j1 default
    - LP: #197040
  * Enable IDE_PMAC for powerpc-smp
    - LP: #196686
  * Disable CONFIG_USB_OHCI_HCD_SSB
    - LP: #182716
  * SAUCE: fix arcmsr + archttp64 calls dma_free_coherent() with irqs
    disabled - dmesg filled with warnings
    - LP: #194207

  [Jorge Boncompte [DTI2]]

  * Fix Messed multicast lists after dev_mc_sync/unsync
    - LP: #193468

  [Stefan Bader]

  * Add support for Apple Aluminium keyboards.
    - LP: #162083
  * SAUCE: Restore VT fonts on switch

  [Upstream Kernel Changes]

  * [NET]: Messed multicast lists after dev_mc_sync/unsync
  * KVM: x86 emulator: add support for group decoding
  * KVM: x86 emulator: group decoding for group 1A
  * KVM: x86 emulator: Group decoding for group 3
  * KVM: x86 emulator: Group decoding for groups 4 and 5
  * KVM: x86 emulator: add group 7 decoding
  * KVM: constify function pointer tables
  * KVM: Only x86 has pio
  * KVM: x86 emulator: group decoding for group 1 instructions
  * KVM: MMU: Decouple mmio from shadow page tables
  * KVM: Limit vcpu mmap size to one page on non-x86
  * KVM: VMX: Enable Virtual Processor Identification (VPID)
  * KVM: Use CONFIG_PREEMPT_NOTIFIERS around struct preempt_notifier
  * KVM: Disable pagefaults during copy_from_user_inatomic()
  * KVM: make EFER_RESERVED_BITS configurable for architecture code
  * KVM: align valid EFER bits with the features of the host system
  * KVM: allow access to EFER in 32bit KVM
  * kvm: i386 fix
  * KVM: export information about NPT to generic x86 code
  * KVM: MMU: make the __nonpaging_map function generic
  * KVM: export the load_pdptrs() function to modules
  * KVM: MMU: add TDP support to the KVM MMU
  * KVM: x86 emulator: Fix 'jmp abs'
  * KVM: x86 emulator: fix group 5 decoding
  * KVM: Fix kvm_arch_vcpu_ioctl_set_sregs so that set_cr0 works properly
  * KVM: Make the supported cpuid list a host property rather than a vm
    property
  * KVM: emulate access to MSR_IA32_MCG_CTL
  * KVM: remove the usage of the mmap_sem for the protection of the memory
    slots.
  * KVM: SVM: allocate the MSR permission map per VCPU
  * KVM: make MMU_DEBUG compile again
  * KVM: paravirtualized clocksource: host part
  * KVM: Add missing semicolon
  * KVM: x86 emulator: add ad_mask static inline
  * KVM: x86 emulator: make register_address, address_mask static inlines
  * KVM: x86 emulator: make register_address_increment and JMP_REL static
    inlines
  * KVM: Add API to retrieve the number of supported...

Read more...

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
Kai Krueger (kakrueger) wrote :

Kernel 2.6.24-12.18 works nicely for me on a MacBook 4.1. I do see the same "problem" as Mario though that one needs to press fn to get at the fx keys rather than the special symbols. (So for example to press alt-f4 one now needs to press 3 keys simultaneous) As described by Chris, I can fix it by setting /sys/module/hid/parameters/pb_fnmode to 2. However at least to me, this logic seems inverted and so I was wondering if the default could be changed?

Revision history for this message
Mario Limonciello (superm1) wrote :

This fix doesn't work for my wireless aluminum keyboard unfortunately. I'm guessing it's just missing a vendor id or product id for it, but I haven't investigated closely.

Revision history for this message
Mario Limonciello (superm1) wrote :

Here is a patch to fix the issue I have with the wireless variant.

Revision history for this message
Stefan Bader (smb) wrote :

Added Mario's follow up patch to the repository.

Changed in linux:
status: Fix Released → In Progress
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.24-12.21

---------------
linux (2.6.24-12.21) hardy; urgency=low

  [Ben Collins]

  * build: Fix vesafb module inclusion into initrd subdir
    - LP: #129910
  * net/bluetooth: POWERBOOK => APPLE, fix for apple keyboard patch
  * custom/xen: Remove asix portion of xen patch, breaks driver
    - LP: #199296

  [Colin Ian King]

  * SAUCE: fix Udma not fully available in Acer 1694 Wlmi
    - LP: #187121
  * SAUCE: Update toshiba_acpi.c to version 0.19a
    - LP: #77026

  [Stefan Bader]

  * x86: Clear DF before calling signal handler
  * Enable FN key on Apple aluminum bluetooth keyboard
    - LP: #162083

 -- Ben Collins <email address hidden> Tue, 11 Mar 2008 13:20:49 -0400

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

this seems to have caused a regression that messes up the numlock/fn keys, and (in my case at least) the F1/F2/F3/F* keys too. See bug #201887.

Any thoughts?

Revision history for this message
Mario Limonciello (superm1) wrote :

Jean -
Lets keep discussion on the separate issue on the separate bug.

Changed in mactel-support:
status: Confirmed → Fix Released
Revision history for this message
Tommy Vestermark (tov) wrote :

The fix introduced for this bug seems to include several regressions for a lot of people. See Bug #201711, Bug #201887 and Bug #214786.

Generally it seems like a wrong solution to make all this peculiar keyboard mapping in kernel space and introduce kernel module parameters (pb_fnmode) for user customization. This Apple specific keyboard handling fills a significant portion of the HID module and even includes locale specific mapping! We already have keyboard layout handling several places in user space and also have the Keyboard Shortcut application to make special shortcuts for media keys. It seems more logical that the fn key should be treated as just another modifier key for general use. It might even make it possible to map it as an insert key which is missing from the keyboard and would normally be in its place.

Why is all this done in kernel space?

Revision history for this message
Petar Forai (pfo) wrote :

I experience the same kind of regression, F{1,2,3,4} keys are only working properly when pressed in conjunction with Fn, ie Fn + F1 = F1.

Revision history for this message
MrMEEE (mj-casalogic) wrote :

The problem is still there for my Aluminium Wireless keyboard...

If I in:

linux-2.6.24/net/bluetooth/hidp/core.c

changes

        { 0x05ac, 0x022c, HID_QUIRK_APPLE_HAS_FN },

to

        { 0x05ac, 0x022d, HID_QUIRK_APPLE_HAS_FN },

Then it works...

there are probably different versions of the keyboard out there... isn't possible to include both???

By the way, can anyone tell me why:

apt-get source linux-image-2.6.24-17-generic

fetches the 2.6.24-16 kernel???.... Output:

falcon ~ # apt-get source linux-image-2.6.24-17-generic
Indlæser pakkelisterne... Færdig
Opbygger afhængighedstræ
Læser tilstandsoplysninger... Færdig
Overspringer allerede hentet fil 'linux_2.6.24-16.30.dsc'
Overspringer allerede hentet fil 'linux_2.6.24.orig.tar.gz'
Overspringer allerede hentet fil 'linux_2.6.24-16.30.diff.gz'
0B skal hentes fra kildetekst-arkiverne.
Overspringer udpakning af allerede udpakket kildetekst i linux-2.6.24

Sry... it is in Danish... but you'll get the idea.. it fetches version 2.6.24-16 instead of 2.6.24-17...

Revision history for this message
Mario Limonciello (superm1) wrote :

This fix got lost going to intrepid. I'm opening this bug back up. I submitted it to the mailing list to be added back in and submitted it upstream.

Changed in linux:
status: Fix Released → Confirmed
Revision history for this message
Tim Gardner (timg-tpi) wrote :
Changed in linux:
assignee: stefan-bader-canonical → timg-tpi
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.27-7.12

---------------
linux (2.6.27-7.12) intrepid; urgency=low

  [ Chuck Short ]

  * xen: Add xen modules to virtual flavours.

  [ Mario Limonciello ]

  * SAUCE: Add back in lost commit for Apple BT Wireless Keyboard
    - LP: #162083

  [ Tim Gardner ]

  * Remove depmod created files from packages.
    - LP: #250511
  * Changed default TCP congestion algorithm to 'cubic' (again)
    - LP: #278801
  * Update configs for 'disable CONFIG_DYNAMIC_FTRACE'
    - LP: #263555

  [ Upstream Kernel Changes ]

  * x86: register a platform RTC device if PNP doesn't describe it
  * disable CONFIG_DYNAMIC_FTRACE due to possible memory corruption on
    module unload

 -- Tim Gardner <email address hidden> Fri, 17 Oct 2008 11:25:39 -0600

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
uli (kali-silat) wrote :

I included a patch for the current ubuntu kernel 2.6.24 from Hardy, so that it also activates fn key for Apple bluetooth alu keyboards, that identify as "hidd" 05ac:022d (and not only for 05ac:022c as tested by kernel 2.6.24). I tested the patch with my keyboard, that identifies with "hidd" 05ac:022d and it seems ok.

Hopefully that can be included in future versions.

Uli

Revision history for this message
pablofunes (pablo-icosystem) wrote :

UPDATE: A newly purchased (11/12/09) Apple Blueetooth Keyboard is having the same problem on kernel 2.6.30.9!

I guess they have changed the hex id (from 022d to 0239) of the keyboard, so the patch doesn't know to enable the FN key on this keyboard?

$ hidd --show
60:FB:42:00:5A:CD Apple Wireless Keyboard [05ac:0239] connected

Other than the FN key being nonexistant, this little Apple keyboard works just fine and has a better key feel than their older models.

Revision history for this message
Michael Nischt (mosaic-school) wrote :

I can confirm pablofunes comment, hope it will be fixed soon.

Revision history for this message
James (james-ph-elec) wrote :

I can confirm too - I get the following as well:
$ hidd --show
60:FB:42:08:9D:B6 Apple Wireless Keyboard [05ac:0239] connected

Took me a long time to figure this out! Boy, I wish I could use my new Fn key.

Revision history for this message
Mahmoud Abdelkader (mahmoudimus) wrote :

I can confirm this as well

% hidd --show
60:FB:42:03:95:BF Apple Wireless Keyboard [05ac:0239] connected

I tried looking in the source files in net/bluetooth/hidp/core.c to see if I can backport one of the patches from above but the file drastically changed from the previous patches.

Would appreciate someone looking into this.

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

Guys, check right bug (fn for Apple Wireless Keyboard) #499013.
It has solution. Works well for Apple Wireless Keyboard [05ac:023a] - the only difference is product id.

Revision history for this message
pablofunes (pablo-icosystem) wrote :

It's hard to believe that a new keyboard model out of a manufacturer would require recompiling the kernel? Linus ought to be ashamed: the hex id for the specific keyboard model is hard-coded in the kernel source code?

True: it's actually a keyboard-handler loadable module, but still you seem to need the whole kernel source just to recompile that module...?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.