On cinnamon manjaro
just upgraded/updated all my packages and then moved to kernel 6.12.
Now I have just one bad keyboard mapping (as far as my testing).
the backtick/tilde key left of 1/! is now putting out left and right chevron (greater and less than).
some help on a fix?
not seeing anything wrong/different in keyboard settings.
Still says English(US).
what is VC keymap and should it be unset?
localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: (unset)
X11 Layout: us
For whatever its worth my localectl output looks like yours.
Can we be sure it is not a hardware fault?
I am a logi mx keys keyboard and run solaar. Maybe not a keyboard locale but rather something change with solaar?
I plugged in another keyboard and the tilde is fine. Something changed likely with solaar/mx keys.
So nothing to do with manjaro/cinnamon. edit: yes it is some recent package, see my post below
Arrrgh. hate when upgrades break things.
Sounds like itās mapped to LSGT.
You can try checking with evtest or xev -event keyboard, or wev for wayland. Though this may be lower than the problematic mapping.
Theyāre not installed by default, the packages are evtest, xorg-xev and wev.
https://wiki.archlinux.org/title/Keyboard_input#Identifying_scancodes
https://wiki.archlinux.org/title/Input_remap_utilities#Testing
Itās the keymap for the Linux console (TTYs). You can set it using localectl, but if you donāt have problems then 
https://wiki.archlinux.org/title/Linux_console/Keyboard_configuration
Can you remap the key using solaar?
If not then perhaps an input remapper will help.
@dmt I have not looked at what you posted but wanted to post some findings.
It is not a kernel issue. I reverted to 6.11 and 6.6 and the issues persists.
On my laptop (pre update) that key works fine. I upgrade (via pamac) and it becomes broken in the same way.
Same can be said for any machine I now upgrade via pamac and this mxkeys keyboard.
I then boot my laptop (or any machine) with a copy of manjaro on a stick (not recently updated) and the key works fine.
Some package in this last update is the culprit. I just donāt have a clue which one.
It is not solaar as this issue exists whether solaar is installed or not
ok from evtest this is the ābacktickā key
Event: time 1734629806.494130, -------------- SYN_REPORT ------------
<Event: time 1734629806.635987, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70035
Event: time 1734629806.635987, type 1 (EV_KEY), code 86 (KEY_102ND), value 0
Event: time 1734629806.635987, -------------- SYN_REPORT ------------
this is the ātildeā key
Event: time 1734629915.117855, -------------- SYN_REPORT ------------
Event: time 1734629915.157669, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1
Event: time 1734629915.157669, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1734629915.157669, -------------- SYN_REPORT ------------
how do I interpret that vs ascii?
FYI, There is no way to remap that key within mxkeys/solaar
here is the shift , = less than to the right of M. it gives the same code 42 as ābadā key. so at least it is consistent.
Event: time 1734630248.685397, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1
Event: time 1734630248.685397, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1734630248.685397, -------------- SYN_REPORT ------------
I plugged in another logi keyboard and press backtick/grave and this what it gives
Event: time 1734630454.415994, -------------- SYN_REPORT ------------
`Event: time 1734630454.576034, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70035
Event: time 1734630454.576034, type 1 (EV_KEY), code 41 (KEY_GRAVE), value 0
Event: time 1734630454.576034, -------------- SYN_REPORT ------------
and for tilde this
Event: time 1734630535.469800, -------------- SYN_REPORT ------------
Event: time 1734630535.589797, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1
Event: time 1734630535.589797, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1734630535.589797, -------------- SYN_REPORT ------------
so we know that it puts out and we know what it should put out question is why.
How about a temporary work round? Is there a way within linux to remap this? As you know without a backtick hard to type markdown and tilde kind of important in linux.
grepping the first output of evtest
sudo evtest /dev/input/event11 | grep GRAVE
Event code 41 (KEY_GRAVE)
so the key event exists in the mxkeys device but it is not mapped to that key anymore.
Wondering what
KEY_102ND
is about and why it got mapped to that key instead of
KEY_GRAVE
Thatās left shift, there should be another report for the other key, but it should be the same as without shift.
The scancode (70035) seems to be correct, but itās mapped to KEY_102ND (\ on a gb layout) instead of KEY_GRAVE. So the scancode has been remapped to a different keycode, but the question is where.
Does Cinnamon use X11?
If so whatās the output from this?
setxkbmap -print -verbose 10
There are several ways to remap.
I provided a link to some remapping utilities, but Iām not sure if theyāll work for this (never tried them).
We can remap scancodes to different keycodes, but this seems to be whatās already been done. Depending on how this has happened it may or may not work.
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdevā¦
Trying to load rules file /usr/share/X11/xkb/rules/evdevā¦
Success.
Applied rules from evdev:
rules: evdev
model: pc105
layout: us
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+us+inet(evdev)
geometry: pc(pc105)
xkb_keymap {
xkb_keycodes { include āevdev+aliases(qwerty)ā };
xkb_types { include ācompleteā };
xkb_compat { include ācompleteā };
xkb_symbols { include āpc+us+inet(evdev)ā };
xkb_geometry { include āpc(pc105)ā };
};
this is exactly the same settings as on my stick manajaro that is working. If I goof around with different choice of keyboards that key gets mapped differently but not to grave. Maybe the ādefaultā keyboard mapping changed? but then why only on my mx and not any other keyboard I plug in. Arrghā¦I really really like this keyboard but it was never meant to be used with linux. Maybe I should buy a new one :(.
cinnamon uses X11 not wayland
Thatās what I expected, though I was hoping it was different.
Well if itās not solaar
I donāt use the us layout, but thereās nothing I can see that would do this. The rules for applying the layouts may have changed, but I donāt know much about them.
Sounds like itās config related, you shouldnāt need a new one.
The input remap utilities would typically be the easiest way to remap a key.
Then thereās remapping the scancode, I edited my last post to include a link. However that may be the most difficult.
xkbcomp is a quick and dirty method of editing the config. However it needs to be re-applied every time you login and when the keyboard is reconnected, but that can be automated.
# dump the config
xkbcomp $DISPLAY ~/.xkbmap
# edit the file
# you can use a GUI editor if you wish
# the labels used are different then evdev
# you won't find 102ND
# you could try to change the keycode
# ie <TLDE> = 49; to <TLDE> = 94;
nano ~/.xkbmap
# get the device id for your keyboard
xinput
# re-apply using the id
# so we don't affect any other keyboards
# if you're not bothered about that
# then you can omit the -i $id part
xkbcomp ~/.xkbmap $DISPLAY -i $id
There are other ways we can remap using xkbcomp, ie symbols rather than keycodes.
Iāll try your remap suggestions before hitting this keyboard with a baseball bat (already 4 hours into this!). Irks me not to find out what really changed.
I did notice that xkeyboard-config package updated from my stick manjaro where key is working. So I downgraded that back to 2.42. No love same issue (even after reboot).
I havenāt changed anything yet but I ran
udevadm info /dev/input/event5
E: KEYBOARD_KEY_70035=102nd
E: KEYBOARD_KEY_70064=grave
hmm. when/how was this even set? it seems to be the issue no?
should either be removed, as that arch pages says only changed are listed, or edited/changed. How?
udevadm info /dev/input/event5
P: /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.3/1-4.3.1/1-4.3.1:1.2/0003:046D:C52B.0003/0003:046D:4092.0004/input/input15/event5
M: event5
R: 5
U: input
D: c 13:69
N: input/event5
L: 0
S: input/by-path/pci-0000:00:14.0-usbv2-0:4.3.1:1.2-event-mouse
S: input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse
S: input/by-path/pci-0000:00:14.0-usb-0:4.3.1:1.2-event-mouse
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.3/1-4.3.1/1-4.3.1:1.2/0003:046D:C52B.0003/0003:046D:4092.0004/input/input15/event5
E: DEVNAME=/dev/input/event5
E: MAJOR=13
E: MINOR=69
E: SUBSYSTEM=input
E: USEC_INITIALIZED=5607312
E: KEYBOARD_KEY_70035=102nd
E: KEYBOARD_KEY_70064=grave
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_BUS=usb
E: ID_MODEL=USB_Receiver
E: ID_MODEL_ENC=USB\x20Receiver
E: ID_MODEL_ID=c52b
E: ID_SERIAL=Logitech_USB_Receiver
E: ID_VENDOR=Logitech
E: ID_VENDOR_ENC=Logitech
E: ID_VENDOR_ID=046d
E: ID_REVISION=2411
E: ID_TYPE=hid
E: ID_USB_MODEL=USB_Receiver
E: ID_USB_MODEL_ENC=USB\x20Receiver
E: ID_USB_MODEL_ID=c52b
E: ID_USB_SERIAL=Logitech_USB_Receiver
E: ID_USB_VENDOR=Logitech
E: ID_USB_VENDOR_ENC=Logitech
E: ID_USB_VENDOR_ID=046d
E: ID_USB_REVISION=2411
E: ID_USB_TYPE=hid
E: ID_USB_INTERFACES=:030101:030102:030000:
E: ID_USB_INTERFACE_NUM=02
E: ID_USB_DRIVER=usbhid
E: ID_PATH_WITH_USB_REVISION=pci-0000:00:14.0-usbv2-0:4.3.1:1.2
E: ID_PATH=pci-0000:00:14.0-usb-0:4.3.1:1.2
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_3_1_1_2
E: LIBINPUT_DEVICE_GROUP=3/46d/4092:usb-0000:00:14.0-4.3
E: DEVLINKS=/dev/input/by-path/pci-0000:00:14.0-usbv2-0:4.3.1:1.2-event-mouse /dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse /dev/input/by-path/pci-0000:00:14.0>
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:
Good question. You can check in /etc/udev/rules.d and /etc/udev/hwdb.d but Iām not sure if youāll find anything there.
Yep, something has switched the scancode to keycode mappings. So it should be assigned to the other key, presumably backslash (but it may or may not be a different key for the us layout).
HA,
look what I found in
/usr/lib/udev/hwdb.d/60-keyboard.hwdb
Logitech MX Keys for Mac
evdev:input:b0003v046Dp4092*
KEYBOARD_KEY_70035=102nd # ā<ā key
KEYBOARD_KEY_70064=grave # ā^ā key
and that entry is NOT in my stick version of that file. I think I have found the issue.
WTF who put that in there and why?
I guess I better just use an override in /etc/ else any upgrades may revert a change to this file?
trying that now.
Thx for input, would have never been able to hunt this down without help.
Nice find. 
Iād forgotten about /usr/lib/udev/hwdb.d, but that was what I was trying (and failing) to remember. 
It seems to be owned by systemd.
pacman -F /usr/lib/udev/hwdb.d/60-keyboard.hwdb
usr/lib/udev/hwdb.d/60-keyboard.hwdb is owned by core/systemd 257-1
Yeah, that should work.
Also thanks for reminding me about udevadm info, Iād forgotten that too.
I tried just commenting out those lines and rebooting but they are still showing up in udevadm info and key is still working.
Maybe there is copy in other udev directories?
Will try my own etc file now.
I wouldnāt expect another.
I think thatās the way, same as remapping scancodes to keycodes but with it mostly figured out for you.
Not sure if an empty file will do, but you can copy it from the file in /usr and swap the keycodes back to normal (make sure the KEYBOARD_KEY lines are indented by a single space). 
Like so:
# /etc/udev/hwdb.d/60-keyboard.hwdb
evdev:input:b0003v046Dp4092*
KEYBOARD_KEY_70035=grave
KEYBOARD_KEY_70064=102nd
Had to rebuild the database first then reboot and it is working!
I can only assume someone on systemd project did this.
Yep they did and I flamed them a bit for doing this.
given they may not take this out I will add to /etc to be sure.
Total Thanks @dmt
geez how many people have this keyboard on linux. Hope they find this post.
Glad itās sorted. 
Clearly Iāve forgotten quite a bit, I think I need a refresher.
I find it a bit weird they accepted that PR. It always seems like the systemd project is very conservative with changes being it can really fubar a lot of people.
Luckily Iām not on the clock so I could waste a whole day on this. The up side is we both (re)learned something about keyboards and udev/hwdb
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.