Keymap problem (two keys switched)

[freeeaks (freeaks)]

my keymap has two keys being wrong. the key that should do “< >” is wrongly mapped to the key that should do “@ #”.

would someone know what particular file i should edit ?
environment is fedora39, kde, wayland.

in kde settings the keymap is set like this:
map: fr
layout: french
variant: french (macintosh)

but i don’t know what file (or files) that setting points to.
i tried to tweak these files:

/usr/share/X11/xkb/symbols/macintosh_vndr/fr
/usr/share/X11/xkb/symbols/pc

it seemed to me the related keys were these ones:

key <LSGT> {[  less, greater, bar, brokenbar  ]};
key <TLDE> {[ at, numbersign, periodcentered, Ydiaeresis ]};

but i were unable to find a solution.

[jasoneckert]

This seems to have been solved here: Swapped keys on Macbook pro (French Macintosh keyboard, keys <> and @#)

[freeeaks (freeaks)]

i assumed wrongly that this wouldn’t have been asked before, sorry about that. it worked, many thanks for the heads up.

[marcan (Hector Martin)]

Note that this is technically a keymap issue and should be fixed in the xkb configs; the module argument thing is a stupid workaround. We still need to do a big round of fixing xkb snafus on Macs…

What exact machine is this, and what physical keyboard layout?

[freeeaks (freeaks)]

it is good to hear it is planned to do a round of fixing regarding those issues. the laptop is a macbookpro 2023, 14", m2pro. the physical layout is more or less the same for all french macbook it’s azerty. i attach a picture.

the layout preview in kde is mostly right (and it does show the keys “@ #” and “< >” at their proper position, despite that in actual use they are inversed). minus the numeric pad that is not present on macbooks.

the module argument workaround works but only for session.
this works:
$ sudo echo 1 | sudo tee /sys/module/hid_apple/parameters/iso_layout

but this does not:
$ sudo echo options hid_apple iso_layout=1 | sudo tee -a /etc/modprobe.d/hid_apple.conf
(after a reboot, i’m back with inversed keys)

[marcan (Hector Martin)]

That’s interesting, it should already work. Can you run this and paste the output?

grep . /sys/devices/platform/soc/*/*/*/country                
hexdump /proc/device-tree/soc/*/*/keyboard/hid-country-code
hexdump /proc/device-tree/chosen/asahi,kblang-code 

[freeeaks (freeaks)]

sure, here it is:

 $ grep . /sys/devices/platform/soc/*/*/*/country     
/sys/devices/platform/soc/2a9b14000.fifo/2a9b30000.input/0019:0000:0000.0001/country:00
/sys/devices/platform/soc/2a9b14000.fifo/2a9b30000.input/0019:05AC:0352.0002/country:00
/sys/devices/platform/soc/2a9b14000.fifo/2a9b30000.input/0019:05AC:0352.0003/country:00

 $ hexdump /proc/device-tree/soc/*/*/keyboard/hid-country-code
0000000 0000 0000                              
0000004

 $ hexdump /proc/device-tree/chosen/asahi,kblang-code 
0000000 0000 0200                              
0000004

[marcan (Hector Martin)]

Oh fun, we’re missing a bunch of keyboard aliases in the device tree… I’ll fix it.

Thanks for reporting this

[freeeaks (freeaks)]

very good to hear

also, since we’re on the keyboard problems, here, look at what happens in tty:

you see the 2nd line ? all the char trashing, it happens when i do combo keypresses, to input some character or to peform some action. here i wanted to switch back to wayland, and that was not possible that time, instead i got keyboard trashed. when this happens, i mash the keyboard a bit here and there, and somehow it progressively got back into working state on its own, after something like 30seconds.

*typo on the screenshot: strangle → strangely

another keyboard problem, at install time, in graphical setup/ final install steps, i did choose a keymap, but it was not applied. it could be dangerous because if user doesn’t test and notice there was a problem in applying keymap, at next step he choose complex password, and once he reboots he will not be able to open session since the password he thought he entered is not the same as the password he actualy entered (because keymap differences).

[marcan (Hector Martin)]

That TTY problem looks like a stuck AltGr modifier. I bet it has something to do with something along the way trying to interpret “Ctrl+Alt” as AltGr but then getting stuck like that. Probably an upstream bug?

The keymap thing is weird, it’s supposed to work. I’ll test again. There’s been a bunch of weird corner cases with the calamares stuff…

[freeeaks (freeaks)]

for what it’s worth, i have an old intel macbookpro from 2015 here. (i made it a linux, single os, removed macos a long time ago on it). the keyboard is very similar, and i haven’t encountered such a problem with it on tty. this sudden char trashing, lasting around half a minute, then getting back to normal on its own. i think it’s an asahi original (afaict), and i tried a bunch of distro with it (the usual distro hopping… right now it’s using plain arch linux, but i tested void, artix, ubuntu, devuan, manjaro, and probably many more through the years).

[marcan (Hector Martin)]

The hid-apple driver is shared for all Apple machines and there’s nothing specific in the key handling for the Asahi paths AFAIK other than some slightly different keymaps in some cases. Of course it could happen only on Asahi for some reason, but I still think it’s likely an upstream bug (that doesn’t mean we won’t look at it).

If you can figure out exactly what key combination causes it (precise order of keys pressed/released) that would be helpful.

[freeeaks (freeaks)]

yes, i also made a discovery, when this happens, if i press key u then keyboard gets immediately back to normal. and for key combination that cause the problem, here’s two of them:

opt+ctrl
opt+cmd
(all keys involved are on left side, order as noted)

however, i’ve also discovered that this behavior is the same as if i was typing with opt key pressed. when i press that key it doesn’t stick, but if i keep that key pressed and i try to type, i get same trashed ouput as i get using the two combos i reported above.

opt+ctrl / opt+cmd just do the same as what opt does, but it make sticky until “u” is pressed, whereas for opt as soon as i release key, it stops.

[marcan (Hector Martin)]

Alright, and just so we get all the info, can you paste the output of localectl? Thanks!

[freeeaks (freeaks)]

certainly:

[ Downloads ]  
 $ localectl 
System Locale: LANG=en_US.utf8
               LC_NUMERIC=fr_FR.utf8
               LC_TIME=fr_FR.utf8
               LC_MONETARY=fr_FR.utf8
               LC_PAPER=fr_FR.utf8
               LC_NAME=fr_FR.utf8
               LC_ADDRESS=fr_FR.utf8
               LC_TELEPHONE=fr_FR.utf8
               LC_MEASUREMENT=fr_FR.utf8
               LC_IDENTIFICATION=fr_FR.utf8
    VC Keymap: fr-mac
   X11 Layout: fr
  X11 Variant: mac
  X11 Options: terminate:ctrl_alt_bksp
[ Downloads ]  
 $ 

(sry for all the edits on the previous post while i was making my report straight

[jannau (Janne Grunau)]

I can’t reproduce the apparently sticky AltGr / right option key on j493 (13-inch Macbook Pro, M2) with a German keyboard (using the fr-mac VC keymap).

[freeeaks (freeaks)]

but what about left option key though ? (for me too right option key doesn’t pose problem, it’s only with the left one).
i hope it won’t be a hard to spot, hard to reproduce bug.
maybe it is limited to m2pro macbooks ?
all i can say is that i just did plain install, and while overall quality and stability and all of asahi seems quite good so far, i have noticed this specific problem… each time i switch to tty it’s there (since the key to drop to tty are: opt+ctrl+fn+f2). in any case, i’m glad that i’ve found ‘u’ key brings the keyboard back into usable state.