Bug 100042

Summary: libinput handles mouse button remapping and button scrolling in the wrong order
Product: Wayland Reporter: freeyourmind
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: medium CC: andris.zeila, peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description freeyourmind 2017-03-03 03:20:20 UTC
libinput 1.6.2 (which isn't a choice in Version above)
xf86-input-libinput 0.24.0

With button scrolling enabled by running:

xinput set-prop DEVICE "libinput Scroll Method Enabled" 0 0 1
xinput set-prop DEVICE "libinput Button Scrolling Button" 3

xinput will synthesize scrolling events (buttons 4 5 6 and 7) when the scrolling button is held down and the pointer is moved.

With the appropriate command to remap buttons:

xinput --set-button-map DEVICE 1 2 3 8 9 10 11

xinput can remap buttons, in this case 4, 5, 6 and 7 are remapped to 8, 9, 10 and 11.

Unfortunately, the button remapping happens *after* the synthetic presses from button scrolling are created. If all the commands listed above are run, then holding the scrolling button and moving the pointer produces events for buttons 8, 9, 10, 11. This makes it impossible to use button scrolling along with remapping the physical buttons.

Evdev had the more preferable behavior of not remapping the synthetic events  from its "Evdev Wheel Emulation", which allowed the physical 4, 5, 6 and 7 buttons to be mapped elsewhere while button scrolling could produce events for 4, 5, 6 and 7.
Comment 1 Peter Hutterer 2017-03-06 00:22:12 UTC
with that button map, the behaviour you describe is what I'd expect, logical buttons 4-7 are reserved for scroll wheels. given that button mapping is handled in the server and not in the evdev driver, I'd expect the same behaviour from the evdev driver.

Any actual button event from the scroll button (other than left/middle/right) should come in as logical buttons 8 or above and those buttons can be remapped.


(In reply to freeyourmind from comment #0)
> Evdev had the more preferable behavior of not remapping the synthetic events
> from its "Evdev Wheel Emulation", which allowed the physical 4, 5, 6 and 7
> buttons to be mapped elsewhere while button scrolling could produce events
> for 4, 5, 6 and 7.

fwiw, this is a difference in design. evdev did the emulation itself, so it had different access to the buttons. the xorg-libinput driver merely takes the pre-emulated events and remaps buttons, so it doesn't necessarily know which physical button was pressed. That's not something that's fixable in the current design.
Comment 2 Peter Hutterer 2017-03-15 23:21:32 UTC
ftr, waiting for you to comment on the first 2 paragraphs above
Comment 3 freeyourmind 2017-03-17 19:54:49 UTC
Sorry, didn't realize you wanted more input. I've reverted my system back to evdev, and can confirm the difference in behavior. What else from my end would help?
Comment 4 Peter Hutterer 2017-03-19 22:33:08 UTC
You'll need to rephrase what you actually want to do, because the set-button-map command in comment #0 doesn't quite make sense to me, it would remap scroll up to the back button, etc. Physical button mappings are a bit quirky but you always have to skip 4-7 (unless theres a bug in evdev somewhere). So what's the evdev configuration you currently have?
Comment 5 freeyourmind 2017-03-20 00:04:09 UTC
Sorry, you're right, I misunderstood my own config when trying to update to libinput. With evdev I'm running:

xinput set-prop "ELECOM ELECOM TrackBall Mouse" "Evdev Wheel Emulation" 1
xinput set-prop "ELECOM ELECOM TrackBall Mouse" "Evdev Wheel Emulation Button" 3
xinput set-prop "ELECOM ELECOM TrackBall Mouse" "Evdev Wheel Emulation Axes" 10 11 4 5
xinput --set-button-map "ELECOM ELECOM TrackBall Mouse" 1 2 3 4 5 9 8 10 11 6 7

"Evdev Wheel Emulation Axes" is the feature I can't find an equivalent for with libinput. With evdev, I map the horizontal scrolling from the wheel emulation to buttons 10 and 11, Then I rebind sets of buttons 6, 7 -> 8, 9 -> 10, 11 -> 6, 7, so the 10 and 11 from the wheel emulation become 6 and 7, and the original 6 and 7 buttons can be mapped elsewhere.

The closest thing I can see for libinput is "HorizontalScrolling" which would let me turn off horizontal scrolling from wheel emulation, then I could still rebind 6 and 7.

Does libinput have a replacement for evdev's "Evdev Wheel Emulation Axes"?
Comment 6 Peter Hutterer 2017-03-20 04:25:47 UTC
(In reply to freeyourmind from comment #5)
> "Evdev Wheel Emulation Axes" is the feature I can't find an equivalent for
> with libinput. With evdev, I map the horizontal scrolling from the wheel
> emulation to buttons 10 and 11, Then I rebind sets of buttons 6, 7 -> 8, 9
> -> 10, 11 -> 6, 7, so the 10 and 11 from the wheel emulation become 6 and 7,
> and the original 6 and 7 buttons can be mapped elsewhere.

The original 6/7 buttons? No driver (evdev included) should map a physical button to logical button 6 or 7. Right now, this config looks like you're trying to map wheel emulation scrolling to 6/7 (albeit indirectly) and horizontal scroll wheels to buttons 9 and 8 (forward, back). for a mouse with six physical buttons, your default logical mapping should be 1 2 3 8 9 10, i.e. your sixth button should be mapped to 10 by default. you never need to touch logical buttons 4-7
Comment 7 Peter Hutterer 2017-04-03 01:25:41 UTC
ping?
Comment 8 Peter Hutterer 2017-04-27 06:09:45 UTC
closing after 3 weeks of silence
Comment 9 Andris Zeila 2018-04-06 08:28:32 UTC
Too bad :/ I have re-mapped mouse wheel left to middle click (with xinput) and did not notice it at first. 99% of time I'm using only vertical scrolling, so it appeared to work, but with small glitches. My other mouse has built-in button remapping and of course was working fine - so initially I thought my mouse is broken.

Tried to disable 'libinput Horizontal Scroll Enabled', but that seems to simply disable all wheel left/right button events instead of disabling horizontal scrolling emulation as I hoped.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.