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

Bug #201887 reported by Brad Jensen on 2008-03-13
84
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mactel Support
Low
Unassigned
linux (Ubuntu)
Medium
Colin Ian King
Hardy
Medium
Colin Ian King

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.

description: updated
Brad Jensen (bradwjensen) wrote :

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.

Eric Johney (ericjohney) wrote :

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.

Eric Johney (ericjohney) wrote :

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!

Mario Limonciello (superm1) wrote :

Jean,

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

Mario Limonciello (superm1) wrote :

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.

Mario Limonciello (superm1) wrote :

Last comment,

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

Eric Johney (ericjohney) wrote :

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."

Brad Jensen (bradwjensen) wrote :

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>

Mario Limonciello (superm1) wrote :

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

Eric Johney (ericjohney) wrote :

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.

Eric Johney (ericjohney) wrote :

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

Brad Jensen (bradwjensen) wrote :

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.

Mario Limonciello (superm1) wrote :

>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.
"

Tommy Vestermark (tov) wrote :

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.

Mario Limonciello (superm1) wrote :

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.

  • hid.ko Edit (509.1 KiB, application/octet-stream)

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

Eric Johney (ericjohney) wrote :

here's the i386 kernel module also

Tommy Vestermark (tov) wrote :

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?

Tommy Vestermark (tov) 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 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...

description: updated
ChaseNeveu (chaseneveu-gmail) wrote :
Download full text (4.3 KiB)

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

Read more...

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.

ChaseNeveu (chaseneveu-gmail) wrote :

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.

Tommy Vestermark (tov) wrote :

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?!)

seanh (seanh) wrote :

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.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Confirmed → Triaged
muro (palomurin) wrote :

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.

muro (palomurin) wrote :

sorry, forgot to add:

4. run xmodmap ~/.xmodmap

it might be necessary to run this on startup

Tommy Vestermark (tov) wrote :

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.

Changed in linux:
assignee: ubuntu-kernel-team → colin-king
status: Triaged → In Progress
Changed in linux:
assignee: colin-king → nobody
status: In Progress → Triaged
Changed in linux:
assignee: nobody → colin-king
status: Triaged → In Progress
Changed in mactel-support:
status: New → Confirmed
Changed in linux:
status: In Progress → Fix Committed
Steve Langasek (vorlon) on 2008-07-17
Changed in linux:
assignee: nobody → colin-king
importance: Undecided → Medium
status: New → In Progress
Steve Langasek (vorlon) on 2008-07-17
Changed in linux:
status: In Progress → Fix Committed
56 comments hidden view all 136 comments
Ricky Campbell (cyberdork33) wrote :

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.

Changed in mactel-support:
status: Confirmed → In Progress

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.

alex (unabatedshagie) wrote :

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?

alex (unabatedshagie) wrote :

Ahhh, thanks.

There is a guide in there that solves the issue.

:D

Chris Collins (ccollins) wrote :

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.

Changed in mactel-support:
importance: Undecided → Low

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

larrycz (snzk) wrote :

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?

Ricky Campbell (cyberdork33) wrote :

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?

Steve Beattie (sbeattie) wrote :

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!

Brad Jensen (bradwjensen) wrote :

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.

Andrew Flegg (aflegg) wrote :

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')

Justin Sunseri (jmsunseri) wrote :

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.

Andrew Flegg (aflegg) wrote :

> 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

Jens Bremmekamp (nem75) wrote :

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.

Martin Pitt (pitti) wrote :

linux 2.6.24-21 copied to hardy-updates.

Changed in linux:
status: Fix Committed → Fix Released
shawnlandden (shawnlandden) wrote :

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)

creatifx (bobwaycott) wrote :

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 . . . ) ;)

shawnlandden (shawnlandden) wrote :

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

creatifx (bobwaycott) wrote :

@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).

shawnlandden (shawnlandden) wrote :

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?

shawnlandden (shawnlandden) wrote :

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.

creatifx (bobwaycott) wrote :

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

shawnlandden (shawnlandden) wrote :

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)

creatifx (bobwaycott) wrote :

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

creatifx (bobwaycott) wrote :

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)

nick king (nick-king-macys) 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.

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

nick king (nick-king-macys) wrote :

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

Justin Sunseri (jmsunseri) wrote :

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

KEYofR (brian-aljex) wrote :

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

ikus060 (ikus060) wrote :

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.

Changed in linux (Ubuntu):
status: Fix Committed → 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.

Changed in mactel-support:
status: In Progress → Fix Released
Displaying first 40 and last 40 comments. View all 136 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers