Summary: | libinput handles mouse button remapping and button scrolling in the wrong order | ||
---|---|---|---|
Product: | Wayland | Reporter: | freeyourmind |
Component: | libinput | Assignee: | 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
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. ftr, waiting for you to comment on the first 2 paragraphs above 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? 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? 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"? (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 ping? closing after 3 weeks of silence 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.