revert mouse

[nadenislamarre]

not sure it is already possible or not.
i don't find how.

is it possible to revert an axis ?
basically, map abs:x to abs:-x (because with my device, the x axis is reverted compared to my needs)

[KarsMulder]

Not possible on the current stable version. I just added a feature to do this to the main branch. The tentative syntax is:

--map abs:x abs:x:-x

Now a somewhat confusing part of this syntax is that the last x just means "whatever the value value was", and the minus means "-1 times that value". The last x does not mean "the value of the x axis", so to invert the y axis, you would also use:

--map abs:y abs:y:-x

The magic x multiplier in the value has the same consistent syntax as the magic d multiplier (which, ironically, is already stable), but since users will probably use it mainly for inverting/accelerating the x/y axes, I can imagine some poor user getting confused and trying to write --map abs:y abs:y:-y.

I could either write a specialised helpful error message for that case, or reconsider the syntax of this feature.

[nadenislamarre]

In fact it is not exacly *-1
It is more max_value - x to revert thé axis.

[nadenislamarre]

In case min IS positiv

[KarsMulder]

This feature has now been added to the main branch. You can now e.g. write --map abs:z abs:z:127-x to map some event's value to 127 minus that event's value, which would invert the axis if abs:z were to have a range of 0~127.

[puffnfresh]

@KarsMulder since evdev events are registered with min/max values, we theoretically know the min/max. Could we add/generate another placeholder (e.g. z_min) so that we don't have to hard code the 127?

[KarsMulder]

@puffnfresh I suppose that it wouldn't be impossible to implement, but with the current internal API, it isn't simple to implement it in a way that:

1. Is correct in all cases, i.e. including cases where multiple devices can generate abs:z events, which in turn are being transformed by other maps before reaching a map containing z_min.
2. Does not impose a measurable performance penalty for the majority of the users who won't use this feature.

The key issue is: parsing the input arguments like abz:z to internal data structures, propagating the event capabilities, and propagating the events, happen at separate stages of the program. A feature like this blurs the line between those stages; e.g. it is currently assumed (and enforced by the compiler) that the propagation of event capabilities does not modify the event stream, and that assumption would need to change to make this work, along with at least one algorithm that relies on it.

In short, I think that I am not going to work on that feature for now because the amount of spaghettiness required to make it work outweighs the feature's utility.

[nadenislamarre]

working for me. i can close.