mute one mapping while another is triggered

[v1s1n]

Heyo!

I use a trackball primarily, and this software is a godsend when it comes to setting it up to function properly with my DAW and games (since they often don't recognize extra mouse buttons). However, I've run into an issue. On many trackball mice, there is a function that allows you to hold down a key on the mouse and scroll with the trackball. I don't see a way to use both mouse acceleration curves (via the analog axis function) and use the axis to scroll, without the mouse moving while I scroll.

Currently, I switch between two profiles. (one for desktop use, with button scroll, and one for gaming, with acceleration) It would be nice if input remapper allowed me to have one mapping override another, so that I could "mute" the acceleration curve mapping while the scroll button is in use. If there's a workaround for this, that'd also work for now, but I think it would worth it to be able to set up mutes like this -- if it's possible.

Thanks!

[sezanzeb]

So the problem is that this mapping:

Still keeps moving the mouse, when "Button EXTRA" is held down, right?

[v1s1n]

Exactly, yes.

[sezanzeb]

I see. There is potentially a solution, requiring a few things:

• Add a new suppress member to InputEvent objects that can be set to True, that defaults to False
• Add a suppress(while, type, code, value) macro that sets event.suppress = True to all incoming events that match EV_REL using a listener. Like suppress(hold(), EV_REL), while the while macro is running. while would allow to do something like wait(1000) or hold() to keep the suppression active for some defined amount of time, or hold_keys(a) to make the button useful in some other way.
• Don't inject events that have event.suppress True

This would require quite some changes

• There is existing "suppress" logic in the handlers. It requires some thought if this becomes redundant with this change
• All places where InputEvents are written need this check. All of them need new or modified automated tests
• InputEvents are frozen currently, so their attributes cannot be modified after construction. I don't know how important this is.
• Writing the new "SuppressTask" class isn't difficult luckily
• The "handled" logic of the event_reader might be redundant with this change. At the very least, it requires more investigation there as well.
• I can't tell off the top of my head if this is incompatible with existing features.

I have tried something similar with the mod_tap macro, but didn't like it and went for a different solution there. So... I don't know. I'm documenting my thoughts on this if someone with lots of motivation and python knowledge wants to work on this. But bear in mind that it might turn out to be a dead end or a solution that isn't very desirable.

Then, map Button EXTRA to something like suppress(hold_keys(whatever), EV_REL), depending on what you want.