Injection silently fails after kernel upgrade

[emersonrp]

Manjaro Linux. input-remapper has been working flawlessly for a long while, but after upgrading my kernel from 6.1 LTS to 6.6 LTS, it stopped working.

Specifically, input-remapper-gtk launches fine, sees my configs as expected. When I select a config for my Razer Tartarus Pro, and click "Apply," it seems to succeed, ie, pauses for a moment then says "Applied preset Division 2" in the status bar.

The Tartarus, however, doesn't get any key mappings; it's just still set to the defaults.

I have uninstalled and rebuilt/reinstalled input-remapper-git from AUR.

Output of "sudo pkill -f input-remapper && input-remapper-gtk -d" attached.

debug_output.txt

Edit to add: Reverting to the 6.1 kernel fixes the issue, so there's something going on with the current 6.6.7-1 LTS kernel in the Manjaro repo that is correlated to the problem.

[Sweeper5]

This may explain why it seems to behave so funkily for me as well under Arch Linux. I suspected I was doing something wrong, but I couldn't even make my mouse dump simple keys when I pressed a button. I will watch this one as the dev seems to snap up on issues and post when fixed.

[ahktenzero]

I have a similar issue on Debian testing after updating to a 6.6 kernel from 6.5. Applying a mapping to my Tartarus v2 appears to succeed but it doesn't have any effect. It does still work on my mouse though.

Looking in /proc/bus/input/devices, the Tartarus has 3 event devices:

I: Bus=0003 Vendor=1532 Product=022b Version=0111
N: Name="Razer Razer Tartarus V2"
P: Phys=usb-0000:00:14.0-5.2.3/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.2/3-5.2.3/3-5.2.3:1.0/0003:1532:022B.000F/input/input62
U: Uniq=
H: Handlers=sysrq kbd leds event11
B: PROP=0
B: EV=120013
B: KEY=3c0000000000 0 0 0 0 0 0 1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=1532 Product=022b Version=0111
N: Name="Razer Razer Tartarus V2"
P: Phys=usb-0000:00:14.0-5.2.3/input1
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.2/3-5.2.3/3-5.2.3:1.1/0003:1532:022B.0010/input/input63
U: Uniq=
H: Handlers=sysrq kbd event19
B: PROP=0
B: EV=10001f
B: KEY=3c0000000000 33eff 0 0 483ffff17aff32d bfd4444600000000 1 130c730b17c007 ffbf7bfad941dfff febeffdfffefffff fffffffffffffffe
B: REL=1040
B: ABS=10100000000
B: MSC=10

I: Bus=0003 Vendor=1532 Product=022b Version=0111
N: Name="Razer Razer Tartarus V2"
P: Phys=usb-0000:00:14.0-5.2.3/input2
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.2/3-5.2.3/3-5.2.3:1.2/0003:1532:022B.0011/input/input64
U: Uniq=
H: Handlers=mouse3 event27
B: PROP=0
B: EV=17
B: KEY=3c0000000000 0 0 0 0 0 1f0000 0 0 0 0
B: REL=903
B: MSC=10

input-remapper is only grabbing the first one (event11), which although it appears to be a keyboard doesn't generate any keyboard events. Events for the keypresses appear on the second device with keyboard cababilites (event19), which isn't grabbed so they continue to pass through unaltered.

[ahktenzero]

Figured out what the issue is and how to fix it. input-remapper stores a hash of the device name and certain other parameters in the input_combination part of the mapping. This is used to determine which devices get grabbed when the mapping is injected. It looks like the hashes saved on pre 6.6 don't match any of the devices on 6.6 so input-remapper falls back to using the first input device of the right type. Unfortunately this isn't the one which gets keyboard events, so the remapping does nothing.

In order to fix it, you need to update the mapping with the right device hashes, either by going through each one in the GTK editor and re-recording the input, or search and replace in the mapping files. The hash for the keyboard part should be 89c79a52c20a75483a82f67d8594ac5d, if you've remapped the wheel use 690ecbecca750bb50f1a5bd74f32831d.

[emersonrp]

Just realized I hadn't commented on this -- ahktenzero's diagnosis seems correct and rebuilding the presets from first principles fixed the problem for me. It's a bit tedious, and it'd be nice if there were some way for the old hashes to be mapped to the new ones automatically, but I understand that might be a lot of effort and it's not clear that the problem affects that many people. I'm going to leave this open for the developer to continue to see and/or close if they decide it's not worth the trouble. Thanks, ahktenzero.