Implemented mouse config

[NeoTheFox]

Add two options: mouse_mod - sets a linear acceleration for the emulated mouse invert_scroll - inverts the scrolling direction for the emulated mouse

Hopefully it helps to make the pointer more consistent across multiple devices.

Previously discussed in #339

[feschber]

There is one more thing:

Since we are making changes to the configuration, we should think about the names a bit more. I'd prefer these options to be under a different section and name them a bit differently like this:

# transformations applied to input events received from other devices
[event_post_processing]
mouse_sensitivity = 1.0
invert_scroll = true

This would later enable a similar section for event pre transformations (when being sent to other devices):

# transformations applied to input events sent to other devices
[event_pre_processing]
mouse_sensitivity = 1.0
# linear_acceleration_factor = 1.2
# scroll_sensitivity = 0.3
invert_scroll = false

Maybe you can come up with some better names, but I find mouse_mod a bit indescriptive and would prefer sensitivity here.

[feschber]

Maybe input_post_processing would be a better name.

[NeoTheFox]

Wouldn't a simple input suffice?

[feschber]

Not if we want to add pre processing later on

[NeoTheFox]

That's fair. Done and done.

[NeoTheFox]

A note on my formatter - my cargo version is cargo 1.90.0 (840b83a10 2025-07-30) (Arch Linux rust 1:1.90.0-4.1) If the linter is mandatory I implore you to consider adding a clear .rustfmt.toml to the repository, as my version sees no issues here and forces the problematic line into that format.

[feschber]

A note on my formatter - my cargo version is cargo 1.90.0 (840b83a10 2025-07-30) (Arch Linux rust 1:1.90.0-4.1) If the linter is mandatory I implore you to consider adding a clear .rustfmt.toml to the repository, as my version sees no issues here and forces the problematic line into that format.

I have the same version and it did complain about the formatting when running cargo fmt --check.

Would you mind opening a separate PR for the rust-fmt.toml (I'm not against that)

[feschber]

Ah one last thing: The input_post_processing section in the config should also be optional, not just the individual settings.

[feschber]

Oh (in case you are unaware): The dynamic updates to the sensitivity and scrolling inversion do not work. You are passing the values to the EmulationProxy but not from there to the actual input-emulation.

[feschber]

If you don't want to do it, I can fix it myself as well.

[NeoTheFox]

I'll probably only be able to get back to this on the weekends, so if it's a quick fix - up to you. I'll do it myself in a few days otherwise

[10a5er]

I’ve been testing this intensively: macOS (Apple Silicon) ↔ Hyprland/Arch (Apple Silicon), both directions. In this setup it finally makes lan-mouse fully usable for real work.

I’m seeing one "maybe-issue" and one point that’s still unclear:

1.	Scroll wheel stops sending events

A gaming mouse tethered to macOS originally forwarded scroll events to the Linux client, but at some point it stopped completely. The wheel still works locally on the macOS host. No combination of config changes or fresh builds (selfbuilt and artefact's from here) brought it back. This might be on me — I experimented with libinput and Karabiner earlier (trying to invert the wheel direction with upstream), so it’s possible I broke something that im not able to backtrack. Mentioning it in case it’s relevant.

2.	Unclear configuration surface

Not an issue — I just haven’t fully mapped out which configuration options are included in this PR. Specifically: • Is scroll sensitivity part of this, or was it only an example? • How does the layering work between host-side and client-side configs? • Which namespace is actually used now: input-, event-, or a mix (depending on -pre-, -post-)?

i hope this has any use and is not a complete waste of space.