keylayout output is invalid: breaks macos conventions and angle-mod

[thblt]

Keylayout output with angle mod swaps the leftmost key of the numeric row with the key next to the left shift. In the above image (screenshot from ukulele showing the angle-modded ergol layout), the Z on row 2, column 1 should be swapped with the backtick on column 2 of row 4.

[fabi1cazenave]

It’s an old story: some Mac keyboards swap the Grave and ISO keys physically, and so far no macOS user has ever provided any patch or explanation for that.

It’s unclear to me why this affects only some keyboards but not others.
Or maybe there’s a setting on the OS side (= Mac keyboard vs standard ISO keyboard), but I’m not using macOS so I don’t know.

Would you mind giving a bit more info?

• What exact keyboard model are you using here?
• How does it behave with an external ISO keyboard?

[fabi1cazenave]

Likely a duplicate of #210

[fabi1cazenave]

Silly question: is the non-angle-mod output valid for your keyboard?

[thblt]

I was going to check this. I’ll do a few tests with a few different keyboards and report. 

[fabi1cazenave]

Thanks, that’s very appreciated.

[thblt]

Far from a complete test, but indeed the issue seems unrelated to --angle-mod: the regular ergol layout swaps those same two keys.

A bit of context. AFAIU, all Apple keyboards swap those two keys (because Macs are not IBM PCs. The OS compensates for this with the keyboard identification dialog, that allows it to use regular PC keyboards as well as third-party mac keyboards without issue.

(This causes issues with programs such as kanata, probably because the karabiner kernel extension kanata uses hijack this mechanism. But for a layout it shouldn’t be an issue.)

IMO the solution is probably just to swap the two corresponding codes in the keylayout exporter. I’ll check the code and see if I can locate the corresponding part

[thblt]

Untested yet, but this seems to work. main...thblt:kalamine:main

[thblt]

A bit of context. AFAIU, all Apple keyboards swap those two keys ...

Self-correction: If Ukelele is correct, it’s actually a bit trickier. The swap only happens in Apple ISO keyboards.

This is the base Apple AZERTY rendered by Ukelele on first an ISO, then an ANSI keyboard.

For Ergol, this means that with my patch applied, the position of the <> key will change on an ANSI keyboard, which seems to me to be a reasonable compromise --- especially at this is how stock layouts behave on mac

[fabi1cazenave]

The swap only happens in Apple ISO keyboards.

I’m not sure ISO is the proper term here.

• What’s the exact name of Apple’s Qwerty-intl keyboard, which I know swaps the TLDE and LSGT key (= xkb names)?
• What’s the exact name of Apple’s Azerty keyboard?
• What happens if you connect a non-Apple ISO keyboard?

The latter is the only one I’d call an ISO keyboard. I would be surprised (or very disappointed) if those Apple keebs with two swapped keys qualified as ISO. Using sharp terms would be a good first step. :-)

[fabi1cazenave]

For Ergol, this means that with my patch applied, the position of the <> key will change on an ANSI keyboard, which seems to me to be a reasonable compromise --- especially at this is how stock layouts behave on mac

That might be an acceptable compromise for Ergol, but it wouldn’t for other layouts (e.g. Bépo). The goal is is to fix this once and for all, not to keep working around it.

I’d really like to know what happens if a real ISO keyboard is connected to a Mac.

Does the Bépo keylayout have the same issue?

[thblt]

• What’s the exact name of Apple’s Qwerty-intl keyboard, which I know swaps the TLDE and LSGT key (= xkb names)?
• What’s the exact name of Apple’s Azerty keyboard?

What do you mean by name? They have Apple product codes and USB vendor/product IDs, but I doubt they have anything beyond their commercial names. Specifically, I don't think there's a common name for all instances of a given physical layout/marking across various product lines.

What happens if you connect a non-Apple ISO keyboard?

They behave exactly the same as an Apple keyboard with the same physical layout (ISO or ISO-ish). I tried that with a Dell ISO keyboard I had at hand: macOS compensates for the scancode peculiarities (the same way the Linux kernel does when it sees Apple keyboards)

[thblt]

The goal is is to fix this once and for all, not to keep working around it.

I'm afraid this is an intrinsic property of the way macOS handles the various physical layout it knows.

Does the Bépo keylayout have the same issue?

I can check later; but AFAICT even Apple stock layouts behave this way (the backtick "moves" to the ISO key if the keyboard has it instead of the ISO key being a new, distinct code)

(Late edit: fwiw, optimot solves this by distributing two separate implementations, labelled ANSI and ISO)

[thblt]

After a few more tests:

• There is no observable difference in behavior on macos between (1) the internal macbook keyboard, (2) an apple "alu" external keyboard, and (3) a regular 105-key external PC keyboard. All those keyboards have an ISO(-ish) physical layout, with the extra key between LSHIFT and AZERTY w. The OS obviously normalizes scancodes between the different keyboard types.
• Keyboard hardware is thus irrelevant to this issue.
• The root cause is the way macos handles ISO vs ANSI keyboards, specifically by assigning the same normalized keycode to keys in different locations.

This means that AFAICT there are four (partial) solutions on kalamine’s side:

1. Produce keylayouts that are a perfect match with the input TOML on ANSI keyboards, but are partially invalid on ISO keyboards without angle-mod, and unusable with angle-mod (this is the current state)
2. Target ANSI as the preferred geometry, like 1, but fix angle mod output specifically.
3. Or have correct output on ISO keyboards, and working angle mod; at the cost of a minor (IMHO) difference on ANSI keybs (this is what Fix Apple scan codes (closes #210, #229) #236 does)
4. Produce two separate .keylayout for ISO and ANSI keyboards, like optimot does. This puts the burden of managing keyboard types on the user.