sezanzeb / input-remapper

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

Only keys that are assigned a mapping work as intended after injection, others are unresponsive #131

Open WilliamHe23 opened 3 years ago

WilliamHe23 commented 3 years ago

When I apply mappings, the keys that I assigned mappings to will function as intended (with the new mappings). However, all of the other keys on my keyboard will no longer produce any input. Of course restoring defaults reverts back to the original. I suppose one workaround would be to map all other keys to themselves, but I am not sure what the issue actually is.

I am using the 1.0.0 version of the software on Pop!_OS 20.04 with X11.

sezanzeb commented 3 years ago

Please run sudo pkill -f key-mapper-service && key-mapper-gtk -d, start the injection and hit a key that doesn't work anymore. Then share that log.

WilliamHe23 commented 3 years ago

Does it matter what order I open the program and run the command in (ie, should I run that command before or after starting key mapper, or does it not matter)? During testing I sometimes got everything to work (although I have not tried autoload yet) after running that command, but I have not been able to reproduce it very consistently. I seemed to have the most luck by:

  1. Restoring defaults and closing Key Mapper if it is open (also stopping the command)
  2. Opening the Key Mapper
  3. Running the command you suggested
  4. Closing the Key Mapper
  5. Opening the Key Mapper
  6. Injecting
  7. Repeating from (1) if it did not work

But then if I restore defaults and try injecting again, it may or may not work. If it does not work then I can try starting from step (1) again. Perhaps these steps are not even what is causing things to work, and time may be a factor too,

This seems to be a reasonable workaround for whatever the issue actually is. But in any case I've attached a log file in which I experience the issue initially described above. The keys that say "forwarding" then "forwarding release" don't actually produce any output. The ones that say "maps to X" then "releasing X" do work as intended. But I believe these output lines are normal.

(There was also at least one time where all the keys except the ones I remapped worked as normal, and the remapped keys did nothing.)

keymapper_debug.txt

sezanzeb commented 3 years ago

The keys that say "forwarding" then "forwarding release" don't actually produce any output

This is useful information. Thanks!

Now please start the injection until the problem is reproduced again and then run sudo evtest. There should be devices ending in "Forwarded" or something. Select them. Do you see events for the keys that don't produce any output?

WilliamHe23 commented 3 years ago

When problem is reproduced

There are two devices with the exact same name ('key-mapper Gaming Keyboard forwarded') that are event269 and event270.

When I select the first one and press any keys on the keyboard, there are no events reported.

When I select the second one, events are indeed reported. For example the J key which is not mapped:

Event: time 1625081313.226193, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7000d Event: time 1625081313.226193, type 1 (EV_KEY), code 36 (KEY_J), value 1 Event: time 1625081313.226193, -------------- SYN_REPORT ------------ Event: time 1625081313.342154, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7000d Event: time 1625081313.342154, type 1 (EV_KEY), code 36 (KEY_J), value 0 Event: time 1625081313.342154, -------------- SYN_REPORT ------------

and the \ key which is mapped to a different key:

Event: time 1625081316.865536, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031 Event: time 1625081316.865536, -------------- SYN_REPORT ------------ Event: time 1625081317.022934, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031 Event: time 1625081317.022934, -------------- SYN_REPORT ------------

(During this process I obviously had a second keyboard connected in order to type the commands and so. But as a side effect, it seemed that I was never able to get Key Mapper to work while the second keyboard was connected, even though I selected the correct one in the program. But once I unplugged the second keyboard, I was able to get the mappings to work by following the steps I mentioned. It could be a coincidence but I will at least mention it.)

When there is no problem

There are still two devices with the same name, now event8 and event268.

When I select the first one and press keys on the keyboard, evtest does not respond with anything (like before), but this time they appear in the console; that is, if I press 'a' twice it looks like

Testing ... (interrupt to exit) aa

When I select the second one, events are reported like before, and the key also appears. For example the J key which is not mapped:

Event: time 1625082470.408637, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7000d Event: time 1625082470.408637, type 1 (EV_KEY), code 36 (KEY_J), value 1 Event: time 1625082470.408637, -------------- SYN_REPORT ------------ jEvent: time 1625082470.531544, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7000d Event: time 1625082470.531544, type 1 (EV_KEY), code 36 (KEY_J), value 0 Event: time 1625082470.531544, -------------- SYN_REPORT ------------

Note that 'j' appears in front on Event on one of the lines, whereas previously it did not.

sezanzeb commented 3 years ago

Thanks. There can be multiple of those devices, yes. Since evtest reports the events I guess key-mapper does what it is supposed to do. I created a new label for all issues of that kind:

https://github.com/sezanzeb/key-mapper/issues?q=is%3Aissue+label%3A%22environment+incompatibility%22+

I think the only way to fix this is to get somebody on board who knows X11 internals. Since evtest shows the events I don't know what I can do to fix this, for all I know this is a bug in the environment for whatever reason.

WilliamHe23 commented 3 years ago

Right, it does seem odd why it would work some times and not others, and why it seems to possibly have a relationship the command and other factors. It may just be something to do with my system, since I got the same results when testing different keyboards.

So am I understanding it correctly that because evtest shows the events, that means that the correct keystrokes are getting passed along by Key Mapper, but for some reason my system is not correctly processing them so they do not appear?

sezanzeb commented 3 years ago

So am I understanding it correctly that because evtest shows the events, that means that the correct keystrokes are getting passed along by Key Mapper, but for some reason my system is not correctly processing them so they do not appear?

I think this is correct, but I really only know some python-evdev stuff, the things that happen in the kernel and environment are completely unknown to me. So my opinion on this is not something to bet on

WilliamHe23 commented 3 years ago

Got it, I'm not super familiar with this either, but at least I can get it working sometimes (like right now).