Score:1

xbindkeys double counting keypresses (not distinguishing between press and release)

us flag

I have a Logitech g502 Proteus mouse, and want to use the "Back" and "Forward" mouse buttons (typically used with browser).

I verified with xev that the mouse button presses are detected. I installed xbindkeys and using various online references setup .xbindkeysrc to map the mouse buttons (6 and 7) to press a series of keys to emulate the correct behavior.

"xte 'key t'"
     b:6 + Release

"xte 'keydown Alt_L' 'keydown Right' 'keyup Right' 'keyup Alt_L'"
     b:7 + Release

The problem, the remap is executed twice, once on press, and once on release. I thought the "Release" modifier would solve this, but it's still ongoing. I verified this by putting in a dummy remap to the letter 't', holding down the mouse button, and seeing one 't' inserted, followed by another 't' on release when I let go.

I did kill all the xbindkeys processes before testing also. running xbindkeys --verbose --nodaemon shows an unusual behavior, in that a press and release are both recorded when I press a mouse button, despite my not releasing the depressed mouse button. The following looks like I pressed and released the button twice, but it was only once:

starting loop...
Button press !
e.xbutton.button=6
e.xbutton.state=16
Button release !
e.xbutton.button=6
e.xbutton.state=16
"xte 'key t' "
    Release + m:0x0 + b:6   (mouse)
got screen 0 for window 510
Start program with fork+exec call

Button press !
e.xbutton.button=6
e.xbutton.state=16
Button release !
e.xbutton.button=6
e.xbutton.state=16
"xte 'key t' "
    Release + m:0x0 + b:6   (mouse)
got screen 0 for window 510

The xte lines themselves on the command line print only one 't.' Any ideas on how to fix/workaround this?

Score:0
ru flag

I use xbindkeys in a similar way on one PC to to workspace switching with the mouse side buttons. Looking at my config I see I have & at the end of my xte config lines which I believe runs xte in the background. Perhaps you need that? I am not at that PC to check what happens if I remove tha & from my config:

        # Mouse button 8 (the "back" side button)
        # Re-map to super+page-down (move to workspace down)
        "xte 'keydown Super_L' 'key Page_Down' 'keyup Super_L' &"
          b:8

        # Mouse button 9 (the "forward" side button)
        # Re-map to super+page-up (move to workspace up)
        "xte 'keydown Super_L' 'key Page_Up' 'keyup Super_L' &"
          b:9
traycerb avatar
us flag
thanks for the reply, I tried that and it gave an error `sh: 1: amp: not found` so still searching for some explanation. I am doing this in a Hyper-V VM, but no other keys, mouse or otherwise, have this behavior. I tried replacing `b:6` (backwards mouse button) with `b:1` (mouse left click) and it works as intended. Holding left click down, I only get a "Button press" state, until I release it.
traycerb avatar
us flag
EDIT: Scrutinzing the `xev` output shows button 6 & 7 register as press AND release even when just pressed. So perhaps` xkeybind` is behaving as expected, but why does the mouse have this behavior?
Score:0
us flag

Well it seems like this not an issue with Ubuntu or xbindkeys, but with the xrdp mouse driver. I am using an MS Hyper-V VM running Ubuntu 20.04.2, and I came across the following issue on github where someone reports my problem exactly, 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."

xrdpmouse: ButtonPress/ButtonRelease event sent twice

So it seems like there's no easy fix, which is unfortunate.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.