search

sezanzeb / input-remapper

🎮 ⌨ An easy to use tool to change the behaviour of your input devices.
GNU General Public License v3.0
3.74k stars 155 forks source link

All macro keys on Alienware keyboard are detected as the same (EV_MSC not supported) #457

Open rodrigopedra opened 2 years ago

rodrigopedra commented 2 years ago

Alienware AW658 keyboard has 6 macro keys on its left side. Input remapper sees all of them as the same.

evtest reports for each key:

Below is the filled issue template

Please install the newest version from source to see if the problem has already been solved.

Share some logs please:

  1. input-remapper-control --version
# input-remapper-control --version
input-remapper 1.5.0 0b885df73c7058158df7483aa542b065c7efa7d0 https://github.com/sezanzeb/input-remapper
python-evdev 1.6.0
  1. If a button on your device doesn't show up in the GUI, verify that the button is reporting an event via sudo evtest. If not, input-remapper won't be able to map that button.
Testing ... (interrupt to exit)
Event: time 1661147956.119353, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff01
Event: time 1661147956.119353, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1661147956.119353, -------------- SYN_REPORT ------------
Event: time 1661147956.176231, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff01
Event: time 1661147956.176231, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1661147956.176231, -------------- SYN_REPORT ------------
Event: time 1661147957.338356, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff02
Event: time 1661147957.338356, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1661147957.338356, -------------- SYN_REPORT ------------
Event: time 1661147957.404355, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff02
Event: time 1661147957.404355, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1661147957.404355, -------------- SYN_REPORT ------------
Event: time 1661147958.090356, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff03
Event: time 1661147958.090356, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1661147958.090356, -------------- SYN_REPORT ------------
Event: time 1661147958.179356, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff03
Event: time 1661147958.179356, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1661147958.179356, -------------- SYN_REPORT ------------
Event: time 1661147958.741356, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff04
Event: time 1661147958.741356, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1661147958.741356, -------------- SYN_REPORT ------------
Event: time 1661147958.827356, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff04
Event: time 1661147958.827356, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1661147958.827356, -------------- SYN_REPORT ------------
Event: time 1661147960.188367, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff05
Event: time 1661147960.188367, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1661147960.188367, -------------- SYN_REPORT ------------
Event: time 1661147960.274365, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff05
Event: time 1661147960.274365, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1661147960.274365, -------------- SYN_REPORT ------------
Event: time 1661147960.813372, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff06
Event: time 1661147960.813372, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1661147960.813372, -------------- SYN_REPORT ------------
Event: time 1661147960.877362, type 4 (EV_MSC), code 4 (MSC_SCAN), value cff06
Event: time 1661147960.877362, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1661147960.877362, -------------- SYN_REPORT ------------
  1. If yes, please run input-remapper-gtk -d, reproduce the problem and then share the logs.
Click to see logs ~~~ $ input-remapper-gtk -d Gtk-Message: 03:00:04.560: Failed to load module "5008{GTK_MODULES" Gtk-Message: 03:00:04.560: Failed to load module "+canberra-gtk-module" Gtk-Message: 03:00:04.560: Failed to load module "}appmenu-gtk-module" 03:00:04.692018 11125 GUI DEBUG logger.py:255: Using rich.traceback 03:00:04.692075 11125 GUI INFO logger.py:223: input-remapper-gtk 1.5.0 0b885df73c7058158df7483aa542b065c7efa7d0 https://github.com/sezanzeb/input-remapper 03:00:04.692134 11125 GUI INFO logger.py:231: python-evdev 1.6.0 03:00:04.692168 11125 GUI WARNING logger.py:234: Debug level will log all your keystrokes! Do not post this output in the internet if you typed in sensitive or private information with your device! 03:00:04.692199 11125 GUI DEBUG input-remapper-gtk:55: Using locale directory: /usr/share/input-remapper/lang 03:00:04.695090 11125 GUI DEBUG pipe.py:62: Creating new pipe for "/tmp/input-remapper-rodrigo/results" 03:00:04.695557 11125 GUI DEBUG pipe.py:62: Creating new pipe for "/tmp/input-remapper-rodrigo/commands" 03:00:04.724578 11125 GUI INFO global_config.py:105: Loaded config from "/home/rodrigo/.config/input-remapper/config.json" 03:00:04.726797 11125 GUI INFO daemon.py:199: Connected to the service 03:00:04.726851 11125 GUI DEBUG daemon.py:235: Telling service about "/home/rodrigo/.config/input-remapper" 03:00:04.728185 11125 GUI DEBUG user_interface.py:246: Running `pkexec input-remapper-control --command helper -d` 03:00:08.250449 11129 Control DEBUG logger.py:255: Using rich.traceback 03:00:08.250529 11129 Control DEBUG input-remapper-control:230: Call for "['/usr/bin/input-remapper-control', '--command', 'helper', '-d']" 03:00:08.293776 11129 Control DEBUG input-remapper-control:212: Booting finished 03:00:08.294852 11129 Control INFO input-remapper-control:260: Done 03:00:08.318079 11125 GUI DEBUG global_uinputs.py:80: creating fake UInput device: 'input-remapper keyboard' 03:00:08.318144 11125 GUI DEBUG global_uinputs.py:80: creating fake UInput device: 'input-remapper gamepad' 03:00:08.318181 11125 GUI DEBUG global_uinputs.py:80: creating fake UInput device: 'input-remapper mouse' 03:00:08.318215 11125 GUI DEBUG global_uinputs.py:80: creating fake UInput device: 'input-remapper keyboard + mouse' 03:00:08.415398 11125 GUI DEBUG groups.py:337: Discovering device paths 03:00:08.415791 11125 GUI DEBUG groups.py:446: Did not find any input device 03:00:08.538038 11143 GUI-Helper DEBUG logger.py:255: Using rich.traceback 03:00:08.569613 11143 GUI-Helper DEBUG pipe.py:79: Using existing pipe for "/tmp/input-remapper-rodrigo/results" 03:00:08.569720 11143 GUI-Helper DEBUG pipe.py:79: Using existing pipe for "/tmp/input-remapper-rodrigo/commands" 03:00:08.569790 11143 GUI-Helper DEBUG helper.py:110: Sending groups 03:00:08.570813 11143 GUI-Helper DEBUG groups.py:337: Discovering device paths 03:00:09.265876 11143 GUI-Helper DEBUG groups.py:378: Found "25_0_3_PNP0C0E", "/dev/input/event8", "Sleep Button", type: unknown 03:00:09.281609 11143 GUI-Helper DEBUG groups.py:378: Found "3_16700_42243_usb-0000:00:14.0-6.2", "/dev/input/event7", "Dell Dell AC511 USB SoundBar", type: unknown 03:00:09.309804 11143 GUI-Helper DEBUG groups.py:378: Found "3_1266_5733_usb-0000:00:14.0-8", "/dev/input/event6", "DELL Alienware Advanced Gaming Keyboard AW568 Keyboard", type: keyboard 03:00:09.333751 11143 GUI-Helper DEBUG groups.py:378: Found "3_1266_5733_usb-0000:00:14.0-8", "/dev/input/event5", "DELL Alienware Advanced Gaming Keyboard AW568 Mouse", type: mouse 03:00:09.369731 11143 GUI-Helper DEBUG groups.py:378: Found "3_1266_5733_usb-0000:00:14.0-8", "/dev/input/event4", "DELL Alienware Advanced Gaming Keyboard AW568 Consumer Control", type: unknown 03:00:09.397728 11143 GUI-Helper DEBUG groups.py:378: Found "3_1266_5733_usb-0000:00:14.0-8", "/dev/input/event3", "DELL Alienware Advanced Gaming Keyboard AW568 System Control", type: unknown 03:00:09.421775 11143 GUI-Helper DEBUG groups.py:378: Found "3_1266_5733_usb-0000:00:14.0-8", "/dev/input/event2", "DELL Alienware Advanced Gaming Keyboard AW568", type: keyboard 03:00:09.457737 11143 GUI-Helper DEBUG groups.py:378: Found "3_10077_2982_usb-0000:00:14.0-6.1", "/dev/input/event1", "USB OPTICAL MOUSE ", type: mouse 03:00:09.473661 11143 GUI-Helper DEBUG groups.py:378: Found "3_3468_32_usb-0000:00:14.0-1.1", "/dev/input/event0", "UC MIC ATR2USB Consumer Control", type: unknown 03:00:09.473967 11143 GUI-Helper INFO groups.py:449: Found "Sleep Button", "Dell Dell AC511 USB SoundBar", "DELL Alienware Advanced Gaming Keyboard AW568", "USB OPTICAL MOUSE ", "UC MIC ATR2USB Consumer Control" 03:00:09.474174 11143 GUI-Helper DEBUG helper.py:91: Waiting for the first command 03:00:09.491499 11125 GUI DEBUG reader.py:99: Received 5 devices 03:00:09.491968 11125 GUI DEBUG preset.py:379: The newest preset is "DELL Alienware Advanced Gaming Keyboard AW568", "new preset copy" 03:00:09.492062 11125 GUI DEBUG user_interface.py:600: Selecting device "DELL Alienware Advanced Gaming Keyboard AW568" 03:00:09.492146 11125 GUI DEBUG user_interface.py:384: "DELL Alienware Advanced Gaming Keyboard AW568" presets: "new preset copy", "new preset" 03:00:09.492305 11125 GUI DEBUG user_interface.py:714: Selecting preset "new preset copy" 03:00:09.492556 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:09.492977 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:09.493293 11125 GUI INFO preset.py:170: Loading preset from "/home/rodrigo/.config/input-remapper/presets/DELL Alienware Advanced Gaming Keyboard AW568/new preset copy.json" 03:00:09.493600 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:09.493777 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:09.494031 11125 GUI DEBUG reader.py:190: Sending start msg to helper for "DELL Alienware Advanced Gaming Keyboard AW568" 03:00:09.494087 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:09.494173 11143 GUI-Helper DEBUG helper.py:103: Starting mainloop 03:00:09.494261 11143 GUI-Helper DEBUG helper.py:117: Received command "DELL Alienware Advanced Gaming Keyboard AW568" 03:00:09.494350 11143 GUI-Helper DEBUG helper.py:139: No more commands in pipe 03:00:09.494525 11143 GUI-Helper DEBUG helper.py:174: Starting reading keycodes from "DELL Alienware Advanced Gaming Keyboard AW568 Keyboard", "DELL Alienware Advanced Gaming Keyboard AW568 Mouse", "DELL Alienware Advanced Gaming Keyboard AW568 Consumer Control", "DELL Alienware Advanced Gaming Keyboard AW568 System Control", "DELL Alienware Advanced Gaming Keyboard AW568" 03:00:13.520458 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:15.534217 11125 GUI DEBUG reader.py:162: down ·························· 03:00:15.534338 11125 GUI DEBUG reader.py:182: read result ··················· 03:00:15.534441 11125 GUI DEBUG system_mapping.py:91: Gathering available keycodes 03:00:15.534496 11125 GUI DEBUG system_mapping.py:91: Gathering available keycodes 03:00:15.536813 11125 GUI DEBUG system_mapping.py:120: Writing "/home/rodrigo/.config/input-remapper/xmodmap.json" 03:00:15.537061 11125 GUI DEBUG system_mapping.py:91: Gathering available keycodes 03:00:15.538955 11125 GUI DEBUG system_mapping.py:120: Writing "/home/rodrigo/.config/input-remapper/xmodmap.json" 03:00:15.544036 11125 GUI DEBUG system_mapping.py:120: Writing "/home/rodrigo/.config/input-remapper/xmodmap.json" 03:00:15.545580 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:15.545884 11125 GUI DEBUG editor.py:644: Symbol missing 03:00:15.602185 11125 GUI DEBUG reader.py:147: release ······················· 03:00:15.602272 11125 GUI DEBUG editor.py:675: Recording complete 03:00:15.602309 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:15.647296 11125 GUI DEBUG autocompletion.py:91: get_incomplete_parameter text: match: None 03:00:21.768337 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:23.697518 11125 GUI DEBUG reader.py:162: down ·························· 03:00:23.697706 11125 GUI DEBUG reader.py:182: read result ··················· 03:00:23.697836 11125 GUI DEBUG editor.py:634: didn't change 03:00:23.765227 11125 GUI DEBUG reader.py:147: release ······················· 03:00:23.765306 11125 GUI DEBUG editor.py:675: Recording complete 03:00:23.765340 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:27.624667 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:28.535452 11125 GUI DEBUG reader.py:162: down ·························· 03:00:28.535557 11125 GUI DEBUG reader.py:182: read result ··················· 03:00:28.535663 11125 GUI DEBUG editor.py:634: didn't change 03:00:28.636207 11125 GUI DEBUG reader.py:147: release ······················· 03:00:28.636303 11125 GUI DEBUG editor.py:675: Recording complete 03:00:28.636368 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:31.584645 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:33.438485 11125 GUI DEBUG reader.py:162: down ·························· 03:00:33.438601 11125 GUI DEBUG reader.py:182: read result ··················· 03:00:33.438693 11125 GUI DEBUG editor.py:634: didn't change 03:00:33.505237 11125 GUI DEBUG reader.py:147: release ······················· 03:00:33.505330 11125 GUI DEBUG editor.py:675: Recording complete 03:00:33.505394 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:34.464657 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:35.075497 11125 GUI DEBUG reader.py:162: down ·························· 03:00:35.075616 11125 GUI DEBUG reader.py:182: read result ··················· 03:00:35.075710 11125 GUI DEBUG editor.py:634: didn't change 03:00:35.176227 11125 GUI DEBUG reader.py:147: release ······················· 03:00:35.176332 11125 GUI DEBUG editor.py:675: Recording complete 03:00:35.176369 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:35.928495 11125 GUI DEBUG reader.py:206: Clearing reader 03:00:36.451414 11125 GUI DEBUG reader.py:162: down ·························· 03:00:36.451504 11125 GUI DEBUG reader.py:182: read result ··················· 03:00:36.451568 11125 GUI DEBUG editor.py:634: didn't change 03:00:36.552277 11125 GUI DEBUG reader.py:147: release ······················· 03:00:36.552357 11125 GUI DEBUG editor.py:675: Recording complete 03:00:36.552393 11125 GUI DEBUG editor.py:337: Enabling the text input 03:00:41.384578 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:41.385102 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:41.385335 11125 GUI DEBUG editor.py:322: Disabling the text input 03:00:43.696648 11125 GUI DEBUG user_interface.py:332: Closing window 03:00:43.696853 11125 GUI DEBUG reader.py:197: Sending close msg to helper 03:00:43.696971 11143 GUI-Helper DEBUG helper.py:193: Stops reading due to new command (input-remapper-gtk:11125): Gtk-CRITICAL **: 03:00:43.699: gtk_tree_model_get_column_type: assertion 'GTK_IS_TREE_MODEL (tree_model)' failed (input-remapper-gtk:11125): Gtk-CRITICAL **: 03:00:43.699: gtk_combo_box_get_active_id: assertion 'gtk_tree_model_get_column_type (model, column) == G_TYPE_STRING' failed 03:00:43.699239 11125 GUI DEBUG user_interface.py:332: Closing window 03:00:43.699346 11125 GUI DEBUG reader.py:197: Sending close msg to helper (input-remapper-gtk:11125): Gtk-CRITICAL **: 03:00:43.699: gtk_main_quit: assertion 'main_loops != NULL' failed 03:00:43.865759 11143 GUI-Helper DEBUG helper.py:117: Received command "terminate" 03:00:43.865818 11143 GUI-Helper DEBUG helper.py:120: Helper terminates ~~~
jonasBoss commented 2 years ago

Inputremapper only considers the EV_KEY events and they all report the code 240. Which explains your issue.

According to the linux kernel docs EV_MSC can be anything. So it is not clear how we could properly handle those events.

@sezanzeb did you look into this already? I think I have seen a similar issue in another bug report. Maybe there is a way to support EV_MSC if Inputremapper always processes a whole frame (from syn-report to syn-report).

jonasBoss commented 2 years ago

Possibly the same issue: #452

rodrigopedra commented 2 years ago

Thanks @jonasBoss for the response.

I searched a lot to see if a similar issue was already reported but could not find that one.

I wish I could help you out on this, but I am not familiar with kernel event handling.

sezanzeb commented 2 years ago

@sezanzeb did you look into this already?

no

Maybe there is a way to support EV_MSC if Inputremapper always processes a whole frame (from syn-report to syn-report).

in order to check if it is a key-up or key-down event?

I wonder if syn-reports are guaranteed to wrap only single complete key events, and if waiting for the final syn-report never causes additional latency

sezanzeb commented 2 years ago

the second EV_MSC event is always a key-up, isn't it?

rodrigopedra commented 2 years ago

Not sure if the question is a technical one or related to how I generated the output.

The first output on my report was created by pressing and "unpressing" the 6 keys in sequence as normal key strokes. I didn't hold any keys for a longer period, nor repeated any stroke.

If you want me to perform any other tests with the keyboard, let me know and I will happily do it.

sezanzeb commented 2 years ago

it was a technical one about how EV_MSC events behave for all kinds of input devices.

maybe we can fall back to the EV_MSC event instead of the EV_KEY event if its code is KEY_UNKNOWN. But since the EV_MSC event arrives first we have to remember it for at least the next EV_KEY event. Then we can just the value of the EV_KEY event.

if all input devices report EV_MSC along with EV_KEY, maybe we can also just always use the EV_MSC event instead? I wonder how its value translates to the code of the EV_KEY event. The EV_MSC value seems to be rising alphabetically, whereas EV_KEY is the position on the keyboard.

jonasBoss commented 2 years ago

I wonder if syn-reports are guaranteed to wrap only single complete key events, and if waiting for the final syn-report never causes additional latency

I think so according to the kernel docs the SYN_REPORT is

Used to synchronize and separate events into packets of input data changes occurring at the same moment in time. For example, motion of a mouse may set the REL_X and REL_Y values for one motion, then emit a SYN_REPORT. The next motion will emit more REL_X and REL_Y values and send another SYN_REPORT.

And from my observations this holds true for all devices I have used so far.

in order to check if it is a key-up or key-down event?

exactley It seems like the value of EV_MSC is the key-code, while the value of EV_KEY is the key-state (up/down).

But looking at #452:

Event: time 1659908549.957874, -------------- SYN_REPORT ------------
Event: time 1659908550.597551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 85
Event: time 1659908550.597551, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1659908550.597551, -------------- SYN_REPORT ------------
Event: time 1659908550.597579, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1659908550.597579, -------------- SYN_REPORT ------------
Event: time 1659908551.644219, type 4 (EV_MSC), code 4 (MSC_SCAN), value 86
Event: time 1659908551.644219, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1659908551.644219, -------------- SYN_REPORT ------------
Event: time 1659908551.644245, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1659908551.644245, -------------- SYN_REPORT ------------

It seems like the EV_MSC is not guaranteed to be sent when the key is released.

maybe we can fall back to the EV_MSC event instead of the EV_KEY event if its code is KEY_UNKNOWN.

This seems to be the best idea so far.

if all input devices report EV_MSC along with EV_KEY, maybe we can also just always use the EV_MSC event instead?

My DualSense controller does not report any EV_MSC events.

sezanzeb commented 2 years ago

This seems to be the best idea so far.

So we would wait for the completion of SYN_REPORT "packets" in the InputEvent class. InputEvent might then become InputDataPacket to be consistent with the kernel docs.

Would any other class besides Reader and EventReader require changes?

And from my observations this holds true for all devices I have used so far. My DualSense controller does not report any EV_MSC events.

Thanks for checking

jonasBoss commented 2 years ago

Would any other class besides Reader and EventReader require changes?

Yes, most likely many others. We use the InputEvent all over the codebase as a hash or part of a hash (EventCombination). And the InputEvent does two completely unrelated things:

  1. Define the Input configuration of a mapping
  2. Transport Input information

There are a few things we should change to support this properly:

I think we need to find a better way store the input configuration of a mapping. The current solution with the EventCombination feels like a hack. It stores a lot of information like the order of events, the direction of events and (on beta) the input threshold of a event. But it is not clear that all this information is part of the EventCombination we should write a class which is more explicit, expandable and is unrelated to evdev.InputEvents. That way the Preset save files can be much better readable and the input processing is independent from the mapping.

Make our own InputEvent let's call it EventDataPacket, which will store all the necessary information to process the Input as it passes through the different EventHandlers

A Translation Layer (the EventReader) which will translate a input frame (SYN_REPORT-SYN_REPORT) into one or multiple EventDataPackets.

sezanzeb commented 2 years ago

Yes, most likely many others. We use the InputEvent all over the codebase as a hash or part of a hash (EventCombination).

Can't the InputDataPacket class be a drop-in replacement for InputEvent? Its type, code and value would be generated from all the InputEvents that are part of it.

jonasBoss commented 2 years ago

Yes this is probably possible, but I don't like it. I think we are better off creating a seperate class for the InputConfiguration (which is also used as a hash) and the InputDataPacket, as those are two different responsibilities.

jonasBoss commented 1 year ago

550 Separates InputEvent from InputConfig