Open Inky1003 opened 2 years ago
Thanks for reporting the issue!
sends the "go back" and "go forward" commands
In addition to the keys you mapped it to?
This don't let me scroll some pages because It sends the "go back" and "go forward" commands, even with the injection.
please run sudo evtest
and select the device that says "forwarded". Then press your mouse buttons that you mapped previously.
It think I never put effort into handling EV_MSC events correctly, which might cause the issues now.
In addition to the keys you mapped it to?
My mouse has, beyond the 2 common buttons, 2 other buttons that do the "go back" and "go forward" buttons on web browsers, which are annoying. I mapped them to wheel(down, 10)
and wheel(up, 10)
.
please run sudo evtest and select the device that says "forwarded". Then press your mouse buttons that you mapped previously.
I think i misunderstanded the inputs, but... when I said this:
For my mouse remapped input (shown as "input-remapper Logitech USB Trackball forwarded") It says:
I'm quite sure It's the forwarded device.
I forgot to mention, both commands of wheel and go back/forward are sent by their respective buttons in input remapper and the system. The problem is that the go back/forward commands shouldn't be sent (which are system ones).
Ok thanks, don't worry about the evtest.
Please try to install the no-ev-msc branch. To see if you installed it correctly, input-remapper-control --version
should print "1b6cf4d3b9d92d1195f6218e11bc2bf0651a255c". Then restart the service sudo systemctl restart input-remapper
and try again.
If this is working the todo is to stop EV_MSC events for mapped keys, and maybe as a second step to inject EV_MSC events that match the mapping for consistency.
It this is still not working, I'll give you a short guide about the evtest and the "forwarded" device to see if there are actually both wheel and side-button events being inejcted for whatever reason.
Okay, I'm quite confused. Nothing says this is the no-ev-msc branch, but the folder I downloaded that says It's from the branch, and no more EV_MSC events are sent (or at least detected by evtest). I did:
$ input-remapper-control --version
input-remapper 1.4.1 https://github.com/sezanzeb/input-remapper
python-evdev 1.4.0
sudo systemctl restart input-remapper
sudo evtest
, and no more EV_MSC commands were sent, neither EV_MSC commands nor any other was sent by the forwarded device when I clicked the mapped buttons.Basically, It didn't work, but the events are not sent anymore.
ok, so EV_MSC is not of interest. I frankly have no idea what EV_MSC is supposed to be
this is incredible, I wonder how chromium apps know that you clicked that button.
I just tried it in vivaldi (chromium based browser) and could not reproduce the issue unfortunately
Would you like to contact in another place to try to figure out the issue? I'm really on need to fix that... Of course we will go back here and update the issue after that, and I think that would be better... Maybe Jitsi or a Matrix client? Send me an email, It's on my profile.
Also, I remind that some years ago I used input-remapper (when It wasn't yet input-remapper but key-mapper, and debian packages were still a dream) and on openSUSE(don't remember the DE) the keys were working just fine and not sending forward the undesired events... Was something you weren't forwarding, so?
Oh, I didn't realize that you also tested the forwarded device before already
To figure out if it was an update of input-remapper that broke it or an update of chromium, you could backup your ~/.config/input-remapper
directory and then install older versions. In manjaro you'll have to checkout at the specific tag (for example git checkout 1.3.0
) and then run the installation steps as shown in the readme. This would help to pin down the problem. You might need to delete the config directory before downgrading in order to get input-remapper/key-mapper to start.
I'm still reproducing the bug with older versions... maybe this is a bug with the event that is being sent?
What a confusing thing, now I'm not running any input-remapper and no events aren't being sent! Neither the go back/forward nor the scroll ones!
Did you restart the service after installing a different version? Maybe that's why you are reproducing it with old versions as well
I killed all the services with pkill before running again... But note that without input-remapper no events are sent, so probably this may be a event's problem?
if input-remapper-service is not running, then it should look somewhat like this:
โ ~ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Power Button
/dev/input/event1: Power Button
/dev/input/event2: Logitech USB Keyboard
/dev/input/event3: Logitech USB Keyboard Consumer Control
/dev/input/event4: Logitech USB Keyboard System Control
/dev/input/event5: USB Optical Mouse
/dev/input/event6: Microsoft Microsoftยฎ Nano Transceiver v2.0
/dev/input/event7: Microsoft Microsoftยฎ Nano Transceiver v2.0 Mouse
/dev/input/event8: Microsoft Microsoftยฎ Nano Transceiver v2.0 Consumer Control
/dev/input/event9: Microsoft Microsoftยฎ Nano Transceiver v2.0 Consumer Control
/dev/input/event10: Microsoft Microsoftยฎ Nano Transceiver v2.0 System Control
/dev/input/event11: PC Speaker
/dev/input/event12: HD Pro Webcam C920
Select the device event number [0-12]: 5
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1bcf product 0x5 version 0x110
Input device name: "USB Optical Mouse"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 273 (BTN_RIGHT)
Event code 274 (BTN_MIDDLE)
Event code 275 (BTN_SIDE)
Event code 276 (BTN_EXTRA)
Event type 2 (EV_REL)
Event code 0 (REL_X)
Event code 1 (REL_Y)
Event code 6 (REL_HWHEEL)
Event code 8 (REL_WHEEL)
Event code 11 (REL_WHEEL_HI_RES)
Event code 12 (REL_HWHEEL_HI_RES)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1646415077.922869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90005
Event: time 1646415077.922869, type 1 (EV_KEY), code 276 (BTN_EXTRA), value 1
Event: time 1646415077.922869, -------------- SYN_REPORT ------------
Event: time 1646415078.130868, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90005
Event: time 1646415078.130868, type 1 (EV_KEY), code 276 (BTN_EXTRA), value 0
Event: time 1646415078.130868, -------------- SYN_REPORT ------------
Event: time 1646415080.042865, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90004
Event: time 1646415080.042865, type 1 (EV_KEY), code 275 (BTN_SIDE), value 1
Event: time 1646415080.042865, -------------- SYN_REPORT ------------
Event: time 1646415080.234867, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90004
Event: time 1646415080.234867, type 1 (EV_KEY), code 275 (BTN_SIDE), value 0
Event: time 1646415080.234867, -------------- SYN_REPORT ------------
I didn't noticed that... Now I redid, and the issue still happens, but I was thinking... maybe this issue is libinput related? Maybe in the past I used evdev and not libinput?
I said that because Xorg reports I'm using libinput, and libinput shows some more things:
event21 POINTER_SCROLL_WHEEL +0.000s vert -15.00/-120.0 horiz 0.00/0.0 (wheel) event21 POINTER_SCROLL_WHEEL +0.061s vert -15.00/-120.0 horiz 0.00/0.0 (wheel) event21 POINTER_SCROLL_WHEEL +0.416s vert 15.00/120.0 horiz 0.00/0.0 (wheel) event21 POINTER_SCROLL_WHEEL +0.478s vert 15.00/120.0 horiz 0.00/0.0 (wheel)
I wonder if one of that 2 numbers after "vert" are getting the pages forward and backward, instead of just scrolling... Anyways, is there any way of getting evdev driver again to work with my mouse?
I honestly never messed around with libinput and the likes, so I can't say anything about that. I guess the number is the amount of wheel movement, it would surprise me if this causes the browser to go backward or forward in history.
Still no clue what is happening here, maybe you could give wayland a try
I'm afraid Wayland could be not good for me... Also, Wayland do use libinput.
Btw, I'll continue checking possible causes for that...
Update: Got to change my mouse driver to evdev and things seem to work different: Clicking the buttons without the service seems to scroll a bit and stop. Clicking the buttons with input-remapper service seems to do the same thing as before.
Weirder than before...
Are you really sure that there is no input-remapper service present? sudo pkill -f input-remapper
Yes, there aren't... Maybe It's the mouse wheel emulation?
Still, I have to congratulate your scrolling. Despite It sends another event with the scroll, It works better.
Summary:
They work-ish. Basically they work but the old events are still sent to chromium/electron based apps like Discord, Vivaldi, etc. This don't let me scroll some pages because It sends the "go back" and "go forward" commands, even with the injection.
Share some logs please:
input-remapper-control --version
which linux distro (ubuntu 20.04, manjaro, etc.) Manjaro
echo $XDG_SESSION_TYPE
x11which desktop environment (gnome, plasma, xfce4, etc.) KDE Plasma 5.24
sudo ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 mar 1 09:45 /proc/1/exe -> /usr/lib/systemd/systemdpaste the affected preset .json file from ~/.config/input-remapper/presets marcia.zip
sudo pkill -f input-remapper-service && input-remapper-gtk -d
, start the injection and hit your key. Then share that log.sudo evtest
would also be interesting while the first command is still running, to see how your mappings are injected.For the mouse device It says:
For my mouse remapped input (shown as "input-remapper Logitech USB Trackball forwarded") It says:
And for a "mouse" remapped input (shown as "input-remapper mouse") It says:
PS: I run the test clicking once the two buttons I've mapped in marcia.json
Edit: This problem is quite old, but I hadn't courage to submit the issue...