input-remapper
input-remapper copied to clipboard
sezanzeb
Mapping mouse movements
I am not seeing this in the mapping list so please let me know if I'm missing something but it would be very nice to be able to map the "scroll method" and "scrolling button" that libinput uses to a mouse button so that the mouse movement can be used for vertical and horizontal scroll such that could be done with xinput set-prop <devID> "libinput Scroll Method Enabled" 0, 0, 1 && xinput set-prop <devID> "libinput Button Scrolling Button" <button>
I think I could add a feature similar to mapping joysticks (see screenshots). To have a dropdown to set it either as "Mouse", "Joystick", "Wheel" or "Buttons"
(The joystick mode might be a bit more complicated to implement, but maybe the debouncer can make sure a resting mouse is injecting a resting joystick event, just like what would be required for the buttons mode already)
The easiest one to implement would be a "Buttons" mode, which could then be mapped like Shift + Mouse Left: wheel(left, 1)
But I need to investigate a bit, how mouse movements would be forwarded in buttons mode if they don't trigger a combination and such, because without hitting that key it should still behave like a regular mouse.
Thanks for looking into it! I think the "Buttons mode" idea is exactly what I would use it for. I have a ball mouse that just begs to have the ball actionable as a scroll wheel.
Tried it out a bit today. At first it worked surprisingly well already, but it ends up feeling quite odd in my opinion.
Joystick and mouse movement events aren't that different, which is why it wasn't hard to get to this point.
If you map a certain direction of the mouse, the mouse won't be able to move into that one anymore. But that can be avoided when mapping a combination between a button and the movement
It's on this branch: https://github.com/sezanzeb/key-mapper/tree/map-mouse-movement
If you mapped "button right" + "mouse up" to "b", it makes a difference if you first move the mouse or first press the button. It's because the existing way of doing things has been designed for a somewhat different use case after all.
- button right first: mouse stops moving, b is written
- mouse movement first: mouse continues to move, b is written
The alternative would be to require "button right" to be pressed before moving the mouse (just like for any other combinations of keys), but using it this way didn't feel so good.
So I'm not very keen on getting it this way into key-mapper any time soon. If I offered that, I wonder how long it will take until gestures and such would be a requirement. I'd probably rather have this functionality offered by plugins once that works. https://github.com/sezanzeb/key-mapper/issues/80
Interesting findings. I think that at least for scrolling, the only use is the first one where the button is depressed prior to mouse movement but I can see how that might feel awkward if you're already starting to move the mouse as you depress the button. Are you using a ball mouse or a regular one? I think that it will feel particularly strange with a regular mouse. But, hey, plugins are also a great way to go about this and I'm all about extensibility.
regular one.
plugins would be great. lets see how that will continue. 1.0.0 which is apparently going to land in the debian repos won't get plugin support, that's for sure.
Congrats on the repo addition! Well, thank you for providing that branch nonetheless. I'm not very git savvy yet but I may crack my fingers and see if I can get it running locally so I can play with it.
This should be possible on the beta branch. Just need to add a RelToRelHandler and a RelToAbsHander which I pan to do anyway.
@sezanzeb you might want to add this to the beta project
Closing because this can be done in beta. It will arrive on main probably in February