Is it possible to map a mouse's relative position to a controller's analog stick absolute position? about evsieve HOT 2 CLOSED

This is currently not possible.

It does seem like a feature worth adding, however it is not simple to extend the --map syntax to make this possible due to details of implementation, the evdev protocol, and UX.

So I am considering adding a --rel-to-abs argument (relatedly: I think it was a a mistake to add relative maps instead of a --abs-to-rel argument), which would look something like either...

    --input /dev/input/by-id/[mouse] \
    --rel-to-abs range=0~255 speed=1 \
    --output

... or ...

    --input /dev/input/by-id/[mouse] \
    --rel-to-abs rel:x abs:x:0~255 speed=1 \
    --rel-to-abs rel:y abs:y:0~255 speed=1 \
    --output

... but I'm still figuring out some UI aspects of it. (I'll follow up on this later, I just thought I should write something to show that this issue isn't getting ignored...)

from evsieve.

I have now implemented the --rel-to-abs argument on the master branch according to the second plan:

    --input /dev/input/by-id/[mouse] \
    --rel-to-abs rel:x abs:x:0~255 speed=1 \
    --rel-to-abs rel:y abs:y:0~255 speed=1 \
    --output

I'm not sure if I actually like the current design though. I may significantly change the API before this reaches stable, but you can already use it if you don't mind your scripts getting broken in a future update.

Maybe I should make more generic and rename it to --add-to instead. Or maybe it should be more specific and have a way to map rel:x → abs:x, rel:y → abs:y, rel:z → abs:z, rel:rx → abs:rx, rel:ry → abs:ry, rel:rz → abs:rz without using six arguments, one for each of those.

It currently requires you to define a range for the output values, because the evdev protocol requires you to define which range the values can take. But maybe it is possible to figure out some sensible default range if the user does not provide one?

Relatedly, currently the initial value of the axes is zero. Maybe it should instead be the center of the output range, which makes sense for rel-to-abs conversion, but perhaps not if I were to rename the argument to something generic like --add-to.

Also undecided on whether I should keep the speed clause. It currently causes some i32-to-f64-to-i32 conversions in the internal mechanics, even if the default speed of 1 is used (which I imagine to be the by-far-most-common usage.) Those conversions don't use that much computing power, but it still feels a bit bloaty. Multiplying values by a factor is already possible with --map anyway (e.g. --map abs ::2x will double the value of all abs-type events.)

from evsieve.