Apple USB ISO keyboard has incorrectly swapped keys

Yes, this i really annoying, another thing is that it's impossible for me to do a left curly bracket with this keyboard (with swedish layotut and the most recent ubuntu kernels, not sure about the older ones as i haven't tried), right alt + 7 gives me a "|" character instead of "{", on the other hand, right alt + 0 gives me a "}" as it's supposed to.

My bad. The second problem was gnome-related and easily fixed in the keyboard options.

Hi Eric,

Just be sure, you also agree on the first issue?

On the danish layout the "<" key is next to the left shift key and the "½" is above the the TAB key. (Actually the "½" key has a "$" sign on the Apple keyboard, but "½" on a regular danish keyboard). Is this the same on the swedish keyboard?

Yes, I agree on the first issue, the buttons are placed the same on a Swedish layout and they're switched for me too. However, normal (Windows) behaviour on a Swedish keyboard is to display a "§" sign on a normal key press and "½" when using shift, I'm not sure how it's usually handled in Linux though.

Same issue here with lastest Apple keyboard and spanish layout.

The "<" key is next to the left shift key and the "º" key above tab key.

I have test another keys, but it seems only "<" and "º" keys are swapped.

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

This option fixes the problem for my keyboard too.

Thanks for the tip :)

Can anyone confirm or deny that this bug also applies for the Wireless Apple Keyboard?

For those who aren't using gnome the following may help. Add apple:badmap option to the "XkbOptions" in the "InputDevice" section in your xorg.conf. The section should look like:

Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "apple"
    Option "XkbLayout" "us,ru"
    Option "XkbVariant" ",winkeys"
    Option "XkbOptions" "grp:shift_caps_toggle,apple:badmap"
EndSection

This should swap problematic keys under X. If it doesn't help one can try adding apple:goodmap instead.

I have had the same problem with the Italian Apple keyboard connected to a Macbook laptop: "|\" key (above Tab) swapped with "<>" (right of shift).
This is solved in gnome by switching on "Swap keycodes of two keys when Mac keyboards are misdetected by kernel", but in that case it is the keyboard on the laptop that does not work correctly. Is there a way to avoid switching the option on and off whenever I change from one keyboard to the other?

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

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

--or--

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

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

So I entered the Interpid Ibex Test Phase and I still see problems with the apple aluminum keyboard (USB).
I have the German version of the keyboard connected to a MacPro running latest 2.6.27 kernel image of today: 2.6.27-2-generic

First: One issue I previously had is gone which was that Mouse and Keyboard input at once didn't work (Quite anoying in games to not be able to use mouse and keyboard). That works now.

However the Issue with bad mapping of keys remains. I thought the fix should have been in 2.6.27 already, but it doesn't seem that way. <>| (which should be right to the left shift key) are still mapped to the ^ key (above tab).

i can confirm, that this is not fixed by a 2.6.27 kernel (tested with images prior and including linux-image-generic-2.6.27-3-generic version 2.6.27-3.4).
(for me it is a spanish apple keyboard (with us-layout))

A recent update (2 days ago ?) on Hardy Heron switched the corresponding two keys of my MacBook laptop, probably to correct the slim aluminum keyboard. I cannot test the latter since I'm currently abroad.

Cannot test hardy anymore, but with up to date Intrepid Ibex I still have the problem of the swapped keys.

To complete my above comment : Now, the aluminum keyboard is correct, but not the Macbook keyboard, and the situation is of course reversed, if I tick the corresponding option in gnome's keyboard configuration. Since I use both keyboard on the same computer, it's annoying...

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

Hi,

I'm trying to keep track of the remaining issue for Apple keyboard. May anybody test if the problem remain in Jaunty Beta 1 without changing any configuration in gnome.

Thanks.

Hi,

I am currently running Jaunty and the problem still occurs :(
Plus it is not possible anymore to select the option in the keyboard interface so I'm stuck with the bug.

Hello,

I confirm this bug exists on Jaunty RC and there is no option to swap keycodes.

To people having this problem.
May you confirm that applying the patch fix the problem ?

Thanks

Hello,
I'm using ubuntu jaunty 9.04 and I have this bug (which was solved in 8.10 by the "Swap keycodes of two keys when Mac keyboards are misdetected by kernel" option).
@ikus060
I don't really now how to test the patch. Could you tell me ?

Thanks

I confirm this issue on jaunty 9.04 with the French Wired Aluminum Keyboard. The ù (on the z's left) and / (on the 1's left) keys are inverted. I check for Vladimir Krasovsky's solution, but the update-manager comment out the keyboard and mouse input, saying that "Hal is now used".

I confirm too this. I'm using ubuntu 9.04 RC with spanish wired apple aluminum keyboard.

I have the same problem. Ubuntu 9.04 with Italian wired apple aluminium keyboard.

I've same problem on french MacBook on Ubuntu 9.04

Can confirm the problem exists in 9.04 on german wired aluminium keyboard. Sadly the option in the keyboard setup disapeared.

Same problem here, updated to 9.04. Option in system settings is gone and cannot be applied anymore by setxkbmap -option apple:badmap. Vewwwy smart.

ikus060: what patch are you talking about?

Confirmed on Ubuntu 9.04 with Danish alu keyboard.

You can work around it by issuing the command:
xmodmap -e 'keycode 94=onehalf section' -e 'keycode 49=less greater backslash brokenbar backslash brokenbar'

or follow the guide at https://help.ubuntu.com/community/AppleKeyboard to add it upon startup.

Confirmed on Ubuntu 9.04 with French Aluminium keyboard (AZERTY layout).

The work-around here is :

xmodmap -e 'keycode 94=at numbersign periodcentered Ydiaeresis' -e 'keycode 49=less greater VoidSymbol VoidSymbol'

for spanish layout:

xmodmap -e 'keycode 94=masculine ordfeminine backslash brokenbar backslash brokenbar' -e 'keycode 49=less greater'

Confirmed on Ubuntu 9.04, Macbook 2,1, International English keyboard.
on the default jaunty kernel and kernel 2.6.30-rc2

Workaround for this one is:
xmodmap -e 'keycode 94=grave asciitilde grave asciitilde dead_grave dead_horn' -e 'keycode 49=section plusminus section plusminus section plusminus'

for italian layout:

xmodmap -e 'keycode 94=backslash brokenbar' -e 'keycode 49=less greater'

Anyone looking for a workaround not posted here: you can check your current keysyms with

xmodmap -pke

Then just switch the keysyms for kexcode 94 and 49 like so:

(Workaround for german layout:)

xmodmap -e 'keycode 49 = less greater Cyrillic_softsign Cyrillic_SOFTSIGN bar brokenbar' -e 'keycode 94 = dead_circumflex degree parenleftparenright U2032 U2033'

Hi,

I'm using the german version of the Apple USB keyboard (aluminium) and had the same problem with the swapped to keys. To solve the problem once and forever, i made a small kernel patch which disables the ISO layout completely. The patch adds a new option (iso_layout) in the driver "hid-apple.ko" (Just like the fnmode option). The default value is "ISO layout enabled" (Just like before). When you set the option to zero the ISO layout gets disabled and the swapped keys are disappearing (At least for my keyboard).

The patch is for kernel version 2.6.30, but should work with every other kernel version.

Confirmed on Ubuntu 9.04, Macbook 2,1, International English keyboard.
on portuguese-brazilian layout and kernel 2.6.30-generic

Workaround using /usr/local/bin/keyboard as attached file.

[This is an automated message. Apologies if it has reached you inappropriately.]

This bug was flagged as having a patch attached. The Ubuntu Kernel Team's preferred policy is for all patches to be submitted and accepted into the upstream kernel before agreeing to merge them into the Ubuntu kernel. The goal for the Ubuntu kernel is to have little to no divergence from the upstream linux kernel source.

https://wiki.ubuntu.com/KernelTeam/KernelPatches has been written to document the suggested policy and procedures for helping get a patch merged upstream and subsequently into the Ubuntu kernel. Please take the time to review that wiki if this patch should be considered for inclusion into the upstream and Ubuntu kernel. Let us know if you have any questions or need any help via the Ubuntu Kernel Team mailing list. Thanks in advance.

Just to confirm: this bug still occurs under the current Karmic alpha 4 release.

The xmodmap workaround does work somewhat. But as an attached USB keyboard works properly while the MacBook keyboard has the 2 keys switched, so the behavior is inconsistent. Therefore the "workaround" is unsatisfactory.

Clarification (I did read the above comments but not close enough apparently). An attache apple USB keyboard works correctly, while the internal Apple Macbook (4,1) keys are switched in Karmic Alpha4

This issue is still relevant for Ubuntu Karmic, i could fix the mixup on a german keyboard with

$ xmodmap -e 'keycode 49 = less greater less greater bar brokenbar bar' -e 'keycode 94 = dead_circumflex degree dead_circumflex degree U2032 U2033 U2032'

Confirmed on(K)Ubuntu 9.10 karmic, MacBookPro5.1, international US keyboard.
As suggested at #33, the following command solves the issue, at least for the internal keyboard.

$ xmodmap -e 'keycode 94=grave asciitilde grave asciitilde dead_grave dead_horn' -e 'keycode 49=section plusminus section plusminus section plusminus'

The following works using a Swedish Apple Aluminium keyboard:
xmodmap -e 'keycode 94=degree section' -e 'keycode 49=less greater bar brokenbar bar brokenbar'

Tested using Ubuntu Linux 9.10

I started a discussion thread about this subject here:

http://ubuntuforums.org/showthread.php?p=8320777

It is also a topic in the MacBook4.1 wiki for Karmic:
https://help.ubuntu.com/community/MacBook4-1/Karmic#Swapped keys

The subsection still needs to completed, maybe somebody can have a look at it, thx!

There's at least one keyboard device that seems to be used in MacBook4,1, that isn't flagged as APPLE_ISO_KEYBOARD in drivers/hid/hid-apple.c (checked with recent karmic kernel sources):

        { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO),
                .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },

Hence, the kernel will not swap these 2 keycodes, incorrectly (in contrast to the USB HID specification) reported by the device.

Forgot to mention, that USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO is 0x022a, and we checked that this device is actually present on this machine (see http://ubuntuforums.org/showthread.php?p=8336027#post8336027).

Hi,

My patch mentioned above is now included in kernel version 2.6.34-rc1 :

http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Ftesting%2Fpatch-2.6.34-rc1.bz2;z=2357

The patch applies cleanly to the Lucid-kernel.

I would be nice if someone would backport the patch to the Lucid-kernel. It solves the problem completely. You only have to add the following line to the file "/etc/modprobe.d/options.conf" :

options hid-apple iso_layout=0

The option disables the card-coded ISO-layout.

I'm seeing the greater/lesser key swapped with the circumflex/degree key on my German USB Apple Aluminium Keyboard (ID 05ac:0221 Apple, Inc. Keyboard (Aluminium) (ISO)) connected to a MacBookPro5,3 on Ubuntu 10.04, 2.6.32-24.42-generic-pae 2.6.32.15+drm33.5. The internal keyboard works as expected. The suggested workaround:

xmodmap -e 'keycode 49 = less greater less greater bar brokenbar bar' -e 'keycode 94 = dead_circumflex degree dead_circumflex degree U2032 U2033 U2032'

works, but after that, the keys on the internal keyboard are swapped while the external keyboard is working as expected.

If anyone having this problem with Apple Turkish Q keyboard ;
Create a file named .Xmodmap under your home folder and paste the following lines ;

keycode 49 = less greater less greater bar brokenbar
keycode 94 = quotedbl eacute quotedbl eacute less degree

Save and voila! Tested on Mac Book Internal Keyboard, Mac Book with Aluminium Keyboard and Aluminium Keyboard on iMac under Ubuntu 10.04

This problem remains unfixed in Maverick (beta).

I also tried the option mentioned in comment #47, but it doesn't seem to do anything (no, I didn't forget to update-initramfs and reboot). I guess it hasn't made into recent kernels after all. Stefan's kernel.org diff link should provide more information, but unfortunately it's invalid.

The only good news is that the xmodmap workarounds are still working for Maverick -- up to a point, as the mods (a) will be lost after resuming from suspend (and at random other times), (b) do not apply within virtual machines, (c) have to be set up manually for each user, and thus (d) are becoming ever more of a nuisance after all those years.

Hi,

> I guess it hasn't made into recent kernels after all. Stefan's kernel.org diff link should provide more information, but unfortunately it's invalid.

My patch is included in Linux since version 2.6.34. It is also included in 2.6.35 and 2.6.35. The source file with the patch is located under "drivers/hid/hid-apple.c" in the source-code directory (e.g. "/usr/src/linux-2.6.35.4").

Normally the option should normally included in the Maverick-version of the kernel-module "hid-apple.ko". The command "modinfo hid-apple" should clarify this :

> parm: iso_layout:Enable/Disable hardcoded ISO-layout of the keyboard. (0 = disabled, [1] = enabled) (uint)

Stefan, thanks for looking into this. You're right, the iso_layout option is in the Maverick kernel. However I can't get it to work. Here's what I've been trying as a minimal case:

1) Open terminal, disable hid-apple module by entering:

sudo rmmod hid-apple

Obviously this will cause the MacBook's keyboard to stop working, so an external USB keyboard is needed for the next step.

2) Re-enable hid-apple by entering:

sudo modprobe hid-apple iso_layout=0 fnmode=2

After that the internal keyboard works again, fnmode=2 is honored (i.e. F1 will produce just that, without having to hold down Fn), but iso_layout is not (i.e., ^ and < are swapped as before on a German keyboard).

Any ideas what I might be doing wrong?

I confirm too, this bug exists on Maverick and there is no option to swap keycodes fix.

Workaround for Turkish layout:
xmodmap -e 'keycode 49 = less greater less greater bar brokenbar' -e 'keycode 94 = quotedbl eacute quotedbl eacute less degree'

On the French aluminium keyboard, it swaps @ and <

The fixes here appear to be incorporated upstream. Moving the development task Fix Released.

I still have the bug with the French aluminium keyboard in 10.10, it swaps @ and <.

I've temporary worked it around with :
sudo -s
echo 0 > /sys/module/hid_apple/parameters/iso_layo

@netangel : Your workaround does not workk when the file /sys/module/hid_apple/parameters/iso_layo does not exist, as on my macbook 4.1 with ubuntu 10.10

@Frédéric Grosshans: Petty sure he/she meant "/sys/module/hid_apple/parameters/iso_layout" with a "t".

I can confirm that netangel's workaround works with a danish aluminium keyboard in 10.10.

@netangel
Thanks, your workaround looks cleaner than using xmodmap.
Here is a single line version :
echo 0 | sudo tee /sys/module/hid_apple/parameters/iso_layout

For the record, that is with a French aluminium keyboard in 10.10.

@Hans Duedal : I'm ashamed to confess that removing the typo solves the problem for the (French) aluminium keyboard :-)

However, the key stays swapped on the laptop's keyboard :-(

@p2k: I confirm the workaround works for me as well on 10.10 for the Belgian aluminium keyboard (same layout as the French keyboard).

It now works out of the box in unity, at least for me :-)

Not for me. Still having the same issues with the French aluminium keyboard for @ and < which are swapped.

famille@famille:~$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "fr", "oss", ""
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "fr", "oss", ""
famille@famille:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 model = applealu_iso
 layouts = []
 options = []
famille@famille:~$ su

Moreover, i can't install xkeyboard-config

@Pierre : I guess you haven't specified that you layout is the Mac layout ("France Macintosh") in the keyboard layout configuration. If I use the same commands as you, I have different output ( and my keyboard works properly) :

fred@sanduleak2:~$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "fr", "mac", ""
_XKB_RULES_NAMES(STRING) = "evdev", "apple", "fr", "mac", "grp:alts_toggle,numpad:mac,apple:badmap,compose:lwin"
fred@sanduleak2:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 options = [grp grp:alts_toggle,compat numpad:mac,compat apple:badmap,Compose key compose:lwin]
 layouts = [fr mac]
 model = apple

Precision on comment #63 : The bug is not solved in the tty. But every thing works fine in unity. Is that a different bug needing a new entry in Launchpad ?

Same workaround needed for Oneiric.
Also needed to reconfigure the "fn" key mode (https://help.ubuntu.com/community/AppleKeyboard).

Volatile fix:

echo 0 | sudo tee /sys/module/hid_apple/parameters/iso_layout
echo 2 | sudo tee /sys/module/hid_apple/parameters/fnmode

Persistent fix:

echo options hid_apple iso_layout=0 fnmode=2 | sudo tee -a /etc/modprobe.d/hid_apple.conf

The same of pdecat on Pangolin (keys <> and \| swapped, inversed "fn" key mode)

Before I speculate on more details about this problem, let me add that pdecat's persistent fix works fine but requires an additional `update-initramfs -u -k all` for the option to be set correctly.

I own two Apple aluminium keyboards of different generations (German layout) , one MacBook Air and one old Early-2008 white MacBook. While the laptops seem to work fine for quite some time now, both alu keyboards experienced this issue in different Ubuntu releases; at least one of them always suffers from it up until today. (Count this as confirmed for Quantal.)

In the past, I used the xmodmap fix from above, but that didn't work out now because of Bug #1016996. Since I didn't know about pdecat's fix at first, I dived a bit into the shady areas of XKB configuration and found out that XKB offers options called "apple:badmap" and 'apple:goodmap' targeting the exact same problem. Those are listed in "/usr/share/X11/xkb/rules/base" and `[…]/evdev`, but not in the respective `.lst` and `.xml` files and therefore don't show up in the GNOME keyboard options dialog.
When it comes to persisent configuration, I didn't succeed in settings the options via `xorg.conf` as described by [1] and [2]. Running `setxkbmap […]` at session start through `gnome-session-properties` works in principal, but seems to conflict with settings from the GNOME keyboard options. (Only one of them will be set due to what seems to be some kind of race-condition.) What worked for me was running the command via `.profile`, but just then I came across pdecat's much simpler and system-wide approach :-).

As there seem to be different generations of Apple keyboards with different behaviours out there, I believe that there won't be a general fix for this problem.
What should however be done in my opinion, is offering a simple way to get the right configuration. I think the GNOME keyboard options are the right place to do that, and therefore the "apple:badmap" option should be added to the `.lst` and `.xml` files like described above. That's why I'm adding xkeyboard-config to the affected packages.

[1] http://wiki.debian.org/MacBook#X11_.28X_Window.29
[2] https://wiki.archlinux.org/index.php/Apple_Keyboard#.3C_and_.3E_have_changed_place_with_.C2.A7_and_.C2.BD

Status changed to 'Confirmed' because the bug affects multiple users.

I'm affected by this problem as well, but the hid_apple fix didn't work for me

this is weird, since I'm using the hid_apple.conf already to use the special keys as default:

> cat /etc/modprobe.d/hid_apple.conf
options hid_apple iso_layout=0 fnmode=1

I tried all of the 3 alternatives that have been written here:
http://wiki.debian.org/InstallingDebianOn/Apple/PageFragmentKeyboard

but not even setting it from GRUB is working

I cannot use the xmodmap setting for a different reason, it seems that I'm affected by this bug:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/289781

the weird thing is that I don't have the evdev module loaded (I guess that the keyboard driver is supplied through usbhid or something like that), so for now I'm refraining to set that bug back to confirmed

I also tried to use this file for startup:

> cat .config/autostart/xmodmap.desktop
[Desktop Entry]
Type=Application
Exec=xmodmap -e "keycode 49 = 0x3c 0x3e" -e "keycode 94 = 0x5c 0x7c"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=false
Name=remap < and \
Comment=

but it doesn't work (it's for the italian layout if you need it)

If I remember correctly, some time ago I also tried to put a script in /etc/acpi/resume.sh (now probably it should go into /etc/pm/sleep.d/ ) to no avail

and finally, sebastien bacher suggested me to use a gnome-settings-daemon hook:
http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=2ec0fbd38cd9d787fc3ad003f462c537ea795890

I wrote this small script

#! /usr/bin/env python3

import argparse
from subprocess import check_call as call
from os.path import expanduser

parser = argparse.ArgumentParser()
parser.add_argument('-t')
parser.add_argument('-i')
parser.add_argument('name')
args = parser.parse_args()

if __name__ == '__main__':
    try:
        if args.t in ("added", "present") and args.i == "10":
            call(["xmodmap", expanduser("~/.Xmodmap")])

#EOF
(I also added some error checking when debugging it, and 10 is the XID obtained from xinput)

and I added it to g-s-d with

gsettings set org.gnome.settings-daemon.peripherals.input-devices hotplug-command '/path/to/mac_keyboard_fix.py'

but apparently, gnome-settings-daemon receives a device-added signal, only for device #11(touchpad) and #14(unknown)

(so, this seems to be denying the hypothesis that the problem is due to the driver loading the keyboard as a completely different keyboard)

right now, I'm not sure why, but when doing a suspend/resume, if I previously applied the xmodmap, the change retains... but in the meanwhile I removed the python script, deactivated the .desktop startup item, and nothing else should be able to change the behaviour after-resume without also changing it after bootup, so I'm quite baffled

I get fed up by this issue every few months, and I try to find a workaround that works once and for all (unless something makes the xmodmap script working, that is)... but now I've spent too much time on this, I just hope that something/somebody will improve the situation in the next months

(when removing the obsolete error checking from the python script, I forgot to remove the try, statement... if you use it and get a syntax error, that's why)

Since the last comment on this is before 13.04, I'll just add that this exact issue still remains on a fresh install of Raring. pdecat's workaround
  echo 0 | sudo tee /sys/module/hid_apple/parameters/iso_layout
works.

Newby at stage! Can you kindly tell me exactly what i have to do to fix this problem? Thank you

@joao-pimentel-ferreira read the previous comment (#73)

Error still present in 15.10

Error still present in 18.04 (German Apple wired USB keyboard)

Hi guys, this problem is still present in Ubuntu 18.04, Portugese Apple wired USB keyboard.

I have an italian apple keyboard and I confirm that the bug where keys <> and \| are switched is still present.

The command for a volatile fix

echo 0 | sudo tee /sys/module/hid_apple/parameters/iso_layout

and for a permanent solution

echo options hid_apple iso_layout=0 | sudo tee -a /etc/modprobe.d/hid_apple.conf

that are mentioned above fix the issue for me.

I'm currently having this issue on a portuguese (european) apple keyboard. The wireless kind used in iMac.

I have two keys swapped. The key < > prints ` and ~

Was working fine previously, not sure what changed.

I'm having this issue with a Spanish USB Mac keyboard. Is it really so difficult to detect when you have a Mac keyboard connected and/or disconnected? Can't anything be done with hotplug, udev, etc. ?

After posting, I tried
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/214786/comments/78
and it worked for me on a Spanish USB apple keyboard.

Currently I have my laptop's and the USB Apple keyboard working correctly _and_ simultaneously

Just my .2 cents