[PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[John Horan]

The quirk for swapping the grave and 102nd keys should be applied to the 
APPLE_ALU_ISO keyboard, as they aren't actually swapped.

Signed-off-by: John Horan <knasher@gmail.com>
---
 drivers/hid/hid-apple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index f822fd2..e4bbfc0 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -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),
-- 
2.3.7

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Jiri Kosina]

On Fri, 1 May 2015, John Horan wrote:

> The quirk for swapping the grave and 102nd keys should be applied to the 
> APPLE_ALU_ISO keyboard, as they aren't actually swapped.
> 
> Signed-off-by: John Horan <knasher@gmail.com>
> ---
>  drivers/hid/hid-apple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index f822fd2..e4bbfc0 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -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.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Jiri Kosina]

On Mon, 4 May 2015, Jiri Kosina wrote:

> On Fri, 1 May 2015, John Horan wrote:
> 
> > The quirk for swapping the grave and 102nd keys should be applied to the 
> > APPLE_ALU_ISO keyboard, as they aren't actually swapped.
> > 
> > Signed-off-by: John Horan <knasher@gmail.com>
> > ---
> >  drivers/hid/hid-apple.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > index f822fd2..e4bbfc0 100644
> > --- a/drivers/hid/hid-apple.c
> > +++ b/drivers/hid/hid-apple.c
> > @@ -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.

Okay, the original e-mail address of Michel bounces, let's try a different 
one :)

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Jiri Kosina]

On Mon, 4 May 2015, Jiri Kosina wrote:

> On Mon, 4 May 2015, Jiri Kosina wrote:
> 
> > On Fri, 1 May 2015, John Horan wrote:
> > 
> > > The quirk for swapping the grave and 102nd keys should be applied to the 
> > > APPLE_ALU_ISO keyboard, as they aren't actually swapped.
> > > 
> > > Signed-off-by: John Horan <knasher@gmail.com>
> > > ---
> > >  drivers/hid/hid-apple.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > > index f822fd2..e4bbfc0 100644
> > > --- a/drivers/hid/hid-apple.c
> > > +++ b/drivers/hid/hid-apple.c
> > > @@ -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.
> 
> Okay, the original e-mail address of Michel bounces, let's try a different 
> one :)

Hmm, that bounced again. One last attempt ...

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Michel Dänzer]

On 04.05.2015 17:11, Jiri Kosina wrote:
> On Mon, 4 May 2015, Jiri Kosina wrote:
> 
>> On Mon, 4 May 2015, Jiri Kosina wrote:
>>
>>> On Fri, 1 May 2015, John Horan wrote:
>>>
>>>> The quirk for swapping the grave and 102nd keys should be applied to the 
>>>> APPLE_ALU_ISO keyboard, as they aren't actually swapped.
>>>>
>>>> Signed-off-by: John Horan <knasher@gmail.com>
>>>> ---
>>>>  drivers/hid/hid-apple.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
>>>> index f822fd2..e4bbfc0 100644
>>>> --- a/drivers/hid/hid-apple.c
>>>> +++ b/drivers/hid/hid-apple.c
>>>> @@ -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.

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.


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


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Michel Dänzer]

On 08.05.2015 19:03, John Horan wrote:
> 
> 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?


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


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Michel Dänzer]

[ Please keep the Cc list intact ]

On 11.05.2015 22:22, John Horan wrote:
>> 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?


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


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


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Michel Dänzer]

On 12.05.2015 18:55, John Horan wrote:
> 
>> [ Please keep the Cc list intact ]
> Appologies, and thanks for spotting that.
>> 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.


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


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[John Horan]

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

> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[Michel Dänzer]

On 12.05.2015 20:05, John Horan wrote:
> 
>> 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.
> 
>> 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.


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[John Horan]

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

Re: [PATCH] unswap the grave and 102nd keys on Apple Alu ISO keyboard

[John Horan]

On Mon, May 4, 2015 at 9:07 , Jiri Kosina <jkosina@suse.cz> wrote:
> 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