WIP: MacOS input consistency, request for comment

[NeoTheFox]

Hello!
I noticed a huge input inconsistency when going from Sway -> MacOS:

1. The inverted scrolling (despite natural scrolling being disabled in MacOS)
2. Mouse sensitivity being extremely low (despite both systems using the exact same resolution)

I'm not a Rust developer, so I don't know what would be the best way to approach it - these are just tiny changes that made my systems feel consistent.
Ideally, the issue is somehow related to DPI and reading the system config, but I propose adding two new config options:

1. mouse_mod - a float value that the actual relative movement gets multiplied by on a given client
2. invert_scroll - a simple flag that inverts the scrolling direction so that you can make it consistent across platforms.

Right now the input-emulation is split away from the config, so I couldn't figure out a way to add these options without excessive coupling. Any comments are welcome.

[feschber]

Ideally, I'd want to do this as a general pre / post-processing step (#156).
This means, I'd like it to be applied directly in the consume() function before being passed to the device specific backends rather than any platform specific code.

The configuration options would need to be passed to the emulation either when instantiated src/service.rs#L118 or preferably as a new FrontendRequest variant which could be used to modify these values in the InputEmulation struct at runtime.

Frontend requests are handled here. We would need a new function on the emulation to pass the request to the actual input-emulation task in EmulationProxy.

Finally, the frontends (gtk and cli) could then be adjusted to generate these Requests.

Let me know if you feel comfortabl implementing this (or any part of it would be fine, really). There is quite a few components involved unfortunately.

I'm considering moving the whole input-emulation proxy that handles disabled input-emulation state into the input-emulation create eventually, which might make things like this easier to implement.

[NeoTheFox]

Thank you for the input!
I'll look into implementing it this way then

[NeoTheFox]

I've partially implemented the mouse_mod and created a new structure for InputConfig, but since now the input is consistent due to #346, is the scrolling inversion the only logical input config to have? Or would querying the natural scrolling config option for the MacOS itself be a better option?

[feschber]

Lets look at it this way: I would consider the inconsistent movement and inverted scrolling bugs. However, regardless of this being fixed, it would still be nice to have configurable multiplier / touchpad inversion (#156).

My general idea behind lan-mouse is that everything should feel as though the input devices were directly attached to the target. Unfortunatelly the reality is that in many cases this is not how it currently works. (E.g. MacOS and Windows capture accelerated mouse input right now).

For the touchpad this would mean that the scrolling direction should be the same as on the physical touchpad of the target device - reading the natural scrolling setting somehow may very well be the correct way to do this, yes.

So really, we have two things to do here in my eyes:

1. Make the touchpad behave correctly on macos (as described above)
2. Implement input postprocessing as in configurable multiplier / inverted touchpad, etc. (maybe at some point there could be configurable keymappings as well)

Now which of these you want to implement is totally up to you. If you say, you are happy with the state it is in right now or simply want to invert the default scrolling direction, that'd be fine as well.

[NeoTheFox]

My initial idea was implementing a modifier for the mouse (one can call that linear acceleration), but if we're going to call this acceleration then a it's a more complex topic, and different devices expect different profiles. But since I'm already working on this we can call it a "hack" for now and I'll just finish doing what I'm doing.

The natural scrolling thing comes down to being opinionated, so the inversion flag is still a good idea. Since MacOS (just like some other compositors mentioned in #156) doesn't allow setting any pointer configuration to the virtual input itself one can argue that someone might prefer having the natural scrolling on the touchpad, when used on its own, but having it off when using lan-mouse to stay consistent with other computers.

Rebasing.

[feschber]

Ideally, every capture backend would capture unaccelerated input and every emulation backend would emulate the input as though it was coming from a phyiscal device. Then all the input settings from the target device should carry over and things would work as expected. Since this is not the case and may never be in some instances, I guess it is a good idea to make these things configurable.

[NeoTheFox]

Implemented cleanly in a different branch, closing this

[feschber]

Why not push to this branch?

[NeoTheFox]

Dirty history due to my first hacky implementation

[feschber]

It's no problem but for the future: You can simply work on a different local branch, then hard reset your other branch to the new one and force push the changes. Or you could setup the new branch to track the remote one and then force push.

[NeoTheFox]

Ah, sorry, I've done the first thing that came to mind really