xorgxrdp
xorgxrdp copied to clipboard
xrdpmouse: ButtonPress/ButtonRelease event sent twice
4.19.45-1-MANJARO OS: Manjaro 18.0.4 Illyria DE: Xfce4 pacman -Qi xrdp: 0.9.11-1
xev -event button
shows that for a single click (press+release) of a Logitech MX Vertical mouse of button 6 and 7 (forward/backward buttons) two ButtonPress and ButtonRelease events are sent:
ButtonPress event, serial 25, synthetic NO, window 0x3600001,
root 0x38a, subw 0x0, time 5226335, (124,98), root:(1338,740),
state 0x10, button 6, same_screen YES
ButtonRelease event, serial 25, synthetic NO, window 0x3600001,
root 0x38a, subw 0x0, time 5226336, (124,98), root:(1338,740),
state 0x10, button 6, same_screen YES
ButtonPress event, serial 25, synthetic NO, window 0x3600001,
root 0x38a, subw 0x0, time 5226449, (124,98), root:(1338,740),
state 0x10, button 6, same_screen YES
ButtonRelease event, serial 25, synthetic NO, window 0x3600001,
root 0x38a, subw 0x0, time 5226449, (124,98), root:(1338,740),
state 0x10, button 6, same_screen YES
Is this a bug of the xrdmouse driver? In my case I'd like to set up a ~/.xbindkeysrc:
"xdotool key 'alt+Left"
b:6
"xdotool key 'alt+Right'"
b:7
to enable the forward/backward functionality. But due to the events sent twice leads to a forward/backward step of 2....
I work in a VM, so xinput --list
shows
xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ xrdpMouse id=6 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ xrdpKeyboard id=7 [slave keyboard (3)]
I'm experiencing this to. I've tried RDP over FreeRDP and Microsoft Remote Desktop and both have the same behaviour: Pressing (and holding) thumb buttons fire pressed and followed directly by a release. Releasing buttons again fire pressed + released events. Also this is on physical hardware, not a VM.
Snipped from logs:
[ 1182.529] (II) Loading /usr/lib/xorg/modules/drivers/xrdpdev_drv.so
[ 1182.529] (II) Module XRDPDEV: vendor="X.Org Foundation"
[ 1182.529] compiled for 1.20.3, module version = 0.2.9
[ 1182.529] ABI class: X.Org Video Driver, version 24.0
[ 1182.529] xrdpdevSetup:
[ 1182.529] (II) LoadModule: "xrdpmouse"
[ 1182.529] (II) Loading /usr/lib/xorg/modules/input/xrdpmouse_drv.so
[ 1182.529] (II) Module XRDPMOUSE: vendor="X.Org Foundation"
[ 1182.529] compiled for 1.20.3, module version = 0.2.9
[ 1182.529] Module class: X.Org XInput Driver
[ 1182.529] ABI class: X.Org XInput driver, version 24.1
[ 1182.529] rdpmousePlug:
[ 1182.529] (II) LoadModule: "xrdpkeyb"
[ 1182.529] (II) Loading /usr/lib/xorg/modules/input/xrdpkeyb_drv.so
[ 1182.529] (II) Module XRDPKEYB: vendor="X.Org Foundation"
[ 1182.529] compiled for 1.20.3, module version = 0.2.9
[ 1182.529] Module class: X.Org XInput Driver
[ 1182.529] ABI class: X.Org XInput driver, version 24.1
And testing with xev
ButtonPress event, serial 34, synthetic NO, window 0x5400001,
root 0x29a, subw 0x0, time 7931027, (345,568), root:(1310,575),
state 0x10, button 8, same_screen YES
ButtonRelease event, serial 34, synthetic NO, window 0x5400001,
root 0x29a, subw 0x0, time 7931028, (345,568), root:(1310,575),
state 0x10, button 8, same_screen YES
ButtonPress event, serial 34, synthetic NO, window 0x5400001,
root 0x29a, subw 0x0, time 7933280, (345,568), root:(1310,575),
state 0x10, button 8, same_screen YES
ButtonRelease event, serial 34, synthetic NO, window 0x5400001,
root 0x29a, subw 0x0, time 7933280, (345,568), root:(1310,575),
state 0x10, button 8, same_screen YES
It's ugly and not a proper solution but you can do something like this in the meanwhile (with a lock file): https://askubuntu.com/a/1017980
Well, it seems like I have the same problem, using a (wired) Logitech g502 Proteus Core mouse, also in a VM environment (Ubuntu 20.04.2 LTS, Win 10 Hyper-V). I get the following output from xev
pressing left click ONCE and mouse's "forward" button ONCE; notice the doubled output for button 7:
$ xev | grep 'button'
state 0x10, button 1, same_screen YES
state 0x110, button 1, same_screen YES
state 0x10, button 7, same_screen YES
state 0x10, button 7, same_screen YES
state 0x10, button 7, same_screen YES
state 0x10, button 7, same_screen YES
I wish I had a solution, that debounce hack above seems like it would potentially cause other complications.