Bug 92663

Acceleration and speed are intertwined in libinput. What's the actual result you're trying to achieve?

http://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

I will clarify what I mean on the example. Every pointer has:
1) Speed - how many pixels pointer will pass, if the mouse was moved. Linear parameter.
2) Sensitivity - how many pixels pointer should pass in short perior of time, to enable accelearion
3) Acceleration factor - value that increases speed

Lets imagine mouse 1000dpi, if it passes 1 inch it  sends to computer signal, that it has passed 1000 points.
Libinput gets 1000 points, the cursos will definetelly be moved by 1000 pixels in some direction. If it has passed first 10 pixels faster than 10 msec ( lets imagine 10 millisecs) - the acceleration mode will be enabled (lets imagine accel factor = 2.0) and cursor will pass 10 + 990*2 = 1990 pixels.

Libinput allows to change acceleration factor (XFCE also allows me to change sensitivity), but it doesn't allow me to change speed. I don't know DE that allows to do it. 

PS: me and many first person shooters' gamers don't need any acceleration at all, any acceleration will only spoil your aiming skill, but we need to adjust pointer's speed .

(In reply to Yan Pashkovsky from comment #2)
> I will clarify what I mean on the example. Every pointer has:
> 1) Speed - how many pixels pointer will pass, if the mouse was moved. Linear
> parameter.
> 2) Sensitivity - how many pixels pointer should pass in short perior of
> time, to enable accelearion
> 3) Acceleration factor - value that increases speed

Basically right, the units aren't quite the same. libinput calculates the velocity of the pointer, based on the movements, not just on the last delta. Based on that velocity, we calculate the acceleration factor and multiply incoming events. The factor can be 1 (for 1:1 movement) but also less than one. For very slow movements we decelerate the pointer to provide better subpixel precision.
The sensitivity is what we call threshold.
 
> Lets imagine mouse 1000dpi, if it passes 1 inch it  sends to computer
> signal, that it has passed 1000 points.
> Libinput gets 1000 points, the cursos will definetelly be moved by 1000
> pixels in some direction. 

No, this also depends on previous movements, and the movement directions.

> If it has passed first 10 pixels faster than 10
> msec ( lets imagine 10 millisecs) - the acceleration mode will be enabled
> (lets imagine accel factor = 2.0) and cursor will pass 10 + 990*2 = 1990
> pixels.
> 
> Libinput allows to change acceleration factor (XFCE also allows me to change
> sensitivity), but it doesn't allow me to change speed. I don't know DE that
> allows to do it.

The speed is a result of the input movement and the acceleration factor. libinput's pointer acceleration is designed that as you increase the pointer speed, acceleration kicks in sooner and goes up further than on a lower acceleration setting. So yes, you can adjust the speed. What you can't adjust is the threshold though, it's part of the acceleration function.


> PS: me and many first person shooters' gamers don't need any acceleration at
> all, any acceleration will only spoil your aiming skill, but we need to
> adjust pointer's speed .

libinput 1.1 has that ability, if you set the pointer profile to "flat" you get a 1:1 mapping of physical to virtual movements.

libinput 1.1 was released yesterday, according to Phoronix, so I didn't test it. Does this flat profile allow you to change the speed of pointer? How to enable this flat profile? (Some terminal command or I need to wait while Gnome devs will implement it?)

I hope you understand how I want my pointer to move: it's movement must be without acceleration at all, no matter how fast I move my mouse - the pointer must pass the same number of pixels. But I want to be able to change this number of pixels

the doc link above explains how it works, but yes, no pointer acceleration, the speed setting will simply multiply the delta.

you'll need xf86-input-libinput 0.15 to get the property exposed to set it, then you can use xinput to toggle it at runtime or write an xorg.conf.d snippet for it (see man libinput)

But I am already using xinput to edit pointer's speed with zero acceleration. What's the reason for flat profile... Is xinput a component of libinput?

What I use:

Section "InputDevice"
    Identifier "Logitech USB-PS/2 Optical Mouse"
    Option "ConstantDeceleration" "0.5"
EndSection

I haven't seen any mention of velocity or flat profiles here: http://wayland.freedesktop.org/libinput/doc/latest/group__config.html

I'm a bit confused. If I understand you correctly - then everything is left is to close this report and open new one on DE's bug tracker to implement tick in mouse settings for flat profile.

libinput is the backend for the xf86-input-libinput driver (which is mostly a thin wrapper between libinput's API and the server API). The driver exposes properties for the config options that libinput provides, similar to other drivers. xinput is a generic tool to change the property values, but is otherwise independent.

I don't think ConstantDeceleration even takes effect for a libinput device, I'd have to double-check to be sure though.

The reason for the flat profile is that a number of people requested a 1:1 mapping between the device and the pointer movement.

And yeah, afacit once you enable the flat profile, you should be fine, at least from the libinput/xorg side.

Let us ignore speed & acceleration for the moment (if possible).

I *need* an option, that I can set, which will govern the linear distance the pointer moves on the screen / display for a specified linear movement of a finger on the touchpad. This parameter should have *no* dependence on speed or acceleration. For example, if a finger moves 1 cm vertically on the pad, it should be possible to see the mouse icon move 1.06 mm, 1.6 cm, 12.3 cm, etc as this option parameter is varied.

It might be necessary to create two options; viz., one for normal moves & one for scrolling.

That's exactly what the flat profile does, it removes any acceleration and just multiplies the deltas by some given factor.

And note that the problem with this basic approach is that some pixels can become unreachable. In the simplest case of 1 device unit == 1 pixel and you apply a factor 2, means you can only hit every second pixel.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/issues/1.