unswap the grave and 102nd keys on Apple Alu ISO keyboard
PATCH 1/1 unswap the grave and 102nd keys on Apple Alu ISO keyboard
The quirk for swapping the grave and 102nd keys should be applied to the APPLE_ALU_ISO keyboard, as they aren't actually swapped.
--- drivers/hid/hid-apple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/hid-apple.c +1 -1
@@ -441,7 +441,7 @@ static const struct hid_device_id apple_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO), - .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),
Signature · 1 line
2.3.7
Quoted 13 lines · John Horan
The quirk for swapping the grave and 102nd keys should be applied to the
APPLE_ALU_ISOkeyboard, as they aren't actually swapped.Signed-off-by John Horan <[email protected]>--- drivers/hid/hid-apple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/hid/hid-apple.c +0
-0
drivers/hid/hid-apple.c static const struct hid_device_id apple_devices[] = { · line 447
Quoted 8 lines
drivers/hid/hid-apple.c +1
-1@@ -441,7 +441,7 @@ static const struct hid_device_id apple_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO), - .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),
Okay, this has been there since 2007, so one would guess there must be a reason for noone complaining about this for past 8 years. I'd rather be careful here so that we don't introduce any regressions.
Adding Michel, who added the original quirk back in 2007 (through commit a45d82d19a6 ("HID: Add support for Apple aluminum USB keyboards")) to CC.
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 28 lines · Jiri Kosina
Quoted 13 lines · John Horan
The quirk for swapping the grave and 102nd keys should be applied to the
APPLE_ALU_ISOkeyboard, as they aren't actually swapped.Signed-off-by John Horan <[email protected]>--- drivers/hid/hid-apple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/hid/hid-apple.c +0
-0drivers/hid/hid-apple.c static const struct hid_device_id apple_devices[] = { · line 447
Quoted 8 lines
drivers/hid/hid-apple.c +1
-1@@ -441,7 +441,7 @@ static const struct hid_device_id apple_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO), - .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),Okay, this has been there since 2007, so one would guess there must be a reason for noone complaining about this for past 8 years. I'd rather be careful here so that we don't introduce any regressions.
Quoted 2 lines
Adding Michel, who added the original quirk back in 2007 (through commit
a45d82d19a6("HID: Add support for Apple aluminum USB keyboards")) to CC.
Okay, the original e-mail address of Michel bounces, let's try a different one :)
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 30 lines · Jiri Kosina
Quoted 28 lines · Jiri Kosina
Quoted 13 lines · John Horan
The quirk for swapping the grave and 102nd keys should be applied to the
APPLE_ALU_ISOkeyboard, as they aren't actually swapped.Signed-off-by John Horan <[email protected]>--- drivers/hid/hid-apple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/hid/hid-apple.c +0
-0drivers/hid/hid-apple.c static const struct hid_device_id apple_devices[] = { · line 447
Quoted 8 lines
drivers/hid/hid-apple.c +1
-1@@ -441,7 +441,7 @@ static const struct hid_device_id apple_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO), - .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),Okay, this has been there since 2007, so one would guess there must be a reason for noone complaining about this for past 8 years. I'd rather be careful here so that we don't introduce any regressions.
Quoted 5 lines
Quoted 2 lines
Adding Michel, who added the original quirk back in 2007 (through commit
a45d82d19a6("HID: Add support for Apple aluminum USB keyboards")) to CC.Okay, the original e-mail address of Michel bounces, let's try a different one :)
Hmm, that bounced again. One last attempt ...
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 32 lines · Jiri Kosina
Quoted 30 lines · Jiri Kosina
Quoted 28 lines · Jiri Kosina
Quoted 13 lines · John Horan
The quirk for swapping the grave and 102nd keys should be applied to the
APPLE_ALU_ISOkeyboard, as they aren't actually swapped.Signed-off-by John Horan <[email protected]>--- drivers/hid/hid-apple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/hid/hid-apple.c +0
-0drivers/hid/hid-apple.c static const struct hid_device_id apple_devices[] = { · line 447
Quoted 8 lines
drivers/hid/hid-apple.c +1
-1@@ -441,7 +441,7 @@ static const struct hid_device_id apple_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO), - .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS), .driver_data = APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),Okay, this has been there since 2007, so one would guess there must be a reason for noone complaining about this for past 8 years. I'd rather be careful here so that we don't introduce any regressions.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Adding Michel, who added the original quirk back in 2007 (through commit
a45d82d19a6("HID: Add support for Apple aluminum USB keyboards")) to CC.
With my ISO Apple Aluminum keyboard:
Bus 006 Device 021: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)
writing 0 to /sys/module/hid_apple/parameters/iso_layout (which disables the APPLE_ISO_KEYBOARD quirk) results in the key right of the left shift key (labelled "" and "~") producing the wrong characters. With the quirk enabled, it produces "" and "~" as expected.
John, please provide more information about the problem you're trying to solve with this patch.
Quoted 4 lines
Quoted 2 lines
Okay, the original e-mail address of Michel bounces, let's try a different one :)
Hmm, that bounced again. One last attempt ...
Third time's the charm. :)
Signature · 7 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · John Horan
I have an Apple aluminum keyboard with the same usb product id, connected to an apple laptop, also with an ISO keyboard. According to xev the key with
printed on it on the external keyboard produces keycode 49 (which matches to §) while the internal keyboard produces 94 (which is mapped to), while the key with § produces the opposite.
What's the output of "xprop -root | grep XKB" for you?
What's the behaviour for you in console?
Quoted 2 lines
Obiviously just disabling the quirk isn't an option for me, as that would just flip the mapping of the two keys.
That assumes the ISO quirk is active for the internal keyboard as well. Have you double-checked that?
Signature · 6 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
[ Please keep the Cc list intact ]
Quoted 3 lines · John Horan
Quoted 1 line
What's the output of "xprop -root | grep XKB" for you?
_XKB_RULES_NAMES(STRING)= "evdev", "pc104", "gb,us", "mac,", "compose:rctrl"
I wonder if the reversed behaviour in X is due to the "mac," (variant?). Which keyboard model did you choose in the system / X keyboard configuration?
Quoted 4 lines
Quoted 1 line
What's the behaviour for you in console?
I'm using the American keymap in the console, so it prints backslash when I press the grave key on the internal keyboard, but the external keyboard is still swapped in relation to it (and actually outputs grave).
So it sounds like the ISO quirk is working correctly for the external keyboard, and there's actually a problem with the internal keyboard.
Quoted 3 lines
Quoted 2 lines
That assumes the ISO quirk is active for the internal keyboard as well. Have you double-checked that?
Yeah, and again just to be sure.
How did you check?
Signature · 6 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · John Horan
Quoted 2 lines
[ Please keep the Cc list intact ]
Appologies, and thanks for spotting that.
Quoted 3 lines
I wonder if the reversed behaviour in X is due to the "mac," (variant?). Which keyboard model did you choose in the system / X keyboard configuration?
I'm using the
English(UK,Macintosh)keymap. (and yes mac is the variant)
Apart from the two keys covered by the quirk, every other key matches
exactly to what is printed on the keys. Which keymap are you using?
I'm using the standard US (pc105) keymap.
Quoted 21 lines
Quoted 9 lines
What's the behaviour for you in console?
I'm using the American keymap in the console, so it prints backslash when I press the grave key on the internal keyboard, but the external keyboard is still swapped in relation to it (and actually outputs grave).
So it sounds like the ISO quirk is working correctly for the external keyboard, and there's actually a problem with the internal keyboard.
Actually I was mistaken there, I'm using the UK layout in the VC (I actually did try a mac-uk there before, but it was unusable, so I've left it as uk). Which is why I still think the problem lies with the external rather than internal keyboard, as the uk key layout would normally put the grave (paired with |) up next to the 1, which is what it does on the internal keyboard, which is then swapped down next to the z key on the external, and that just happens to be where apple puts the grave key.
Quoted 4 lines
That assumes the ISO quirk is active for the internal keyboard as well. Have you double-checked that?
Quoted 6 lines
Quoted 3 lines
Yeah, and again just to be sure.
How did you check?
As you did, I disabled the quirk by echoing 0 into
/sys/module/hid_apple/parameters/iso_layout. And that had an effect on both keyboards, rather than just the external.
I'm afraid I don't know how to sort out this mess, but I'm pretty sure removing the ISO quirk for just one ISO keyboard is not correct.
Signature · 6 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines
I'm using the standard US (pc105) keymap.
That explains it then. The pc105 keymap calls for the tilda and grave key to be placed next to the 1. So if I select the same layout on my macbook, then they end up in the correct place (according to the layout) on the internal keyboard. For the external keyboard the quirk is then mapping them down to next to the z key, which just happens to be where Apple puts them on their international keyboard (but not on their US ones). The pc105 keyboard is actually very close to the Apple ISO layout, apart from some of the special keys like £ and the placement of tilda and grave and the inclusion of a §± key next to 1.
Quoted 2 lines
I'm afraid I don't know how to sort out this mess, but I'm pretty sure removing the ISO quirk for just one ISO keyboard is not correct.
I'd actually argue that proves that the quirk shouldn't have been applied to this model of keyboard. I guess my main point is that there shouldn't be a discrepency between the internal and external keyboards. If you selected pc105 on a laptop with an iso keyboard, then the tilda key should be next to 1, and if you used a uk,mac layout with an apple iso keyboard then the tilda should be next to z.
-John
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines · John Horan
Quoted 2 lines
I'm using the standard US (pc105) keymap.
That explains it then. The pc105 keymap calls for the tilda and grave key to be placed next to the 1. So if I select the same layout on my macbook, then they end up in the correct place (according to the layout) on the internal keyboard. For the external keyboard the quirk is then mapping them down to next to the z key, which just happens to be where Apple puts them on their international keyboard (but not on their US ones). The pc105 keyboard is actually very close to the Apple ISO layout, apart from some of the special keys like £ and the placement of tilda and grave and the inclusion of a §± key next to 1.
Quoted 8 lines
Quoted 2 lines
I'm afraid I don't know how to sort out this mess, but I'm pretty sure removing the ISO quirk for just one ISO keyboard is not correct.
I'd actually argue that proves that the quirk shouldn't have been applied to this model of keyboard. I guess my main point is that there shouldn't be a discrepency between the internal and external keyboards. If you selected pc105 on a laptop with an iso keyboard, then the tilda key should be next to 1, and if you used a uk,mac layout with an apple iso keyboard then the tilda should be next to z.
It makes some sense, but OTOH it sounded like in console it's actually the external keyboard which is working correctly for you.
Also, my Apple keyboard isn't connected to an Apple machine but to an HP notebook. How do you suggest such a combination should be configured without the ISO quirk?
Finally, I still find it hard to believe that this issue would only affect this particular Apple ISO keyboard model.
Signature · 6 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
It makes some sense, but OTOH it sounded like in console it's actually the external keyboard which is working correctly for you.
I wouldn't say that. The external keyboard was wrong according to the keymap applied to it.
Quoted 3 lines
Also, my Apple keyboard isn't connected to an Apple machine but to an HP notebook. How do you suggest such a combination should be configured without the ISO quirk?
I'd imagine your HP notebook has an American keyboard. In your case my personal preference would be that the keymaps would match and when I press the button next to 1, tilda is printed regardless of the keyboard I'm using. If you prefer to use the keymap which matches the symbols printed on the keyboard, then I believe you can specify a per keyboard keymap using udev and setxkbmap. Though to be honest I think this would be a clunky solution, as setxkbmap seems to apply to X alone; I don't know if there is a better solution.
Quoted 2 lines
Finally, I still find it hard to believe that this issue would only affect this particular Apple ISO keyboard model.
I suspect it doesn't. In particular when googling for this I found a lot of people disabling the iso_layout quirk for the MacbookAir2013 models[1][2]. The ISO keyboard on my laptop definetly requires it, but I suspect the quirk has been applied more broadly that it should have been.
-John
[1]http://atodorov.org/blog/2015/04/30/fixing-tilde-and-function-keys-mapping-for-macbook-air-on-linux/ [2]https://bugzilla.redhat.com/show_bug.cgi?id=1025041#c2
Quoted 3 lines · Jiri Kosina
Okay, this has been there since 2007, so one would guess there must be a reason for noone complaining about this for past 8 years. I'd rather be careful here so that we don't introduce any regressions.
Just to follow up on this point specifically. I actually have been able to find a number of people complaining about this issue[1]. Including a patch that would have removed the quirk from this keyboard model, though aimed at a previous version of the code, that I guess was either not pushed upstream, or was rejected for some reason[2]. Looking at the code the only effect of the quirk is to swap these too keys, and googling for "iso_layout" and "hid_apple" shows that disabling this quirk is rather common advice for fixing apple keyboards, being mentioned on both the Ubuntu wiki[3] and the Arch one[4].
My issue I guess is that I have two keyboards using this module, one requiring the quirk, and another not.
[1]https://bugs.launchpad.net/ubuntu/+source/linux/+bug/214786 [2]https://launchpadlibrarian.net/13297091/0001-Remove-faulty-swapping-of-keys-for-Apple-USB-ISO-key.patch [3]https://help.ubuntu.com/community/AppleKeyboard#Correcting_swapped_keys_and_wrong_keymaps_for_international_.28non-US.29_keyboards [4]https://wiki.archlinux.org/index.php/Apple_Keyboard#.3C_and_.3E_have_changed_place_with_.5E_and_.C2.B0