Suggestion: Pointer speed/acceleration

[asahilina]

Using lan-mouse between machines running KDE Plasma, the mouse feels significantly slower/more sluggish on remote machines than on the local machine. Messing with the mouse settings, I think the issue is that there is no pointer acceleration with remote machines (turning it off locally in the System Settings gives similar behavior). But there is also somewhat of a difference in perceived linear speed, probably due to having different screen scale factors (and physical screen size).

Am I guessing right that the desktop environment acceleration behavior is not available to lan-mouse due to the way it works? If so, it would be nice if lan-mouse could implement acceleration internally, and perhaps also a speed control. Maybe this could be configured in the config file, per-machine-connection to allow different acceleration/speed profiles depending on what machine is the server and what machine is the client? (I have a weird setup where two different host machines can be the input controllers for a single shared mouse-less client machine, so it would not be out of the question to want different speed factors for the shared machine depending on which machine is the active host, since they have different OSes and different mice and might have different behavior)

[feschber]

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).

[asahilina]

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.