Keymap problem (two keys switched)

freeeaks · October 27, 2023, 8:50pm

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 · October 27, 2023, 9:04pm

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

freeeaks · October 27, 2023, 9:23pm

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

marcan · October 28, 2023, 7:39am

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 · October 28, 2023, 9:54am

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 · October 28, 2023, 11:08am

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 · October 28, 2023, 11:15am

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 · October 28, 2023, 11:52am

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

Thanks for reporting this

freeeaks · October 28, 2023, 12:18pm

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 · October 28, 2023, 4:12pm

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 · October 28, 2023, 4:37pm

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 · October 28, 2023, 5:16pm

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 · October 28, 2023, 5:32pm

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 · October 28, 2023, 7:23pm

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

freeeaks · October 28, 2023, 7:31pm

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 · October 28, 2023, 8:26pm

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 · October 28, 2023, 8:52pm

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.