Slim USB Apple Keyboard not working correctly when pressing the "numlock" key

Actually, after testing it more i find that the keyboard only gets screwed up when I type with keys on the Numpad. The numbers above the letters works fine.

I'm having this problem too. Except that today I can't get it to return to normal even by unplugging/rebooting. I'm still looking for why. Hopefully we can get this fixed

I'm seeing this too. Very strange. When activating the numlock, all keys other than the numpad (and "fn numpad") are deactivated, and you can't use numlock to switch back. My only option is then to "sudo /etc/init.d/gdm restart" remotely through ssh.

I now think this is most likely a kernel bug. I booted up into rescue mode and the keyboard displayed the same behavior where pressing keys on the numpad disabled the letters. Could this be due to recent apple keyboard patches in the kernel? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/162083/comments/25

are you also affected by the fact that all the "F" keys (F1, F2, etc) do not work?
this is really crippling!

Jean,

Please try turning off numlock from another keyboard. I had very similar problems until I did this.

And if you are talking about F* keys not working, that is the default behavior of these keyboards.

you "hold" fn to activate one of those keys. This behavior can be changed though.

Last comment,

be careful with the application numlockx. It causes weird stuff like this when these keyboards are used....

Mario,

Thank you! numlockx was my problem. I forgot that I had installed it months ago. Found this forum post showing how to change the default F key behavior http://ubuntuforums.org/showpost.php?p=3518372&postcount=5

However, pressing the numlock key, or on this keyboard it's labeled "clear", still causes the behavior described above. So I think there's still a bug.

A workaround I found was to enable the keypad numbers by default by going to System > Preferences > Keyboard > (Layouts Tab) > Layout Options... > Miscellaneous Compatibility Options, and checking "Default numeric keys" and "Numeric keypad keys work as with Mac."

Eric Johney,

Thank you for the temporary work around.
The workaround works well for me, for the time being.

BradwJensen wrote:
> Eric Johney,
>
> Thank you for the temporary work around.
> The workaround works well for me, for the time being.
>
Okay so in an effort to nail down the cause of this bug, lets try to get a few
things straight. Does your keyboard really have a numeric keypad?

Attached is the keyboard i've got (which doesn't have such a pad, so I wouldn't
be able to reproduce it).

So did these problems crop up for everyone right after the update to enable FN
key on the USB variety? An the real problem - is it that something weird
happens with the FN key or just with when numlock (of some variety) is pressed?

--
Mario Limonciello
<email address hidden>

BradwJensen wrote:
> Eric Johney,
>
> Thank you for the temporary work around.
> The workaround works well for me, for the time being.
>

--
Mario Limonciello
<email address hidden>

Mario,

I just turned off Eric's workaround and tried a few things once more..

When i log in, all function keys and volume up/down keys work fine, page up, page down, letters.. those all work fine.. but if i type a number on the numpad nothing happens (like it's turned off) so then i type everything else again like letters and function keys and they still work..

Once i click the "Clear" key to turn on the number pad - the number pad still doesn't work, and letters start typing numbers..

Here is what i got after pressing the "Clear" key to turn on the numpad:

I = 5
u = 4
l = 3
k = 3
j = 1
m = 0
o = 6

..And so on.

Some of the keys don't do anything from there on.. But the audio up/down keys still work.

Once i log out and log back in, all is back to the way it started again.

P.S. i have this keyboard:
http://images.apple.com/keyboard/images/wired_keyboard20070813.gif

Brad, I have the same keyboard too. Ok, here's what I saw going on while I was monitoring the events that were being created when pressing different keys. What's happening is, when numlock is pressed it's basically getting stuck in an infinite loop.

I created a kernel patch file that worked for me and seems to return the behavior back to the way it's expected. Let me know if this works for anybody else with this issue. I also have no idea what this will break on any other apple keyboards so any testing there would be helpful too.

oops, that first patch is backwards, use this instead

Eric Johney wrote:
> oops, that first patch is backwards, use this instead
>
> ** Attachment added: "apple-keyboard-numlock.patch"
> http://launchpadlibrarian.net/12736374/apple-keyboard-numlock.patch
>
Although I don't have one of these keyboards (with that fancy shmancy
numlock/keypad), you may consider attaching the compiled kernel module (.ko) for
this bug so other folks who do and don't have that exact keyboard can see if it
breaks things for them without waiting a few hours for the kernel build process
to complete locally.

I say this because I came across another bug the other day that there was a
gentleman who was talking the same thing about a bzr branch. Sure developers
don't have any troubles doing these sorts of things, but even a power user can
throw a way a few hours trying to figure out how to build something and then not
knowing if they broke it in the process.

--
Mario Limonciello
<email address hidden>

Ok, sounds good mario, I'll build the kernel module for easier testing. However, I was thinking about it some more, and I don't think this is even the right fix. The keypad number keys should just be on by default, and the "clear" key should not be even interpreted as a numlock, but an actual clear. I'll work on another patch to accomplish this tonight and post it here

Eric, I know on Windows the Clear key works as a numlock key would, but I was curious as to what the Clear key is originally supposed to be for on the mac? What does it originally do?

Just for replying to all the latest questions that affect me, and have a summary of my particular situation:

>> Please try turning off numlock from another keyboard.
That was done already (when I plugged another keyboard, numlock led was off)

>> And if you are talking about F* keys not working, that is the default behavior of these keyboards.
Uh, this is nonsense, it worked a week ago! And I bought this keyboard because it has comfortable keys, not because I want it to behave like a mac or something. I think most users under linux need the F* keys quite often, be it for F11 (fullscreen), F2 (rename), alt-F2, alt-F3 (deskbar), F1 (help), and so on.

>> be careful with the application numlockx.
I did not have numlockx installed.

>> Does your keyboard really have a numeric keypad?
Yes, my keyboard is the full-size version that comes with new iMacs and stuff like that. I am not using the wireless version.

>> So did these problems crop up for everyone right after the update to enable FN
key on the USB variety?
I don't know, I think this happened a week or so ago. Maybe after a kernel update. I find it quite funny that a keyboard needs a friggin' kernel driver, I did not know that until now :)

I did not try the workarounds or kernel patches, I want to use the "default that ubuntu offers" whenever possible.

>Uh, this is nonsense, it worked a week ago! And I bought this keyboard because it has comfortable keys, not because I want it to behave like a mac or something. I think most users under linux need the F* keys quite often, >be it for F11 (fullscreen), F2 (rename), alt-F2, alt-F3 (deskbar), F1 (help), and so on.
Yeah well this is what i was thinking too. Look at bug 201711.

Quoting the mailing list that it was turned down on:
"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
this.
"

I can confirm problems these problems as well. I have a wired USB white Apple keyboard with danish layout. Allthough to me it seems like to seperate issues:

1. When upgrading kernel from 2.6.24-11.17 to 2.6.24-12.22 all F-keys stopped working except 'F5' and 'F6'. Other characters are swapped as well (e.g. '½' and '§' has been swapped with '<' and '>'). Based on the discussion above i can now make the F-keys temporarily work again by pressing and holding the 'fn' key.

2. When pressing the "crossed rectangle" key above '7' on the numeric keypad (is it the 'clear' og 'num-lock' key??) the letters and numeric keypad no longer work correctly. Instead some of the letters behave as a virtual numeric keypad as for a laptop keyboard without a numeric keypad. A fix is to press the 'F6' key twice to get the keyboard back to normal mode. Apparently 'F6' behaves as 'num-lock' in this mode.

After spending several hours with this problem before realizing it was related to the kernel-update, I went to search the bug database. It seems to me it is likely to be caused by the "fix" introduced in bug #162083. The keyboard worked fine before, so this is very annoying.

Tommy,

This is because of the default behavior of these keyboards.

To change it to what you are expecting:

set /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.

As for the numlock problem, it's very obvious from viewing the code in
the drivers/hid/hid-input.c file what is going on. Basically, when you
hit the numlock key on an apple keyboard that has a real keypad, it
doesn't actually care that you have a real keypad and switches the
keyboard into powerbook style keypad mode. That is the letters on the
right side of the keyboard take on the keypad functionality. This is
obviously wrong for those apple keyboards that actually do have a keypad.

Here's another patch that's probably more correct than the one I posted
earlier. When the numlock key is pressed, it checks the model of the
keyboard to decide whether or not to change the key mapping. This is
still probably wrong however.

As long as the precedent for default apple behavior has been set with
the whole FN/F-Key business, keyboards that have keypads SHOULD be stuck
on numlock. Unfortunately, I'm no kernel programmer, but I'll keep
working on this.

I have also attached a kernel module file for amd64 machines. Move this
file to /lib/modules/2.6.24-12-generic/kernel/drivers/hid/hid.ko and
reboot only if you're having this numlock issue and only if you're
running amd64 ubuntu. The i386 kernel module is still compiling, but I
will post it here when its done and tested.

aaaand, the new patch, because launchpad is weird and only lets you attach one file at a time

here's the i386 kernel module also

Mario,
I tried to set /sys/module/hid/parameters/pb_fnmode to 2 by writing the following line:
sudo echo 2 >/sys/module/hid/parameters/pb_fnmode
but i get a "permission denied" error. Is there a better way to change this setting?

Furthermore if changing this setting is needed for making the Apple keyboard work, shouldn't this be the default setting? I would hate Hardy to be released with this sort of quirk.

I did some more testing with the old kernel (2.6.24-11.17) and the keyboard just worked as I would expect. The Num-lock key worked as for a normal keyboard, all the F* keys worked and the "<" key was not swapped with the "½" key. The only key not working was the "fn" key, but that is a minor loss. All the multimedia functions on the F* keys could just be set by using the "Keyboard Shortcut" applet. So in my perspective the change introduced is a serious regression. For the record lsusb reports the following ID for my keyboard: "ID 05ac:0221 Apple Computer, Inc. ".

Eric,
I just copied your hid.ko (the i386 version) to /lib/modules/2.6.24-12-generic/kernel/drivers/hid/hid.ko and rebooted. There seems to be no change or improvement. Can I somehow verify, that the correct module is loaded?

After some digging around i think i finally found the commit where the issue is introduced:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=efb3031b446d441dca5b10619503ac0bba7f9748

With regard to the "fn" key problem I would think the following line should be changed to a default value of 2 (if Mario is right)
+++ b/drivers/hid/hid-input.c
+static int hid_apple_fnmode = 1;

With regard to the swapped "½" and "<" key it is seemingly done by purpose by this, since my keyboard is an ISO keyboard:
+++ b/drivers/hid/hid-input.c
+static struct hidinput_key_translation apple_iso_keyboard[] = {
        { KEY_GRAVE, KEY_102ND },
        { KEY_102ND, KEY_GRAVE },
I don't know the reason for this, but it is wrong for my keyboard with danish layout. Does anyone know why this is done?

With regard to the Num-lock problem as far is I can see it is due to laptop and non-laptop keyboards treated equal. Erics patch above should address this.

I am no kernel hacker but would love to try to tinker with the code. Could anyone give me a pointer to how to compile a module as Eric has done above?

Also shouldn't this bug be set to affect "linux (Ubuntu)"?

That default value isn't going to be changed. I already filed a bug
about it.

You can adjust it at module load time or runtime.

We do however need that patch that differentiates these full size
keyboards from the laptop and smaller ones.

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

On Mar 24, 2008, at 16:52, Tommy Vestermark
<email address hidden> wrote:

> After some digging around i think i finally found the commit where
> the issue is introduced:
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=efb3031b446d441dca5b10619503ac0bba7f9748
>
> With regard to the "fn" key problem I would think the following line
> should be changed to a default value of 2 (if Mario is right)
> +++ b/drivers/hid/hid-input.c
> +static int hid_apple_fnmode = 1;
>
> With regard to the swapped "½" and "<" key it is seemingly done by p
> urpose by this, since my keyboard is an ISO keyboard:
> +++ b/drivers/hid/hid-input.c
> +static struct hidinput_key_translation apple_iso_keyboard[] = {
> { KEY_GRAVE, KEY_102ND },
> { KEY_102ND, KEY_GRAVE },
> I don't know the reason for this, but it is wrong for my keyboard
> with danish layout. Does anyone know why this is done?
>
> With regard to the Num-lock problem as far is I can see it is due to
> laptop and non-laptop keyboards treated equal. Erics patch above
> should
> address this.
>
> I am no kernel hacker but would love to try to tinker with the code.
> Could anyone give me a pointer to how to compile a module as Eric has
> done above?
>
> Also shouldn't this bug be set to affect "linux (Ubuntu)"?
>
> --
> Slim USB Apple Keyboard not working correctly..
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.

This patch solved my problem with wrongly mapped keys. I am no kernel-hacker, but it also seems odd that locale specific mappings are done in the kernel anyway. This is my first official kernel-patch, so I have no clue of what to do to get it merged in the Ubuntu kernel?

Eric,
I managed to compile a kernel with your patch applied and it solved the "virtual keypad" problem for me. I hope you will be successful in getting it applied to Ubuntu kernel.

Mario,
I managed to change the pb_fnmode to 2 and it solved the 'fn' key problem for me. The other behavior might be default for Mac users, but I am not a Mac user. I just bought this nice keyboard for my PC, so it seems very odd to me that 'F*' keys must be so difficult to use. Well hopefully someone will regain their senses and realize 'F*' keys are used for so many tasks in Linux...

After doing a bit of research on this particular issue, I've come to a few of my own conclusions. I'll start by running down the issue.

Hardware: the slim aluminum wired(although perhaps also wireless; same issues anyone?) apple keyboard.
Problem: the clear (numlock) key renders the keyboard practically useless. That is to say, it doesn't turn numlock on for the keypad, and disables _most_ other input from the keyboard (more on this later).

Diagnosis: according to this post (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/162083), there was an issue with the macbook keyboard; the fn key was patched to restore function of the fn key. In that same line of update, I believe the laptop functions of this particular keyboard were addressed. I'm uncertain, but somewhere along the lines the keyboard was introduced into the kernel and fixed to work correctly (fn keys, additional numerical keys: *-+/= ). I believe this has also inversely affected these slim apple keyboards recently introduced. The kernel just sees it as the laptop version, and assigns the keymaps accordingly (assumption, as I have no technical experience in the matter; just my own deductions and research here, mind you).

For those who aren't quite sure of what's going on, here's a bit of a recap:
The numpad is needed, and numlock isn't on by default (this can be changed, but doesn't address the issue). Pressing the clear button on most models of apple keyboards is equivalent to the numlock key on a PC. In this particular case, since the kernel doesn't see the keyboard as a generic usb keyboard anymore (it's a macbook now), this key is remapped to whatever enables the numpad for its device. In this case, since it's a laptop, it's enabling the /*-+ keys on the Alpha keys, appropriate to where they'd be on the laptop. (This would be correct, were we actually using that model of keyboard.) After the clear key is pressed, the numpad still no longer works, and now all other functions of the keyboard are disabled except for the *-+ keys and the F6 key (more on this later). No other keys process (AFAIK). The mouse still works, and a log out restores functionality.

Fix: This is an issue. Although the keyboard is acting appropriately for how it's assigned, it's not right. The fn key isn't helpful on a full-sized keyboard (in fact it's rather harmful, as alt+fn+f1 is a pretty big stretch for my tiny hands), and neither are the remaps of the numerical keys, since we have a numpad. It's especially less so if the numlock renders the rest of the keyboard useless. What is needed is for the kernel to recognize this particular keyboard differently from the laptop version. I suppose a generic usb keyboard remapping would work essentially the same, but the fn key would then be useless, unless remaped to insert, like my old apple keyboard was. Alternatively, it would be nice to preserve the media, brightness, et cetera keys by assigning them to work with fn pressed. This could work if the fn key were remapped as a modifier key(right now fn isn't recognized as an actual key to assign for anything) specific to the media keys and etc keys. I wouldn't miss them much, but I'm sure some people would ...

wow, that was a very thorough and (I think) correct analysis of the situation. I just want to say that I agree 100% (as in: every single word) with what ChaseNeveu just wrote.

I think the proposed solutions would fix all the problems and make the greater part of users happy; I even remember that in a mac store I worked in recently, I was told to use fn to access the media/volume keys (that is, on iMacs); therefore I don't know if this was the default behavior of newer macs, but is certainly is possible and is, in my opinion, much less dangerous (and much more functional) than the current behavior in Hardy. Ctrl+alt+fn+F7/F9 is not a sane amount of keys to press and hold to switch TTYs, for example.

Jean-François Fortin Tam wrote:
> wow, that was a very thorough and (I think) correct analysis of the
> situation. I just want to say that I agree 100% (as in: every single
> word) with what ChaseNeveu just wrote.
>
> I think the proposed solutions would fix all the problems and make the
> greater part of users happy; I even remember that in a mac store I
> worked in recently, I was told to use fn to access the media/volume keys
> (that is, on iMacs); therefore I don't know if this was the default
> behavior of newer macs, but is certainly is possible and is, in my
> opinion, much less dangerous (and much more functional) than the current
> behavior in Hardy. Ctrl+alt+fn+F7/F9 is not a sane amount of keys to
> press and hold to switch TTYs, for example.
>
My comment will be that the wireless variant is not affected by any issues as
listed here.

--
Mario Limonciello
<email address hidden>

Thank you Mario. I assumed this was the case, since the wireless version is more laptop styled.

Jean, can you confirm that the F6 trick works? I've talked to Brad and it worked for him, and it also works for me, just wondering your success.

Now I'm just wondering when this bug will get some attention. Can we assign some importance to it, now that the issue is clear and a fix is proposed? Who's doing something about this?

ChaseNeveu, I remember being able to "unlock" the keyboard by pressing F6 twice, yes.
I'm nominating this for hardy, in the hope it gets some love.

Thanks Jean.

If any more information is needed to help with this bug, I'll be happy to oblige.

Just a waiting game now, then? I'd really like to see this fixed, so no one else has to deal with this bug as I had to.

The NumLock issue is solved by Eric Johneys "keyboard.patch" above. I hope someone will apply it soon...

The attached patch furthermore solves that F5 and F6 work opposite to the other F-keys when pb_fnmode = 1 (which unfortunately is the default?!)

Bump. Would like to see this fixed also. I would like to get a not-too-expensive-keyboard that will save my wrists from pain and this apple keyboard is the most convenient thing to get my hands on.

There is also a simpler way to fix the numlock issue:

1. make sure, you have xmodmaps installed (this should be by default)
2. create the file ~/.xmodmaps
3. paste the following into the file:

keycode 79 = 7
keycode 80 = 8
keycode 81 = 9
keycode 83 = 4
keycode 84 = 5
keycode 85 = 6
keycode 87 = 1
keycode 88 = 2
keycode 89 = 3
keycode 90 = 0
keycode 91 = period
keycode 82 = minus
keycode 86 = plus
keycode 157 = equal
keycode 77 = F20

the last line remaps the clear (=numlock) key to behave as F20 instead.

sorry, forgot to add:

4. run xmodmap ~/.xmodmap

it might be necessary to run this on startup

Hi Muro,

Nice little trick! Unfortunately it will only work in X and not for the console. Furthermore I really think the bug should be properly fixed in the kernel, where it originates.

same problem here with apple usb keyboard

thanks for the xmodmap file
/ and * are missing by the way

Tommy, probably way too late, but I thought I'd mention, for the record:

When you type: sudo echo 2 > /wherever
Bash sees: (sudo echo 2) > /wherever

What you probably want is something like "sudo su -", then you can just edit it. Or "echo 2 | sudo tee /wherever" will work, too.

I still want to know where the best place to set this is, though -- I suspect it would be somewhere in udev.d, but i really don't know my way around that. For now, I'm sticking it in rc.local, so I don't forget.

same problem with apple alu usb keyboard connected to a regular PC (not apple computer).

I guess the kernel fixes for this didn't make it in time for hardy. Will they be sent out as a regular update some time down the line? Or for 8.04.01?

Just upgraded from 7.10 to 8.04 LTS release version and when it came up had no working keyboard... disappointing. I have the slim, aluminium, full-length wired Apple USB keyboard. I am running AMD64 on a standard PC.

Followed the workaround using a PS2 keyboard to switch off numlock and now have working alpha-numeric keys. Then followed the kb layout instructions to get working keypad. Without a spare keyboard, I can disable numlock by pressing the <F6> key twice in 'problem' mode.

All keys work now but:
*Function keys (F1, F2 etc.) don't work unless <fn> key is held down, which is a serious problem
*Eject key registers, that is eject symbol appears on screen, but drive does not eject
*Volume keys are sluggish and take between 2-10 seconds to register a response(but are useless to me anyway since my master volume control does nothing on my Asus M2N-SLi motherboard)

It is surprising to me that this problem flowed into the release version, seeing as it has been known about since March 13th.

Under Ubuntu 7.10 the eject key worked, the volume keys did not work(but I don't need them anyway) and the function keys worked how they should work, on a normal keyboard.

100% agree with ChaseNeveu regarding problem summary, just would like to add that if a custom behaviour is planned for this full length keyboard:

1) It would be nice to disable the numlock function of the <clear> key, and if possible, allow the <clear> key to "clear" entries in programs such as Calculator

2) Allow the <=> equals key to map to the alpha-numeric equals, or enter, or something else, to actually display an answer in Calculator.

Same problem since i updated from 7.10 to 8.04 !

F6 trick works fine for me (Slim Alu USB Apple keyboard on PC)

I also have two keys inverted, @# and <>

Don't need to use xmodmaps to use numpad, just set this (in french sorry)

Système -> Préférences -> Clavier
Onglet "Options de l'agencement"
Rubrique "Diverses options de compatibilité"
Cocher : "Touches du pavé numérique par défaut" et "Les touches du pavé numérique se comportent comme sur un Mac".

As i sue quite same configuration at home and at work, i'll keep 7.10 at work 'till this bug isn't solved.

While poking around the source to see what's going on, I discovered an amazingly simple workaround for this problem (the numlock one, that is):

set pb_fnmode to 0. (via sysfs and in a modprobe options file)

This will disable that entire section of code causing the problem.

Cheers

@Edwin Erdmanis

The fn "problem" is a feature: it mimics the way the keyboard works under OS X.
For me eject, volume and brightness keys work perfectly. (Hardy on a MacBook)

@Fabrice
The <> @# problem is solved for me in gnome by selecting the appropriate option («Swap keycodes of two keys when Mac keyboards are misdetected by kernel» in the keyboard options menu.
However, the «Numeric keypad keys work as with Mac» oprion doesn't work for me.

@Ryan Lortie

Just for the record : the /sys/module/hid/parameters/pb_fnmode tric works, but disables the keypad and the fn functions altogether.

@Frédéric Grosshans:

It's a mis-feature at best. 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.

Switching /sys/module/hid/parameters_pb_fnmode to 2 on non-laptop Apple keyboards seems like the best solution. Make it then an option for people who want it to run like OS X.

Just wanted to say that I have the slim Apple Keyboard, and am having the numlock key problem. For those of you who do the bug fixing, I want to get a vote in for changing the f-keys to their values by default. If I want to change my volume for example, pressing fn before hand seems most appropriate and allows the function keys to be more accessible.

Also, the f6 trick is good to know. I spent 20 mins trying to figure out how to get the numlock to unstick. Now I can unplug my old keyboard and use my apple one (which is the best keyboard ever) until the bug gets fixed.

All the keys on this keyboard work correctly except for the "Clear" key. Someone should make the "Clear" key be the key for "Numlock".

That's all that needs fixed.

The "fn" key is set up right now exactly how it's supposed to be on this keyboard. I understand it can be a pain to type (ctl + shift + fn + f2) but it's not impossible, nor is it something someone should be pressing all the time.

Right now, I can use the volume up/down/mute, forward/backward/pause/play keys without the fn key pressed. I like this way because I use those keys a lot more than I use the terminal/console key combination.

@Brad:
What you describe is easily obtainable for any keyboard by spending 5 minutes in the Keyboard Shortcuts program. Right now this mapping is done by adding (buggy) code to the kernel - and is very difficult to change back for users expecting their F-keys to work consistently as for any other keyboard. Furthermore F5 and F6 are inverted compared to the other F-keys!

The F-key are important keys in OpenOffice, Firefox, Evince, Evolution, Krusader and many, many other programs - and often the F-keys even has modifiers like Ctrl and Shift. This makes it unacceptable to require fn to be pressed for using the F-keys, whereas it is a small offer to require the fn key pressed for the six(!) media keys that actually have a meaning in Ubuntu.

@Brad:
Have you tried pressing <ctrl + alt + fn + F7> lately?

There has to be a way to keep both OSX people and Linux people happy, a simple check-box would suffice.

[quote=brad]The "fn" key is set up right now exactly how it's supposed to be on this keyboard.[/quote]

I'm sorry, but the way Apple makes things work is not necessarily the way it is "supposed" to work. This behavior is the opposite on most every keyboard out there and only affects a keyboard on a Mac portable because it has to have additional functions. Even a full Apple keyboard doesn't behave in that manner. Pretty much every laptop I have ever used has this in reverse, accessing the specialized functions such as brightness, video output switching, wifi control, etc by using the Fn key, unless of course there is a dedicated button for those functions.

Hey everyone, I'm just saying..

You bought this exact keyboard and this is how this one keyboard is made to work. lol

I'm not saying it has to be that way, but it is the original way for this exact keyboard, and you bought it that way. The thing even works this way on a mac, I know cos my friend has one. It was made for multi-media before function keys. Maybe Linux has a bad/old way of using keystrokes?

Or maybe Mac is just weird.

Either way... Neither way is wrong I guess.

Actually I think you will find that the function keys (F1, F2 etc.) would work in the default way (without holding the <fn> key) if you plugged the keyboard into Windows. And it also worked this way in the last Ubuntu release (7.10) by default. Holding down the <fn> key modifier to get the function keys to work seems to be an OS X only thing.

FAIK, this bug is about the numlock problem.

For the definition of the "correct" fn key behavior, the correct bug seems to be https://bugs.launchpad.net/ubuntu/+source/linux/+bug/201711 ,

For the swapped <> and @#, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/214786

2008/4/30, BradwJensen <email address hidden>:

> You bought this exact keyboard and this is how this one keyboard is made
> to work. lol

No. I bought this keyboard because it has comfortable keys. And because it
is not some cheap plastic junk like all the keyboards I had before this. I
could not give a rat ass about how it's supposed to work on a mac, this is
Linux, not a mac.

I'm not saying it has to be that way, but it is the original way for
> this exact keyboard, and you bought it that way.

I did not buy it that way. I bought it with cash. And it should damn well do
what I expect this to do, and behave like any other keyboard I plug on this
friggin' linux box.

  The thing even works
> this way on a mac, I know cos my friend has one. It was made for multi-
> media before function keys. Maybe Linux has a bad/old way of using
> keystrokes?

I know that it works like this on macs. I have worked in a mac store just a
few months ago and I sold these things. That's where I bought mine. The mac
software is not centered around the F* keys, but most apps in the
windows/gnome/kde/xfce ecosystem use those keys. Don't give me some argument
about linux not being media centered enough, every other keyboard on the
surface of this earth that I could get my hands on has behaved correctly,
even this one... until now. The keyboard is supposed to interact with apps,
not the apps caving in to the keyboard.

Or maybe Mac is just weird.

It's not weird, it's different. Now, here, this is not a mac; a keyboard,
being apple-branded hardware or not, should behave accordingly to the host
platform.

I'm certainly more rude than I should be here, but attitudes like that in
this thread are really starting to piss me off. Oh sure, just relearn half
of your shortcut techniques, grow a third hand, or buy a different keyboard
or a mac! Oh yeah, just weave through the missiles!

@Edwin : for the "media keys", you apparently need to install pommed (see https://help.ubuntu.com/community/MacBook_Santa_Rosa ). I think this info should be on a different place, like https://help.ubuntu.com/community/FlameAboutAplleKeyboards ;-)

@Frédéric Grosshans:
Thank you for taking care of the housekeeping :) Will make an effort to stay on topic:

I believe that any work/patches that were done for MacBooks are actually working fine: Macbook users seem to be happy with the state of the current kernel as above. The problem seems to only effect users of the slim USB keyboards(such as myself).

It has been mentioned that the driver(not sure?) should detect whether the Apple Inc. keyboard is either the Macbook, or USB/External type and adapt it's behavior accordingly.

For the USB slim keyboard, IMHO, num-lock is not needed at all. There are no arrows marked on the num-pad and therefore arrow function on the num-pad is of no use. The num-lock/clear key should definitely *NOT* change the behavior of the alpha-num keys, as it unfortunately does currently - this is the specific problem I believe.

I believe that any work/patches that were done for MacBooks are actually
> working fine: Macbook users seem to be happy with the state of the
> current kernel as above. The problem seems to only effect users of the
> slim USB keyboards(such as myself).
>
It also affects me, using a slim USB keyboard on a MacBook

> It has been mentioned that the driver(not sure?) should detect whether
> the Apple Inc. keyboard is either the Macbook, or USB/External type and
> adapt it's behavior accordingly.
>
Agreed

> For the USB slim keyboard, IMHO, num-lock is not needed at all. There
> are no arrows marked on the num-pad and therefore arrow function on the
> num-pad is of no use. The num-lock/clear key should definitely *NOT*
> change the behavior of the alpha-num keys, as it unfortunately does
> currently - this is the specific problem I believe.
>
With or without numlock, I still want to be able to type numbers on the keypad. Its only functional key for me is currently the enter key. Not the most useful one ...

>It also affects me, using a slim USB keyboard on a MacBook

Interesting... does this mean you observe different 'oddities' comparing the internal MacBook keyboard, and the external USB slim keyboard? You may be in a unique position in that case, to report on and test the two different keyboards. I only have the USB slim external keyboard.

>With or without numlock, I still want to be able to type numbers on the keypad.

I agree that the keypad is necessary for typing numbers - I am suggesting that being able to type numbers in the num-pad is the only valid functionality, and there is no need for num-lock/clear or any other key to alter this behavior at any time.

Hey Guys..
I didn't read all the comments.. But I had a similar issue with a windows keyboard I connected to my macbook 3,1 SantaRosa
Both internal macbook keyboard and windows keyboard worked fine, when connected.. and when I remove the windows keyboard, macbook internal keyboard stops working..
and sometimes when I press alphabets on the macbook keyboard, numbers appear instead of alphabets.
In the login windows it worked fine.. After login the problem occurs..

This is how I fix it, when I get that problem..

I delete the directory ~/.gconf/system/peripherals
logout and login

Apologies for getting off topic Frédéric... thanks for getting us back inline.

I can confirm that this bug still exists, and that pressing F6 twice is the only way of getting out of numlock mode. Took me quite some time to figure out what was going on.

What's the status on getting this patched and fixed?

I have 2 macs and 2 Slim USB Keyboards. We will call them set 1 and set 2, to avoid confusion. I had an issue with the 6 on the number pad on set 1, so i switched out the keyboard with the one from set 2. (which worked fine- all keys) The 6 on the number pad on the keyboard from set 2 didn't work on the mac from set 1, and the 6 on the number pad from set 1 (which originally didn't work) worked fine hooked to the set 2 mac. I have obviously determined that it is an issue with the mac, but I do not know how to find the problem, let alone fix it.

Any ideas would be greatly appreciated.

Jamie,

You need to post in the forums. This is a bug tracking system and is not the place for support requests.
http://ubuntuforums.org/

Patch spotted in upstream kernel 2.5.26-rc4

http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Ftesting%2Fincr%2Fpatch-2.6.26-rc3-rc4.bz2;z=276

Just posting the upstream git commit id for the kernel team to reference. Has anyone been able to test and confirm this patch resolves the issue? Also note that this patch is already in the upcoming Intrepid Ibex 8.10 kernel. I'll try and update this report when the latest intrepid kernel build is available for testing. Thanks.

commit 6e7045990f35ef9250804b3fd85e855b8c2aaeb6

Author: Diego 'Flameeyes' Petteno <email address hidden>

Date: Mon May 5 16:20:50 2008 +0200

    HID: split Numlock emulation quirk from HID_QUIRK_APPLE_HAS_FN.

Hi,

I've put up some kernel packages (linux - 2.6.24-19.34cking4 with a linux-image that contains the fix) in my PPA at https://launchpad.net/~colin-king/+archive

Please try this kernel and report any success/regressions. If this fixed the problem I can add the fix to Hardy 8.04.1. Thanks.

Hi

I came up against this issue back in April when upgrading from Gutsy to Hardy - function keys no longer worked as they did in Gutsy. I ended up a bit lost and just wound up using my laptop keyboard for the missing functions, so it's good to finally find a discussion like this.

For what it's worth, as a user with a technical background, rather than an Ubuntu developer, here is my take on the issue:

* I have a full size Apple wired USB keyboard (http://images.apple.com/keyboard/images/gallery/wired_1_20070813.jpg), with number pad. I use it because it's very easy on my fingers, it's light - i can chuck it my backpack easily plus it is very well made and designed.
* I don't use it with an Apple PC, although I could in the future. I use it primarily with a Dell XPS 1330 laptop.
* The function keys not working look to be due to the keycode not being mapped to a specific key symbol. You can set this up as an Xmodmap file by grabbing the keycodes from xev and (in KDE) add that as a script to the ~/.kde/Autostart directory. I'm sure there is another solution.

keycode 101 = F1
keycode 212 = F2
keycode 166 = F3
! F4 keycode not found...
keycode 71 = F5
keycode 72 = F6
keycode 234 = F7
keycode 162 = F8
keycode 233 = F9
keycode 160 = F10
keycode 174 = F11
keycode 176 = F12
keycode 182 = F13
keycode 183 = F14
keycode 184 = F15
keycode 93 = F16
keycode 131 = F17
keycode 247 = F18
keycode 132 = F19

e.g
xmodmap /path/to/mymodmap.file

* The F4 key was never detected, even with getscancodes from keytouch.sf.net. I have two of these keyboard and neither emitted a keycode or scancode, so it isn't a faulty keyboard.

* The only other key not detected on the keyboard is the "fn" key, which neither emits a keycode in xev or a scancode in "getscancodes". This is a bit annoying as it would be the perfect modifier key for multimedia function fn+F12 for "Volume Up", for instance.

* One other thing to watch our for is that (on my dell laptop at least), the dedicated Dell media keys for Mute, Volume Up and Volume Down emit the same keycodes as F10, F11 and F12 on the Apple keyboard.

What I'd expect this keyboard to do in *ubuntu running on non Apple hardware. (I can't speak for what should, and probably does, happen on Apple hardware as I haven't used it)
* the function keys should just emit the F1-F19 keycodes that are mapped to the respective key symbols. hitting the F2 key on it's own should not increase brightness.
* the fn key should be detected and be used as a modifier key, like on a non apple laptop. For instance on the Dell, Fn + UpArrow increases screen brightness.
* the fn key together with the various media keys (F7 to F12) should carry out the generic XF86Audio* actions. For instance, hitting fn+F8 should Play/Pause, fn+F2 should increase brightness.
* the "clear" key should not be a numlock key, there is no need for it as a numlock on a fullsize keyboard. As someone else suggested, it should clear a calculation or maybe emulate "esc" key.
* the number pad should be enabled by default.
* the command key should be the same as the meta/windows key on a non apple laptop.

I hope that info helps out with any decisions made on this. While I am on th...

>Please try this kernel and report any success/regressions. If this fixed the problem I can add the fix to Hardy 8.04.1. Thanks.
I tried this kernel, it fixes the problem. Thanks!

SRU justification:

Impact: Slim USB Apple Keyboard stops working if a numpad or number key
is pressed.

Testcase: A clean boot, keys work. Press numpad or number key and the
keyboard stops working.

Patch in my PPA tested and verified
https://bugs.launchpad.net/ubuntu/+bug/201887/comments/72

This patch splits the Numlock emulation for Apple keyboards in a
different quirk flag, so that it can be enabled for all the keyboards
but the Aluminium USB ones.

If the Numlock emulation is enabled for Aluminium USB keyboards, the
JKL and UIO keys become the numeric pad, and the rest of the keyboard
is disabled, included the key used to disable Numlock.

Additionally, these keyboard should not have a Numlock at all, as the
Numlock key is instead replaced by the 'Clear' key as usual for Apple
USB keyboards.

Patch from upstream cherry pick 6e7045990f35ef9250804b3fd85e855b8c2aaeb6
backported for Hardy.

I too have one of these new aluminium keyboards, and I too think it should behave the way we want it to, not the way some more or less illuminated Steve Jobs' HIG designer decided to. Apple has made poor choices in design at times (such as their stubborness with the one-button mouse) and we don't need to live with them.

That said, this keypad bug only happened to me once, and I had to reboot to fix it. I wasn't hitting the "Clear" or "KP_Lock" key by the way... I was plugging in and out the mouse from the USB hub of the keyboard. Strange.

I have the Apple Aluminum USB Keyboard. I have tried to use it on Fedora 9, Ubuntu 8.04 and Suse 11 with the same problem on each distribution. The keyboard is acting like a laptop keyboard with the number lock on to the QWERTY keys change into a numerical keypad. I can't figure out a way to stop it. I've tried changing the layout and also type of Keyboard with no avail. Only some keys work as people have previously mentioned. This is the only thing stopping me from using Ubuntu on my Mac Mini. Seems like the problem is due to the hardware not being supported by Linux since this keyboard is clearly different internally than most. Hope this gets worked out.

Is it safe to purchase this keyboard now, is the new kernel working for many people, and will the fix be released soon?

Hey I had the same problem with this keyboard. Solution is pushing F6
twice and it should work fine.

On 15/07/2008, at 3:30 PM, Justin Sunseri wrote:

> Is it safe to purchase this keyboard now, is the new kernel working
> for
> many people, and will the fix be released soon?
>
> --
> Slim USB Apple Keyboard not working correctly when pressing the
> "numlock" key
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Mactel Support: Confirmed
> Status in “linux” source package in Ubuntu: Fix Committed
>
> Bug description:
> I have the new Slim USB Apple Keyboard and in Hardy Heron (Beta)
> when I first boot up the alphabet keys work perfectly, but once I
> type in the numpad or a number, nothing happens. After nothing
> happens I'm not able to use my alpha keys, either.. When I type
> alphabet keys after trying a number the alphabet keys produce
> numbers like '4' and '3'.. And many of the keys don't do anything..
>
>
> I have tried setting the keyboard up as default, and as an Apple
> keyboard by going to System > Prefs > Keyboard -- but nothing works.
>
> If i then unplug the keyboard to reboot the keys usually work fine
> until I hit a number key or the keypad again.

I was told, after system boot, press F6 twice. I tried this and it worked for me!

did you try the kernel colin packaged?

I tried it on my current distros (with no changes) and the F6 two times worked. The distros I used is Fedora 9, Ubuntu 8.04 and Suse 11. They all seemed to work with the F6 trick.

When are these going to start showing up in the Hardy kernels? Are there any plans to put the patch in this series, or is the plan to release it in Intrepid?

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

After upgrading to the newest kernel here is what I found. Pressing a key on the number pad does not cause the letter keys to malfunction anymore. The issue now is that the number pad is behaving like a directional pad. Pressing the clear button at the top of the number pad turns on the number lock and once the number lock is on then it behaves like a normal number pad. I'm not sure if this is the intended behavior but it seems very undocumented looking at the keyboard. You really don't expect the clear button to toggle the num lock. Not sure if it is a gnome issue or kernel issue but the brightness keys F1 and F2 do not adjust the brightness of my laptop screen. If you need any other information please let me know.

The numpad behavior is consistant with most other PC keyboards. I believe this is the desired functionality. The "clear" button is in the place of most keyboard's numlock keys.

Your other issue should likely go to a different location unless this test reversed previous functionality.

I'm afraid that I must disagree with your assessment. There is no way on
earth that I can justify the number pad working as a directional pad by
default when there are no arrows marked on the keys and no visible number
lock key. Why should someone have to go find a real keyboard to find where
the number lock key is if all that person has is mac hardware? Who is to
say that that person will even realize that finding the number lock key
would be the answer to his problem. All someone who plugs in this keyboard
will know is that his numbers don't work and there is no visible indicator
on the keyboard what is going on. luckily i am using a laptop that has a
number lock light and i can see the status of the lock. If a person is
using a desktop there will be no such indicator as there is no number lock
light on the keyboard itself.

Is there anyway we can get this keyboard to default to number lock on
behavior by default?? Even if this is outside of the kernel itself when
someone plugs in this keyboard the system should know that the most
desirable mode of operation for this keyboard is to enable to number lock.

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

I am not trying to say what is right and what is wrong, just trying to explain why it functions as it does.

Tested the latest kernel from hardy-proposed (2.6.24.20), results are just as expected:

 - on startup the numpad keys behave normally, entering digits
 - pressing Clear button switches the numpad to navigation mode

Excellent, thanks a lot for fixing this!

Re: numlock or navigation buttons by default: it depends. I'd rather prefer navigation mode by default, and switch on the numpad when I need a numpad, but that's my personal preference. Luckily, it can be configured https://help.ubuntu.com/community/NumLock.

Justin, you may be interested in this.

Thanks Fedor, that just masks the issue though, pushes off and reverses the
problem. Doing that when i take my laptop somewhere without the keyboard
now I would get numbers where I expect letters and I would have to turn off
the number lock. Is there a way to enable the number lock by default when
this device gets plugged in?

On a completely different issue what is that symbol on the f4 key supposed
to stand for? it looks lie a fuel gauge

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

Justin,

That's the dashboard key: http://support.apple.com/kb/HT1117
(Note the picture is that of a macbook pro keyboard, but I think the usb keyboard has the same layout).

Alex

I'm not sure what the "clear" key does, though a quick Google search shows:

http://www.google.com/search?q=os+x+clear+key&ie=UTF-8&oe=UTF-8

The link doesn't work well for me, but the Google summary of the first result includes:

"The Clear key, of course, acts like the clear key on a calculator..."

In other words, whatever it is supposed to do, it is NOT supposed to act like a numlock. I would argue that in this case, we should only allow the directional mode for users sophisticated enough to go searching for it -- remember, there is no visual indication that numlock is on or off, and the functions it performs (other than numbers) are not visible anywhere on the keyboard.

So any new user who happens to press the "clear" key will now think something along the lines of "My computer is broken!"

Having the option of directional arrows is nice, but for this keyboard, leave it off by default.

Apple themselves recognize that Numlock must be supported on non-apple OSes:

http://support.apple.com/kb/HT1216

In short, yes, Clear button is supposed to work as a Numlock, only not in MacOS.

I've seen many discussions on this topic already, I think whatever hardware is used, Ubuntu must support what Ubuntu users want. If this particular keyboard is plugged into a Mac it's a Mac keyboard, when it's used with Windows it's a Windows keyboard, and when used with Ubuntu? I guess it should be Ubuntu keyboard!

I'm an Ubuntu user and I want Numlock. I don't care whether it is supposed to be used as such or not. I don't care about what is printed on the buttons (there are keyboards without any text at all, so what?). I want the functionality that I'm used to.

Is there not a way to set whether numlock is on or off by default on bootup?

Fedor, I have no doubt that you want the directional pad. You know its
there and that's great for you. But for someone who just bought this
keyboard and does not know it is there turning the directional pad on by
default can only cause confusion. If someone buys this keyboard and his
numbers don't work he is not going to know to hunt around for a num lock
key. There is no visible num lock key and no arrows on the keyboard that
would indicate that this is expected behavior. It will only seem broken.
Honestly I wish I could put a sticker on everyone's clear key so that they
know it is a num lock key and the directional pad can be on by default but
we can't do that it's out of our control. What we can control is making the
keyboard behave as expected for the majority of people looking at the
keyboard. I don't honestly think that people are going to look at that
clear key and say that it must be a num lock key because it is in the
location normally occupied by the num lock.

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

The first thing I do on a keyboard with a numeric pad, is to enable the numeric functionality. I always thought that having it act as a directional pad by default is counter intuitive. I mean, I expect the fraction of people who use it as a directional pad to be very small compared to the number of people who use it as a number pad.

So personally, I would prefer if the default was switched to a number pad on all keyboards (isn't that the default behaviour on OSX and Windows anyway?!)

However, I'm leaning toward the argument that there should be no special treatment for the apple keyboard, though I'm on the fence on this one :)

Justin,

you may be surprised to learn, that despite you don't believe people are looking for Numlock button where it's supposed to be, it's actually the case. Well, except maybe for hardcore Mac users. But they don't have a reason to look for it anyway.

On the other hand, who really knows what Clear button is supposed to do? Given the pictogram displayed on that key, I bet rarely anyone without Mac experience would be able to decipher that. Also, BootCamp emulates Numlock on Windows with Clear key.

I think people are smart enough to guess that Clear == Numlock.

Who wants to rely on people being smart? What is printed on the key should
be the default behavior. period.

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

I think this is all a bit off-topic for this bug. The bug was originally focused on the fact that having numlock on would cause part of the qwerty portion of the keyboard to change to a number pad (like on a laptop keyboard). The clear key has always acted a numlock on apple keyboards even before this bug.

A new bug has been submitted
here<https://bugs.launchpad.net/ubuntu/+bug/251219>.

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

PLEASE REMOVE ME FROM YOUR LIST.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Ricky Campbell
Sent: Wednesday, July 23, 2008 1:33 PM
To: <email address hidden>
Subject: [Bug 201887] Re: Slim USB Apple Keyboard not working correctly when pressing the "numlock" key

** Changed in: mactel-support
       Status: Confirmed => In Progress

--
Slim USB Apple Keyboard not working correctly when pressing the "numlock" key
https://bugs.launchpad.net/bugs/201887
You received this bug notification because you are a direct subscriber
of the bug.

Status in Mactel Support: In Progress
Status in “linux” source package in Ubuntu: Fix Committed
Status in linux in Ubuntu Hardy: Fix Committed

Bug description:
I have the new Slim USB Apple Keyboard and in Hardy Heron (Beta) when I first boot up the alphabet keys work perfectly, but once I type in the numpad or a number, nothing happens. After nothing happens I'm not able to use my alpha keys, either.. When I type alphabet keys after trying a number the alphabet keys produce numbers like '4' and '3'.. And many of the keys don't do anything..

I have tried setting the keyboard up as default, and as an Apple keyboard by going to System > Prefs > Keyboard -- but nothing works.

If i then unplug the keyboard to reboot the keys usually work fine until I hit a number key or the keypad again.

PLEASE REMOVE ME FROM YOUR LIST

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Justin Sunseri
Sent: Wednesday, July 23, 2008 1:42 PM
To: <email address hidden>
Subject: Re: [Bug 201887] Re: Slim USB Apple Keyboard not working correctly when pressing the "numlock" key

A new bug has been submitted
here<https://bugs.launchpad.net/ubuntu/+bug/251219>.

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

--
Slim USB Apple Keyboard not working correctly when pressing the "numlock" key
https://bugs.launchpad.net/bugs/201887
You received this bug notification because you are a direct subscriber
of the bug.

Status in Mactel Support: In Progress
Status in “linux” source package in Ubuntu: Fix Committed
Status in linux in Ubuntu Hardy: Fix Committed

Bug description:
I have the new Slim USB Apple Keyboard and in Hardy Heron (Beta) when I first boot up the alphabet keys work perfectly, but once I type in the numpad or a number, nothing happens. After nothing happens I'm not able to use my alpha keys, either.. When I type alphabet keys after trying a number the alphabet keys produce numbers like '4' and '3'.. And many of the keys don't do anything..

I have tried setting the keyboard up as default, and as an Apple keyboard by going to System > Prefs > Keyboard -- but nothing works.

If i then unplug the keyboard to reboot the keys usually work fine until I hit a number key or the keypad again.

you have to go to the bug report and remove yourself i can't remove you.

On Wed, Jul 23, 2008 at 1:01 PM, Jamie <email address hidden> wrote:

> PLEASE REMOVE ME FROM YOUR LIST.
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> Ricky Campbell
> Sent: Wednesday, July 23, 2008 1:33 PM
> To: <email address hidden>
> Subject: [Bug 201887] Re: Slim USB Apple Keyboard not working correctly
> when pressing the "numlock" key
>
> ** Changed in: mactel-support
> Status: Confirmed => In Progress
>
> --
> Slim USB Apple Keyboard not working correctly when pressing the "numlock"
> key
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Mactel Support: In Progress
> Status in "linux" source package in Ubuntu: Fix Committed
> Status in linux in Ubuntu Hardy: Fix Committed
>
> Bug description:
> I have the new Slim USB Apple Keyboard and in Hardy Heron (Beta) when I
> first boot up the alphabet keys work perfectly, but once I type in the
> numpad or a number, nothing happens. After nothing happens I'm not able to
> use my alpha keys, either.. When I type alphabet keys after trying a number
> the alphabet keys produce numbers like '4' and '3'.. And many of the keys
> don't do anything..
>
>
> I have tried setting the keyboard up as default, and as an Apple keyboard
> by going to System > Prefs > Keyboard -- but nothing works.
>
> If i then unplug the keyboard to reboot the keys usually work fine until
> I hit a number key or the keypad again.
>
> --
> Slim USB Apple Keyboard not working correctly when pressing the "numlock"
> key
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

I'm running ibex alpha 3 and the numlock works as I expect.

The only problem I'm having with the keyboard now is the F keys.

In order for me to open the run command I have to press ALT + fn + F2.

I would expect the fn key to enable the extra functions on the keys rather than enable the F-Keys.

Is there anything in the works to change the way this work or am I going to be stuck with this?

you are looking for this bug:
https://bugs.edge.launchpad.net/mactel-support/+bug/201711

Ahhh, thanks.

There is a guide in there that solves the issue.

:D

The Numlock behaviour for apple keyboards was fixed somewhere between 2.6.24 and 2.6.26 with the introduction of a HID QUIRK flag.

Patch attached that backports the HID_QUIRK change to 2.6.24.

Offtopic, but any chance that the mapping of command/option is one of the "quirks"?

Being able to have alt and win be where my muscle memory thinks they are, without having to switch manually when switching keyboards (I've got a PC laptop that I plug this keyboard into), would be awesome.

Unfortunately, there's not much to be done about the fn key, without hacking the firmware...

Confirmed on Dell OptiPlex 745 PC, 2.6.24-16 (also tried 2.6.24-19), with Apple Slim keyboard.

Solved by pressing F6 twice after each reboot and painting the Num Lock key red so that I never press it again

This is an very annoying and striking issue. I can't help the sarcasm, but I just feel frustrated after months of trying to use the Apple Wireless keyboard -- how long is it going to take before I can get the patched somewhere-between-2.4.26-and-2.4.26 kernel through the usual channels (apt-get) without having to compile the kernel just to use a keyboard with my Ubuntu?

larrycz, I think the problem was that the External Apple Keyboards were being mistakenly identified as the built-in keyboards on MacBook Pros (which have a psuedo-numberpad on the main keys when numlock is turned on). As far as I know this has been fixed in Intrepid. Can you test it there?

Would it be possible for some of the commenters to verify that the problem, as described originally, is addressed by the kernel image in hardy-proposed? Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. I note that Justin Sunseri has appeared to do this already, so we're looking for one more tester, though more would be better of course.
Thank you in advance!

Steve Beattie:

The Proposed files fix this problem.

To get proposed working: "System > Admin > Software Sources > Updates Tab", and then check the box that says, "Pre-released Updates (hardy-proposed)".

After getting the proposed box checked, you can refresh your source list and update your software. This will fix the numlock problem with the Slim Apple keyboard.

The proposed updates do, indeed, stop the keyboard going into laptop mode when the numlock/clear key is pressed.

It's still sub-optimal, though:
* The function keys only work when 'fn' is held down. The pb_fnmode value change corrects this, but this *should* be the default: without 'fn' held down, the keys can't be mapped to Compiz's scale plugin etc. so they're dead keys.
* Numlock defaults to off, even though the key is not intended to be numlock. Keeping it numlock is OK (since people seem so passionate about it), but it should default to on (as there is no LED indicator for 'clear')

I don't agree with Andrew's assessment of the function keys. This isn't a
normal PC keyboard and we shouldn't try to make it one. For the same reason
the number lock should always is the same reason that the media keys should
be used over the function keys. Yes its annoying sometimes but I end up
using my media keys far more often than fn keys and when looking at they
keyboard it is clearly obvious that the media keys are what a user expects
should happen if he presses one because the media key icon is so much
larger. Same situation with the directional pad. We should try to be
consistent with what is actually on the keyboard not with what is in our
minds that the keyboard should be. Yes its different but thats what buying
apple hardware is all about. "Think Different"

I have another bug open for these issues
https://bugs.launchpad.net/mactel-support/+bug/251219

--
Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

> This isn't a normal PC keyboard and we shouldn't try to make it one.

As has been pointed out above, though: the primary OS for this keyboard is OS X. Apps for OS X use function keys a *lot* less than Linux apps in terms of keyboard shortcuts etc. This is argument #1 - from a user-centred design point of view, for making the default different to this keyboard's behaviour in OS X.

Argument #2: this keyboard is a nice keyboard, and many people using it with Ubuntu are using it on non-Apple hardware. In fact, I'd wager that *more* Ubuntu users use it with non-Apple hardware than with.

Argument #3: Some of the keys don't have media/hardware use. This is another UCD argument for making the default behaviour one all keys support.

Argument #4: In their default configuration the keys aren't bindable. Steps to reproduce: System > Preferences > Advanced Desktop Effects Settings > Scale > Bindings; click keyboard shortcut for "Initiate Window Picker"; click "Grab key combination"; press Exposé key (F3); label changes to "disabled".

Argument #5: There is no easy way - except going through each application, and each Compiz setting, separately to make the behaviour of Ubuntu match the brightness, scale, widget layer and volume buttons.

> We should try to be consistent with what is actually on the keyboard not
> with what is in our minds that the keyboard should be.

Indeed: this is why I believe the numlock should be enabled by default (and why I'd prefer the 'clear' key to work as such in Calculator, OpenOffice.org, etc.). However, every function key has a 'F\d' label on it - this isn't making up behaviour.

> Yes its different but thats what buying apple hardware is all about.
> "Think Different"

The only Apple hardware I currently own is this keyboard. We should be trying to ensure that this keyboard (and any other hardware) presents the most usable and joyful experience when using Ubuntu. Any *intended* use by its manufacturer, or behaviour on another operating system should play second fiddle to this.

I have noticed windows users picking up this keyboard as well.
How would you think they configure it in windows? Foremost, a
keyboard layout is about usability in concert with the operating
system at hand - not any other operating system.

Henrik

After following this ttps://help.ubuntu.com/community/AppleKeyboard to get the functions working as expected on PC you might want to swap the positions of Alt/Cmd keys, create an Insert key and do some other minor modifications to make the layout more similar to PC keyboards.

Find attached an .Xmodmap file correcting those issues. Copy to your home directory to execute automatically on login or call xmodmap with it to activate manually.

linux 2.6.24-21 copied to hardy-updates.

I lightly fallowed this problem about a moth ago both here and in kernel and believed that a kernel fix was commited to fix the function keys, however i am in intrepid beta and they have not been fixed, i believe this is importand, the function keys should do theree special thing when you are pressing the fn key, and be normal F keys when not. I really dont feel like going into kernel commits again nor compiling a comtum kernel but i am in strong support for changing this to what people expect out of their F keys on linux (not necc on mac)

Though it feels as though it took an awfully long time to get here (March!?!), I can confirm that hardy-updates for 2.6.24-21 has solved the Apple slim USB keyboard problems for this Ubuntu user.

Thanks to everyone who hashed this out and to those developers who made this possible.

Now . . . getting that numlock on by default (as it should be . . . ) ;)

i am getting this on intrepid too, in addition on intrepid my numpad keys completely dont work

@sceintus

You must tap 'clear' to enable the numpad by default. As discussed throughout this thread and elsewhere, the decision was made that 'clear' is in the spot a user might expect the 'Num lock' key to be, and it will be detected and treated as such. So, after booting the computer, or at any time, just tap 'clear' and your keypad will work.

I'm assuming that you are running the latest Intrepid kernel (you did a distribution upgrade and have updated any packages through apt).

nope creatifx, before that worked, but now if i tap 'clear' or numlock on aanother (ps/2) keyboard the numpad doesnt work, hmm woah, numpad on that is broken too, so its not a prob with the keyboard, my keypad is just completely toast in the os for some reason, where hsould i report that?

also a wierd bug (prob related) is that in vmware when i press 'up' on the arrow keys (not keypad) it triggers printscreen in the vm.

What kernel are you running (what is the output of running uname -a in a terminal)?

Linux ubuntu-server 2.6.24-21-virtual #1 SMP Mon Aug 25 18:40:59 UTC 2008 i686 GNU/Linux

 lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01)
00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
00:0f.0 VGA compatible controller: VMware Inc Abstract SVGA II Adapter
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10)

To my knowledge, the kernel installed by default with a full intrepid ibex install is 2.6.27-7-generic i686

However, I can confirm (as I did above) that my Hardy system worked just fine once I upgraded to 2.6.24-21

This is with the full-size slim USB keyboard ... I don't mess with that tiny wireless stuff (gotta have my keypad)

Hey guys,

There is no such thing as "Number Lock" in the Apple Keyboard. If your keypad is not working, it could be because Mouse Keys are turned on in System Preferences -> Universal Access -> Mouse & Trackpad. From there you can turn this function off or (if the box is checked) you can press the Option key 5x to turn Mouse Keys on or off.

Mouse Keys give the keypad the funtionality of a mouse. If you were to hold the "8" key down, your mouse would go up; "4" would go left and so on.

If the keyboard is not operating in a certain software program, it sounds like a software issue. Some would say that this is an issue with the Apple Keyboard, but remember that software is designed for the operating system. And the Apple Keyboard is meant to work with Apple OS.

As for using kernal patches, I strongly recommend caution. Since Apple keeps the kernal very secretive, it's not wise to go messing around in there.

Well, I hope this helps.

Is Nick King smoking crack? This is a Ubuntu Linux bug tracker not Apple.

Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

On Tue, Feb 10, 2009 at 8:41 AM, nick king <email address hidden> wrote:

> Hey guys,
>
> There is no such thing as "Number Lock" in the Apple Keyboard. If your
> keypad is not working, it could be because Mouse Keys are turned on in
> System Preferences -> Universal Access -> Mouse & Trackpad. From there
> you can turn this function off or (if the box is checked) you can press
> the Option key 5x to turn Mouse Keys on or off.
>
> Mouse Keys give the keypad the funtionality of a mouse. If you were to
> hold the "8" key down, your mouse would go up; "4" would go left and so
> on.
>
> If the keyboard is not operating in a certain software program, it
> sounds like a software issue. Some would say that this is an issue with
> the Apple Keyboard, but remember that software is designed for the
> operating system. And the Apple Keyboard is meant to work with Apple
> OS.
>
> As for using kernal patches, I strongly recommend caution. Since Apple
> keeps the kernal very secretive, it's not wise to go messing around in
> there.
>
> Well, I hope this helps.
>
> ** Attachment added: "Mouse Keys.png"
> http://launchpadlibrarian.net/22444265/Mouse%20Keys.png
>
> --
> Slim USB Apple Keyboard not working correctly when pressing the "numlock"
> key
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.
>

My mistake.

Thanks Justin.

Justin Sunseri [2009-02-10 14:53 -0000]:
> Is Nick King smoking crack?

/me waves with the Code of Conduct. Please be more respectful to other
people!

> This is a Ubuntu Linux bug tracker not Apple.

Nevertheless this describes a problem of the mouse on an Apple laptop
when running under Ubuntu, so it's very much on topic here.

This hardware has a driver and is supposed to work with Ubuntu, so obviously
it belongs in the bug tracker. Watch your language.

Sincerely Yours
Nicholas Ipsen

On Tue, Feb 10, 2009 at 5:05 PM, Martin Pitt <email address hidden> wrote:

> Justin Sunseri [2009-02-10 14:53 -0000]:
> > Is Nick King smoking crack?
>
> /me waves with the Code of Conduct. Please be more respectful to other
> people!
>
> > This is a Ubuntu Linux bug tracker not Apple.
>
> Nevertheless this describes a problem of the mouse on an Apple laptop
> when running under Ubuntu, so it's very much on topic here.
>
> --
> Slim USB Apple Keyboard not working correctly when pressing the "numlock"
> key
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Mactel Support: In Progress
> Status in "linux" source package in Ubuntu: Fix Committed
> Status in linux in Ubuntu Hardy: Fix Released
>
> Bug description:
> I have the new Slim USB Apple Keyboard and in Hardy Heron (Beta) when I
> first boot up the alphabet keys work perfectly, but once I type in the
> numpad or a number, nothing happens. After nothing happens I'm not able to
> use my alpha keys, either.. When I type alphabet keys after trying a number
> the alphabet keys produce numbers like '4' and '3'.. And many of the keys
> don't do anything..
>
>
> I have tried setting the keyboard up as default, and as an Apple keyboard
> by going to System > Prefs > Keyboard -- but nothing works.
>
> If i then unplug the keyboard to reboot the keys usually work fine until I
> hit a number key or the keypad again.
>

I guess no one has a sense of humor anymore.

Sincerely

Justin Sunseri
Please don't print this e-mail unless you really need to.

> --
> Slim USB Apple Keyboard not working correctly when pressing the "numlock"
> key
> https://bugs.launchpad.net/bugs/201887
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I updated the Fn / F-keys directions here for Jaunty:
https://help.ubuntu.com/community/AppleKeyboard

It's essentially the same directions but the names of things changed in Jaunty.

change:
modprobe.d/* files should be *.conf now as later anything not *.conf will be ignored, though for now it just generates warnings but still works.

change:
instead of hid or usbhid, now it's hid_apple

change:
instead of pb_fnmode, now it's fnmode.

addition:
aside from rc.local and modprobe.d/<some file>, you may also use /etc/sysfs.conf

--
bkw

In Ubuntu Jaunty, the problem is fixed. The 'Clear' key behave like 'NumLock' key.
I test it with Apple Keyboard 0003:05AC:0220.0005

The original issue reported here has been confirmed to be resolved so I'm marking this from Fix Committed to Fix Released.

Hey guys...I'm seeing a very similar problem to this bug. I'm using karmic with latest updates on a 'regular' PC and an Apple bluetooth keyboard. This keyboard has no number pad at all and is very much like a laptop keyboard (which is what I select in the 'keyboard' preferences).

The symptoms are :

1) I can log in ok without having to do anything special, but
2) once logged in, it behaves as if the keyboard has been put into a number mode, so some of the letter keys actually produce numbers on the screen

Pressing fn-f6 twice fixes the problem, but I would like to avoid having to do this.

Any ideas?

Thanks,

Max.