Suggestion: Pointer speed/acceleration about lan-mouse HOT 2 OPEN

What I definitely want to avoid is amplification of acceleration across devices (pointer acceleration is captured and then accelerated again when being emulated remotely).

In my opinion the only correct thing to do is to send unaccelerated motion to the compositor and let the compositor handle acceleration instead of lan-mouse, since the compositor is the only component that can correctly identify if accelerated or unaccelerated motion is required (through interfaces like relative-pointer-unsatble-v1, which report both accelerated and unaccelerated events, letting applications chose what they want).
In other words: Sending accelerated motion to the compositor (and this means any artificial acceleration added by lan-mouse either on the capture or emulation side) would make it impossible for the compositor to infer the original unaccelerated motion.

So ideally, we want to send unaccelerated motion, but also tell the compositor, that it is infact unaccelerated, which I tried to do wherever possible, though in reality most backends do not yet do it correctly.

As for KDE -> KDE, you are (almost certainly) using the layer-shell capture backend, which is explicitly using dx_unaccel / dy_unaccel, so this is working as intended.

On the emulation side, it's either the remote desktop portal org.freedesktop.impl.portal.RemoteDesktop.NotifyPointerMotion for KDE < 6.1 or libei using ei_pointer.motion_relative on KDE >= 6.1.

The RDP documentation says "The (dx, dy) vector represents the new pointer position in the streams logical coordinate space.", which if I'm understanding correctly is the compositor coordinate space, hence unfortunately motion in its accelerated form... which makes sense, considering the "remote desktop" usecase.

As for libei, it's a little bit more complicated: ei_device_type. Virtual devices generate events in a pixel coordinate space
and physical devices in millimeters. So we probably want to have device type physical here and report unaccelerated motion.
However GNOME and KDE both seem to advertise only devices of type VIRTUAL to libei from what I have seen so far, so no luck here either...

The only emulation backend where acceleration should work correctly, is probably the wlroots backend, which uses zwlr_virtual_pointer_v1, where the documentation explicitly states "This protocol allows clients to emulate a physical pointer device."

I personally am very much in favor of having no pointer acceleration at all, but having this be configurable would not hurt anyone I guess (though the drawback is what I stated above).

from lan-mouse.

Yes, this is with layer-shell capture (due to #140) and libei for emulation.

I agree that sending unaccelerated motion and then handling it locally in the compositor is ideal, but of course then there needs to be an interface that allows that (that is implemented properly in compositors).

I do think that at least a simple linear scale config on the sender side is probably still appropriate, since different mice have different DPI and the linear scale appropriate with one mouse might not be appropriate with another mouse.

from lan-mouse.