input-remapper All macro keys on Alienware keyboard are detected as the same (EV

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

Open rodrigopedra opened this issue 2 years ago • 13 comments

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:

same type: 4 (EV_MSC)
same code: 4 (MSC_SCAN)
but different values: cff01, cff02, cff03, cff04, cff05, cff06

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:

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

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 ------------

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 ·························· <InputEvent KEY_UNKNOWN (240) down>
03:00:15.534338 11125 GUI DEBUG reader.py:182: read result ··················· <EventCombination (1, 240, 1)>
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 ······················· <InputEvent KEY_UNKNOWN (240) up>
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 ·························· <InputEvent KEY_UNKNOWN (240) down>
03:00:23.697706 11125 GUI DEBUG reader.py:182: read result ··················· <EventCombination (1, 240, 1)>
03:00:23.697836 11125 GUI DEBUG editor.py:634: <EventCombination (1, 240, 1)> didn't change
03:00:23.765227 11125 GUI DEBUG reader.py:147: release ······················· <InputEvent KEY_UNKNOWN (240) up>
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 ·························· <InputEvent KEY_UNKNOWN (240) down>
03:00:28.535557 11125 GUI DEBUG reader.py:182: read result ··················· <EventCombination (1, 240, 1)>
03:00:28.535663 11125 GUI DEBUG editor.py:634: <EventCombination (1, 240, 1)> didn't change
03:00:28.636207 11125 GUI DEBUG reader.py:147: release ······················· <InputEvent KEY_UNKNOWN (240) up>
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 ·························· <InputEvent KEY_UNKNOWN (240) down>
03:00:33.438601 11125 GUI DEBUG reader.py:182: read result ··················· <EventCombination (1, 240, 1)>
03:00:33.438693 11125 GUI DEBUG editor.py:634: <EventCombination (1, 240, 1)> didn't change
03:00:33.505237 11125 GUI DEBUG reader.py:147: release ······················· <InputEvent KEY_UNKNOWN (240) up>
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 ·························· <InputEvent KEY_UNKNOWN (240) down>
03:00:35.075616 11125 GUI DEBUG reader.py:182: read result ··················· <EventCombination (1, 240, 1)>
03:00:35.075710 11125 GUI DEBUG editor.py:634: <EventCombination (1, 240, 1)> didn't change
03:00:35.176227 11125 GUI DEBUG reader.py:147: release ······················· <InputEvent KEY_UNKNOWN (240) up>
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 ·························· <InputEvent KEY_UNKNOWN (240) down>
03:00:36.451504 11125 GUI DEBUG reader.py:182: read result ··················· <EventCombination (1, 240, 1)>
03:00:36.451568 11125 GUI DEBUG editor.py:634: <EventCombination (1, 240, 1)> didn't change
03:00:36.552277 11125 GUI DEBUG reader.py:147: release ······················· <InputEvent KEY_UNKNOWN (240) up>
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

Aug 22 '22 06:08 rodrigopedra

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).

Aug 22 '22 14:08 jonasBoss

Possibly the same issue: #452

Aug 22 '22 14:08 jonasBoss

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.

Aug 22 '22 15:08 rodrigopedra

@sezanzeb did you look into this already?

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

Aug 22 '22 18:08 sezanzeb

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

Aug 22 '22 18:08 sezanzeb

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.

Aug 22 '22 20:08 rodrigopedra

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.

Aug 22 '22 20:08 sezanzeb

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.

Aug 24 '22 11:08 jonasBoss

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

Aug 27 '22 11:08 sezanzeb

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:

Define the Input configuration of a mapping
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.

Aug 28 '22 09:08 jonasBoss

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.

Aug 28 '22 10:08 sezanzeb

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.

Aug 28 '22 11:08 jonasBoss

#550 Separates InputEvent from InputConfig

Dec 06 '22 15:12 jonasBoss

input-remapper input-remapper copied to clipboard

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

input-remapper
input-remapper copied to clipboard