Apple fn key behavior isn't consistent with what's expected

Bug #201711 reported by Mario Limonciello on 2008-03-13
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Mactel Support
linux (Suse)
Fix Released
linux (Ubuntu)
Nominated for Hardy by Peter Marks
Nominated for Intrepid by Tommy Vestermark
Nominated for Lucid by Jonas Jochum

Bug Description

Hi, this is a follow up to bug 162083. With my newly functional FN key on my Aluminum BT keyboard, I realized that the default behavior on it doesn't make much sense with what users have come to expect on Linux systems. The default behavior is that the "special keys", like f1-f2-f10-f11-etc all act "special" without pressing fn. They then act normally when you hold FN. This is the default behavior on Mac OSX, but on Linux the FN keys are more commonly used. Eg, it's rather awkward to have to press ctrl-alt-fn-f1 to switch to a VT, or FN-F11 to set a terminal full screen.

Mario Limonciello (superm1) wrote :

attaching patch to change this behavior

Changed in linux:
status: Unknown → Fix Released
Mario Limonciello (superm1) wrote :

As commented on by mjg:

My experience is that the majority of users who run Linux on Apple
hardware are also used to MacOS, and so maintaining consistency with it
is worthwhile. That's entirely independent of the fact that altering
this in the kernel would change the default behaviour of the system for
users who are upgrading, which would be highly confusing.

Apple hardware tends to be intrinsically different to other PC hardware,
and we're limited in our abilities to make it behave identically - the
glaring lack of more than one mouse button is an obvious example of

Changed in linux:
status: New → Won't Fix
Raphael Huerzeler (r-h) wrote :

The new behaviour makes the keyboard essentially unusable for me - tons of apps have F-keys mapped in linux and having to press fn to use normal f-keys just makes thinks very arkward - not to mention that having to press fn-alt-ctrl-f1 to switch to a console is just ridiculous.

Is there any way to force the kernel to treat the keyboard like a bog-standard keyboard again?

Mario Limonciello (superm1) wrote :

Raphael, to change this behavior:

/sys/module/hid/parameters/pb_fnmode set that to 2.

You can change it at startup by adding it as a modprobe option as well.

Raphael Huerzeler (r-h) wrote :

Thanks Mario - setting the /sys parameter works, however I can't get the modprobe option to work. I already tried setting "option hid pb_fnmode=2" in both /etc/modprobe.conf as well as /etc/modprobe.d/options - neither had any effect on a reboot. Did something change in u8.04 re. module parameters?...modprobe.conf didn't even exists anymore by default.

These strings will go inside /etc/modprobe.d/FILE

Where file is one you create.

Mario Limonciello
<email address hidden>
Sent from my iPod Touch

On Mar 24, 2008, at 4:25, Raphael Huerzeler <email address hidden> wrote:

> Thanks Mario - setting the /sys parameter works, however I can't get
> the
> modprobe option to work. I already tried setting "option hid
> pb_fnmode=2" in both /etc/modprobe.conf as well as
> /etc/modprobe.d/options - neither had any effect on a reboot. Did
> something change in u8.04 re. module parameters?...modprobe.conf
> didn't
> even exists anymore by default.
> --
> Apple fn key behavior isn't consistent with what's expected
> You received this bug notification because you are a direct subscriber
> of the bug.

Raphael Huerzeler (r-h) wrote :

hmm...I created /etc/modprobe.d/hid and added the line:

options hid pb_fnmode=2

that doesn't work however, after a reboot the keyboard is still set to I missing something here?

Mario Limonciello (superm1) wrote :

options usbhid pb_fnmode=2

Is what you should be doing.

Raphael Huerzeler (r-h) wrote :

Thanks for all the help, unfortunately that still isn't working for me...

...I give up...quite honestly it's beyond me why the devs think that breaking (or at the very least making it very arkward to use) keycombos across hundreds if not thousands of existing linux application is a bright idea just so mac users can use half a dozen keys without having to press fn...and it's not even like those keys have more than a single function, whereas F-keys are assigned seperate functions in almost every single linux app out there...

Tommy Vestermark (tov) wrote :

Hi Raphael,

I *really* agree with you. I bought this nice shiny Apple keyboard for my Ubuntu desktop and it just worked perfectly. Then someone got this brilliant idea of adding all sorts of "quirks" in the kernel to emulate some MacOS X behavior and now suddenly overnight the keyboard became almost useless.
- The F-keys stopped working to a usable level expected by a normal Linux user (This bug)
- The NumLock key would "lock up" the entire keyboard (Bug #201887)
- Two keys were incorrectly swapped for no apparent reason (Bug #214786)

And the worst part is that is seems like Hardy may ship with these errors in place :-(

Nicolas Wu (nicolas.wu) wrote :

Making the function keys only accessible after pressing the fn key is terribly unintuitive. There are a few points that seem to be in favour of making the behaviour of this keyboard like all other keyboards with respect to function keys.

* Although this is standard behaviour for macs, I see no analogous behaviour in any other Unix system.
* Ubuntu (and Linux) users are not using macs with these keyboards, and typically expect behaviour on their keyboards to be similar between keyboards (minus obvious key position changes).
* Regular keyboard behaviour is such that the unmodified version of the key is displayed on the key itself below the special symbol: eg "1" is below "!", ";" is below ":".
* The apple aluminium keyboard has the F*-symbols below the special behaviour symbols so it really makes sense for F* to be the default behaviour.
* Function keys are more often used that the apple functions on a Unix machine (other than the standard Help, Search, they are also used to change between ttys with ctrl-alt-F*); they ought to be more readily accessible.

Is there really any good justification for enabling unusual and unexpected behaviour for this keyboard by default? Is this not completely against the philosophy of making things easy for the end-user?

Who do we need to convince to accept a patch that would rectify this?

Luke Maurer (luke-maurer) wrote :

I'd also like to add that MacOS X allows a choice of behaviors; out of the box, they're special keys by default (after all, they were designed for Mac use, and there's an Exposé key and a Dashboard key to prove it), but that can be turned off, and the MacBook fanatics I know have set them to being F-keys by default. So it's not universal that Mac guys will expect the keys to have the special meaning (especially as the Exposé and Dashboard keys don't mean much to a vanilla Ubuntu install).

Also, it's not the case that only Mac guys will use these keyboards. I'm not a Mac guy, and I'm typing on one right now :-) (It is quite pertinent to the discussion to note the unmistakable fact that these keyboards are frickin' *sweet*.)

Nicolas Wu (nicolas.wu) wrote :

Comments from users indicate that a "Won't Fix" really isn't appropriate in this case -- Suse has decided to fix this bug, so should Ubuntu.

Changed in linux:
status: Won't Fix → New
Tommy Vestermark (tov) wrote :


I am not a Mac guy either, and in fact these fantastic Apple keyboards are becoming so popular amongst regular PC users that normal computer shops are beginning to sell them. For these users Hardy will be an unpleasant experience. It is interesting that the original argumentation was that consistency with an entirely different operating system is more desirable than consistency within the *same* operating system. My own experience is that Mac users can perfectly well adapt to another operating system when they dual boot to e.g. Windows...

Is there any way to help in the solution of this problem? How is it possible to get more involved in the development process than just ranting on these bug pages? :-)

AFAIK, this bug is about the numlock problem.

For the definition of the "correct" fn key behavior, the correct bug seems to be ,

For the swapped <> and @#, see

Sorry for the spam. Wrong bug :-(

Andrew Flegg (aflegg) wrote :

Frédéric is creating links between the multiple issues. There's also some strong arguments in for why the current default behaviour is wrong.

I wrote there, in support of the same arguments eloquently made by Tommy, Luke, Nicolas and Raphael:

Ubuntu isn't OS X, and Apple sell these keyboards as any other keyboard manufacturer. They are Apple keyboards, not Mac keyboards; therefore trying to enforce they work like Macs - when they might well not be being used on Mac hardware, and definitely not OS X - is at least partially incorrect.

It'd be different if the keys were *obviously* volume/brightness/dashboard/exposé and not F1, F2, F3 etc. However the hotkeys and the fn keys are given equal prominence.

The third argument is that not all of the keys have special purposes, so they should do the base action - function keys without a modifier, first and foremost.

Wether this a bug or not, this problem and how to fix it is documented in , and with different solutions. I think it's time to write a new entry in the wiki (Apple Keyboards)

Peter Marks (peter-indigomail) wrote :

Frankly, I am stunned that this ridiculous behaviour has made it into the Hardy release. The suggestion that this is the behaviour that most users would want or expect is quite preposterous.

If I plug a standard keyboard into a machine running OS X it behaves the same as if I plug in an Apple keyboard. the same should be true on linux. In OS X, the function keys are not used all that frequently, in linux they are.

If you take the argument to it's conclusion, surely you should map command-c to copy and command-v to paste. Surely this half based hack satisfies no one.

Why does this need to be done in the kernel anyway? Could it not have been accomplished in console tools and X? That way users could choose if they wanted to customize their linux setup to be more like OS X.

I still not found any way to get my keyboard to behave as it did under Gusty: function keys as function keys, num lock as num lock and the backquote and backslash back where I expect them (UK layout).

Tommy Vestermark (tov) wrote :

Hi Peter, I agree wholeheartedly with your observations. It is completely crazy to the point where there is actually introduced remedies to the kernel-madness in the Keyboard Preference program (hint: see System->Preferences->Keyboard->Layout->Layout Options->Miscellaneous compatibility options->Swap keycodes of two keys when mac keyboards are misdetected by kernel) !!!

To remove the function key and num lock madness you can add the following line to /etc/modprobe.d/options:
options hid pb_fnmode=0

Tommy Vestermark (tov) wrote :

Made a small guide for correcting the issues here:
Hope it will be helpful for someone.

Jeff Fortin Tam (kiddo) wrote :

Tommy, I tried your trick to edit /etc/sysfs.conf (which does not exist initially, by the way), but it does not work. The fn key problem is not solved at all, I still have to use fn to use F* keys.

  • unnamed Edit (1.0 KiB, text/html; charset=ISO-8859-1)


The file that Tommy was likely referring to was /etc/sysctl.conf

On Mon, May 12, 2008 at 7:53 PM, Jean-François Fortin Tam <
<email address hidden>> wrote:

> Tommy, I tried your trick to edit /etc/sysfs.conf (which does not exist
> initially, by the way), but it does not work. The fn key problem is not
> solved at all, I still have to use fn to use F* keys.
> --
> Apple fn key behavior isn't consistent with what's expected
> You received this bug notification because you are a direct subscriber
> of the bug.

Mario Limonciello
<email address hidden>

Jeff Fortin Tam (kiddo) wrote :

tried with sysctl.conf, no luck either

igor (igor-babic) wrote :

Ubuntu 8.04,
to change pb_fnmode to 2 you need to add following command to /etc/rc.local file

    echo -n 0x02 > /sys/module/hid/parameters/pb_fnmode

and then behaviour of function keys will be the same as in 7.04 version.

Gabriel Forster (gforster) wrote :

Seriously, when working with a highly customizable system such as linux, shouldn't we be able to tell any key on any keyboard to do anything we want? If i want my spacebar to act as my F3 key, I should be able to do that (not that I want to).

Anyway, thank you all for your help in this, hopefully this can be "officially" fixed soon.

Wagner Volanin (volanin) wrote :

> I already tried setting "option hid pb_fnmode=2" in both /etc/modprobe.conf
> as well as /etc/modprobe.d/options - neither had any effect on a reboot.

Raphael, you're doing it correctly.
You must add "option hid pb_fnmode=2" in /etc/modprobe.d/options.
AND you must regenerate your initrd image with the command "update-initramfs -u"

> Seriously, when working with a highly customizable system such as linux,
> shouldn't we be able to tell any key on any keyboard to do anything we want?
> If i want my spacebar to act as my F3 key, I should be able to do that (not that I want to).

Linux is not meant to be a highly customizable system, it is meant to be a great OS!
But it is indeed customizable if you consider that you have the source code in your hands.
If you hate one particular thing, like the lack of a spacebar mapping to your F3 key,
you can always rewrite the keymaps (like I indeed do to change the place of my
interrogation sign key), and you can even reprogram some functions in the
programs that you use the most.

But, that's not the main topic of this BUG entry, so let's continue it in the ubuntuforums.
We can discuss a lot there!

Tommy Vestermark (tov) wrote :

> You must add "option hid pb_fnmode=2" in /etc/modprobe.d/options.
> AND you must regenerate your initrd image with the command "update-initramfs -u"

Yes, I forgot the "update-initramfs -u" part in and someone changed the
page to another non-working suggestion. It should be corrected now.
Sorry for the confusion.

Beware though that you need to use pb_fnmode=0 instead of pb_fnmode=2
to also correct the Numlock bug.

Nicolas Wu (nicolas.wu) wrote :

Thanks Tommy, that works really well. I had changed my /etc/modprobe.conf to the same effect.

The trouble with pb_fnmode=0 is that the fn key doesn't modify the F* keys at all now -- they remain F* keys.

This is nevertheless a great improvement. Why isn't this a default setting?

Martin Capitanio (capnm) wrote :

Just createt a "swallow-the-alu-pill" tux mascot to see if that helps ;-)

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.


2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Henrik Rydberg (rydberg) wrote :

Tested the Intrepid daily live CD just now (31AUG2008), on a Macbook Air. I cannot determine from the thread whether the default beviour will be changed to "linux standard", from the current "mac standard", but these are my two cents on the matter. My first problem was to debug a non-functional mouse pointer, and having to press FN+ALT+F2 to bring up the command launcher was utterly unintuitive. My first assumption, while pressing ALT+F2, was that my keyboard was frozen as well...

zenzike (zenzike) wrote :

I have just installed ibex, and can confirm that this bug still exists on the 2.6.27-7-generic kernel.

Benoit Grégoire (benoitg) wrote :

Indeed, bug still exists on Intrepid

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 for more information. Thanks.

Craig Maloney (craig-decafbad) wrote :

I can confirm on my desktop machine that the fn key works as expected, though I don't believe this is default behaviour.

Simone Malacarne (s-malacarne) wrote :

i agree. Default behaviour is terrible. Using function key is terrible and difficult.

Just to make alt-f4 you need both hand.

When you press fn change must be permanent (until you press it again). This is the right way.

Brad Figg (brad-figg) on 2009-04-20
tags: added: ct-rev
Jyaan (box100-prodigy) wrote :

I think everyone is forgetting that on Mac OS X you can go into System Preferences and change this behavior at any time. I believe it would be best if Keyboard Preferences had a similar option -- perhaps under "Miscellaneous compatibility options".

I also believe that using fn to toggle the status of the keys ('lock' rather than modifier) is another choice that should be available. However, this should also be listed in Keyboard Preferences.

Regardless, Ubuntu uses the Fx keys quite a bit and that isn't going to change. I found the current default behavior to be very cumbersome and changed the setting on my computer right away. We also need to get the exposé and widget keys added in, whether they do anything by default or not.

Andrew Carter (ascarter) wrote :

My Logitech Illuminated keyboard has the same sort of Fn key behavior. I'd agree that a Misc compatibility option for these keyboards would be best.

Bryan Wu (cooloney) wrote :

Unfortunately it seems this bug is still an issue. Can you confirm this issue exists with the most recent Jaunty Jackalope 9.04 release - . Please let us know your results.

If the issue remains while still running Jaunty, please run the following command which will automatically gather and attach updated debug information:

apport-collect -p linux-image-2.6.28-11-generic <bug #>

Thanks in advance.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Simone Malacarne (s-malacarne) wrote :

I can confirm bug still exist in Jaunty (AMD64).

z600 (sanjivarunsahayam) wrote :

I can also confirm the bug still exists in Jaunty:
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Linux 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

Architecture: amd64
 [ 19.203847] r8169: eth0: link up
 [ 19.203853] r8169: eth0: link up
 [ 29.332009] eth0: no IPv6 routers present
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=b173fda2-b177-4e0f-82b2-f736877a4999
MachineType: Gigabyte Technology Co., Ltd. GA-MA770T-UD3P
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-13-generic 2.6.28-13.45
PackageArchitecture: amd64
ProcCmdLine: root=UUID=47866083-cce7-4316-9130-d73e15a26fe3 ro quiet splash
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.28-13.45-generic
Uname: Linux 2.6.28-13-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Samuel Huckins (wormwood-3) wrote :

The following fix works for me running:

OS: Linux, Ubuntu 9.04 \n \l
Kernel: 2.6.28-13-generic

 * Edit /etc/rc.local
 * Add before "exit 0":
echo 2 > /sys/module/hid_apple/parameters/fnmode
 * Reboot

After that, the function keys worked fine for me without pressing Fn.

For more history and related issues, see my post here:

Tom Wright (twright-tdw) wrote :

This bug report is not incomplete, all the information + strong user support is here. Does anyone actually want the broken behavior on their own behalf, not just on that of 'the people'. This is a clear cut issue and requires only small changes to get it usable again.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Gionn (giovanni.toraldo) wrote :

There is any plan for make the choice of the Fn keys behaviour more friendly? Like an option on the keyboard preferences panel?

On karmic I should put a new command in rc.local as #44.

I have to agree, an option in the keyboard settings for fnmode would be helpful, like:
"Use F1, F2 as function keys"

I think having the special keys as default (as on OS X) is fine.

@Ralf Ebert: I also agree with an option for the Fn keys but I disagree to have the default as in OS-X. I think initiating the Applications menu by pressing fn + alt + F1 is quite a finger excercise :-)


Jonas Jochum (jonas-jochum) wrote :

There should be a way to vote bugs up.
The default behaviour is seriously annoying. Lots and lots of keyboard shortcuts use FN keys, and having to press the fn button on Apple keyboards to access those shortcuts REALLY IS a finger excercise. Please, pleeeease change this behaviour for 10.04. I don't think any user familiar with Mac OS X expects Apple-like behaviour of the function keys on Linux. And those expecting that behaviour most likely won't use Linux on their computers.

Brian K. White (brian-aljex) wrote :


The logic behind making the new default is based on assumptions which are surely wrong.

The logic behind making this default, whether it's terrible or sensible, take place in the kernel instead of in X or the desktop environment is inexplicable.

The logic behind requiring the user to manually edit a system startup shell script, _correctly_, _to a moving target_ (name of hid module in sysfs changes in different kernel versions) and all that that implies, instead of in some gnome menu is also inexplicable.

I'm using an Apple keyboard on a generic pc running Ubuntu simply because it's a great, and great looking keyboard. The fact that Apple makes this keyboard in no way implies that I want my Linux system to emulate OS/X.

Add another vote to the pile that says, regardless of hardware combination (Apple keyboard on generic pc, Apple keyboard as part of Apple laptop or pc) it is most reasonable to expect, and most reasonable to supply, Linux behavior on Linux!

John Pye (jdpipe) wrote :

Is there any possibility that this 'normal' F1-F15 behaviour could be switchable using the GNOME System->Preferences->Keyboard->Layouts->Options dialog? That would be the best solution that allows people to reconfigure according to their wishes?

Dawning (dawning) wrote :

I've run Ubuntu on my Apple machines for several years now and I've found the current approach (requiring the pressing of the fn key) to be very intuitive. I do have a friend however who bought an Apple keyboard for his Whitebox PC and he never thought to even try holding 'fn'. But you can't win 'em all.

Perhaps there's enough quirks to Apple hardware to justify a little GUI config app for selecting enablers for various little things such as disabling the default functionality in this case.

I like it as it is, that's my vote anyway.

Martin Capitanio (capnm) wrote :

The best way to fix this (worked well for me for several years)
is to append the needed module parameters to the kernel command line.

sudo vi /etc/default/grub
and change
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash hid_apple.fnmode=2"

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash hid_apple.fnmode=2 hid_apple.iso_layout=0"


modinfo hid_apple
parm: fnmode:Mode of fn key on Apple keyboards (0 = disabled, [1] = fkeyslast, 2 = fkeysfirst) (uint)
parm: iso_layout:Enable/Disable hardcoded ISO-layout of the keyboard. (0 = disabled, [1] = enabled) (uint)

Changed in linux (Suse):
importance: Unknown → Low
Adam Dingle (adam-yorba) wrote :

In Ubuntu 13.04 (Raring) I still have to press Fn to get to the function keys. The fix Samuel mentioned in comment #44 above still works fine.

I have to set up this manually time I install a new version of Ubuntu, which is annoying. I'd love for no-Fn to be the default - could Ubuntu consider this? If not I think John's suggestion in comment #51 (making it switchable in Keyboard->Layouts->Options) would be pretty reasonable.

Mario Limonciello, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:

where VERSION-NUMBER is the version number of the kernel you tested. For example:

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:

If the mainline kernel does not fix this bug, please add the following tags:

As well, please remove the tag:

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Juan Solsona (juansolsona) wrote :

Confirmed that external AppleKeyboard by default does not handle function keys with distro:
Linux juansolsona-XPS-15-9550 4.8.0-41-generic #44~16.04.1-Ubuntu SMP Fri Mar 3 17:11:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

My way to fix it was
add to the file /etc/rc.local
the line " echo 2 > /sys/module/hid_apple/parameters/fnmode"

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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