Out of interest, what is your use-case here?

I simply dislike it. I prefer knowing exactly by how much the pointer is going to move. After getting used to it, it's very easily noticeable and annoying.

Also, velocity-dependent acceleration makes building muscle memory a lot harder, which is why many gamers disable it.

note that games can use a different API to get the unaccelerated motion events, so that's catered for.

as for AccelSpeed -1, you're correct that it currently does some deceleration below the threshold. having said that, the pointer accel code isn't finished yet either, e.g. it doesn't do any constant deceleration, so the -1 setting is a bit off anyway.

I can't promise you a timeline or whether this will get fixed in the way you want it to. we're trying to simplify a couple of things, pointer acceleration is one of those, and that means that not every configuration that was previously possible will be possible in the future. 
So I'll leave this bug open for now, but don't expect any immediate fixes, sorry.

Honestly that sounds a bit like "we know what you want better than you know what you want". libinput isn't secretly a Gnome project is it?

If the new system is not able to give people what they actually want, its not really better than the old is it?

Please try to be constructive, throwing meaningless accusations around isn't getting issues fixed.

I'm also peeved by this change, so I'll give a couple usecases/reasons to justify putting effort into "fixing" this.

To me, it seems very unintuitive when the cursor speed changes. Moving my mouse 2 inches can potentially move the cursor 5 pixels or 20. I rely on muscle memory for mouse input and the new acceleration/deceleration is breaking my mind.

The problem is that some of us use our mice as if it were an extension of our body. The cursor is a physical object we're moving. The speed of the mouse is either factored up or down using gears. The important thing is that the gears aren't swapped mid-movement. If the gears start getting swapped out from under us, we get confused.

Another way of thinking about this is that the mouse is your mind's image of yourself. Proprioception and motor skills and all that. The cursor is your hand. You reach out to pet a dog, and not wanting to smack the dog, you attempt to slow you hand down. But your hand has a mind of its own. Your mind is saying "Slow down by this amount", but your hand interprets the signals and thinks "Brain wants me to slow down by x amount. I can do better, I can go even slower!"

Then, we get disoriented and what ends up happening is our hands move 20 feet in our heads without ever reaching the dog.


A bit long winded, but I hope it helps you libinput guys understand why this is important for some people

IMO, it's best to be able to adjust the pointer speed independently from the acceleration.

For anyone interested, I achieved something similar by turning the acceleration to the lowest setting (-1). This however makes the cursor unbearably slow. To fix this, fiddle with the MOUSE_DPI for your mouse in the udev hwdb.

Unfortunately, this isn't a complete workaround. The mouse still seems a little _off_. It's more noticeable when trying to ease the cursor into place.

+1 for this issue. I primarily work in 3D and raster apps. After the change to libinput my mouse got this weird "adaptive deceleration" feel to it which is really screwing with my working process. It's not just about muscle memory but also inconvenient because it makes you move the mouse greater distances when you trying to be precise hence you move it slower. Now you have to physically move it farther away every time, so the hand gets tired quicker. 

I appreciate the work you, the devs, do. I hope a fix will be coming soon.

I noticed another (possible) bug. It seems that if you move the mouse too slowly, the cursor does not move at all.

This is most noticeable when trying to move the cursor by just a few pixels. It becomes impossible to move. It has been bugging me for a while. It's worse than the actual deceleration/acceleration. The cursor literally stops moving when I'm trying to move my mouse precisely.

I'm posting this comment because it feels like it's related.

the "not moving at all" is about to be fixed here:
http://lists.freedesktop.org/archives/wayland-devel/2015-June/022509.html

the rest: we're still tweaking the accel functions to have something useful.

I also rely on muscle memory but, since I have a non-HiDPI triple-head 3840x1024 desktop, I rely on a little bit of pointer acceleration to comfortably reach my entire desktop without lifting the mouse.

I'm willing to give you guys the benefit of the doubt but be aware that, should I wind up in a situation where I have to switch to libinput and I can't achieve the behaviour I want through the exposed configuration options, I can and will maintain a patched fork.

(And, given my limited available time to watch for updates, that tends to mean I'm willing to risk staying on a vulnerable version of a package for an indeterminate amount of time to get an acceptable end-user experience. I was actually making plans to do that before the Classic Theme Restorer extension came out.)

Adding myself to the watch list here, this is definitely something that I feel could affect a lot of users. In my case I have a high DPI mouse, if I want it to move faster I'd rather switch my DPI on the mouse than have the software try to guess and break my expectations of movement. I've always disabled acceleration and prefer that the pointer moves 1:1 the same relative distance as my actual mouse, anything else just doesn't feel right.

https://github.com/whot/libinput/tree/wip/no-pointer-accel
this is the simplest fix to disable pointer acceleration, hardcoded and with no knobs but apparently that's what is desired. Give this a test and tell me if that is really what you want, I've already talked to some users who said they wanted no accel only to revise their opinion when confronted with real "no acceleration".

Tried it now, and yes, I think this is what many people wants. It really should be togglable though, because I guess you must have a high dpi device for this to not feel jittery when moving the mouse just a little bit.

Just tested it. This is exactly the behavior I want. Please add a setting for it.

jittery is not the right term, I think. using this on a 400dpi mouse is excruciatingly slow, 800dpi is still doable. for 1000dpi it feels odd (to me anyway) but one could get used to it after a while I guess. the problem here is with the normalization too, I haven't looked at this for low-dpi mice, so right now they're likely jumping over pixels for slow movements.

more questions: what resolution does your mouse have? and what is the main problem with the acceleration right now? with 1.0 we've dropped deceleration down to only happen for *really* slow movements. for most slow movements, the acceleration for most movements would be 1:1 anyway. So the question then becomes - does the acceleration kick in too quickly, too strongly, too.... ?

what is your normal workload? e.g. I find subpixel precision extremely hard without having deceleration since it would require me to move my mouse less than 1/1000 of an inch.

As a commenter above put it, any movement other than 1:1 just doesn't feel right. My mouse allows me to set any DPI between 50 and >5000. I have no problem with precision at my normal DPI, though if I wanted, I would just use a button to momentarily lower it. A lot of people have similar mice. So again, please make it an option to have unaccelerated movements.

My suggestion is as follows:

Have two modes of calculating mouse movement - the default should stay with the acceleration mode libinput already has. But add another mode called linear mode (or something like that). There, the only configuration value should be a scale value you can use to compensate high (and low) dpi mouse. The scale/gradient value should just be a how much mouse movement should be linearly translated to movement on screen - you could call it sensitivity factor or something.

I think that's a great idea. Have separate settings for acceleration and sensitivity. That would allow people with regular mice (unable to change dpi) to disable acceleration but still compensate for speed.

do any of you guys use Windows/OS X? how do you disable pointer acceleration there?

Created attachment 118005 [details]
attachment-20980-0.html

It's horrible in Windows, there's a registry hack you have to use to get it
truly disabled. Just disabling pointer 'precision' is generally enough to
make it usable for me though.

On Sun, Aug 30, 2015 at 8:14 PM <bugzilla-daemon@freedesktop.org> wrote:

> *Comment # 21 <https://bugs.freedesktop.org/show_bug.cgi?id=89485#c21> on
> bug 89485 <https://bugs.freedesktop.org/show_bug.cgi?id=89485> from Peter
> Hutterer <peter.hutterer@who-t.net> *
>
> do any of you guys use Windows/OS X? how do you disable pointer acceleration
> there?
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are on the CC list for the bug.
>
>

I have "enhance pointer precision" checkbox unchecked and the speed slider set at 6/11. Although I might've used a registry hack on top of that.

ok, here's a version that provides 'flat' acceleration
https://github.com/whot/libinput/tree/wip/no-pointer-accel
and you'll need the matching X driver
https://github.com/whot/xf86-input-libinput/tree/wip/no-pointer-accel

this exposes a property to enable the flat acceleration. Currently only with xinput:
xinput set-prop "..device name.." "libinput Accel Profile Enabled" 0 1
won't work on touchpads, but other pointer devices should all work.

there's an error in the Xorg log about an "unknown" profile on startup, you can ignore that error.

The speed setting "libinput Accel Speed" is the same as before, takes [-1, 1]. Speed settings < 0 are a percentage of the default speed (i.e. -0.3 is 70% of the normal speed), speeds > 0 are times 2, so 0.5 is 200% and 1.0 is 300% of the normal speed.

Let me know how you go.

Fantastic :)

After that simple xinput set-prop 11 "libinput Accel Profile Enabled" 0 1, the mouse movements is exactly right. You really should merge something like this!

Since I don't need to fiddle with Accel speed, you should hear with justanarcher and/or others with fancy high dpi mice to find out if the range available is enough.

Great work!

Well, the point of fancy mice is that I don't have to fiddle with such settings. :)

As for the changes, everything works as expected. Thank you.

Will be eagerly awaiting a stable release.

You could do a small test to see if you can get an acceptable pointer speed at the lowest dpi and the highest dpi setting, just to see if the scale is wide enough...

The negative scale can go lower than 1%, so that's not a problem. Rather, 300% speedup might not be enough for low-dpi mice used with 4K monitors.

(In reply to justanarcher from comment #28)
> The negative scale can go lower than 1%, so that's not a problem. Rather,
> 300% speedup might not be enough for low-dpi mice used with 4K monitors.

if it's not enough, you'll need a proper acceleration profile, not a flat profile. The big disadvantage of the flat profile is that it doesn't work at all for subpixel-precision and badly at pixel-precision. If you translate a pointer movement of 1 delta to 1 pixel you can address every pixel on the screen (even if it requires that you move your mouse not more than 1/1000 of an inch). Once you start applying acceleration, you start skipping pixels. At an acceleration of 300% the pointer will jump pixels at low speeds because 1 delta == 3 pixels.
Which means that I'll cut down the accel range to a max of 200%, anything above that is pointless.

I'm also somewhat tempted to only enable the flat profile for devices we know have switchable DPI profiles, but I'm not sure that's worth the effort.

http://lists.freedesktop.org/archives/wayland-devel/2015-September/024177.html

commit 8d9e7a1bcf8eac3a344d8c1135b2b546c37e8b04
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Aug 27 13:13:47 2015 +1000

    Add an API to change pointer acceleration profiles

Thanks for creating the "flat" profile. I think this is exactly what was
requested. It will be very useful for me.

I also believe that while objecting the approach with the acceleration,
no one was against the normalization to 1000dpi that libinput does. I
think it's a very nice touch to make all mice feel the same with the
same profile.

In the patch, you're disabling that normalization so devices that are
able to change their DPI could actually this way alter the pointer
speed.

Respecting switchable DPI devices and disabling acceleration are two
separate concepts. Was there a need to tie them together in your patch?

yes. if you have a profile who's whole purpose is to make the pointer move like the mouse, doing normalization on top doesn't make sense. in order for mice to feel the same, you need to slow some down and speed others up, for low-dpi mice that's particularly true, otherwise you get pixel jumps.

*** Bug 92670 has been marked as a duplicate of this bug. ***

(In reply to Peter Hutterer from comment #33)
> yes. if you have a profile who's whole purpose is to make the pointer move
> like the mouse, doing normalization on top doesn't make sense. in order for
> mice to feel the same, you need to slow some down and speed others up, for
> low-dpi mice that's particularly true, otherwise you get pixel jumps.

Hi Peter!

Is this really fixed and merged? How can I really disable it with libinput?

yes, it's merged. How you configure it depends on how you use libinput, with the xf86-input-libinput driver set the matching option (see man libinput), if you're using a wayland compositor it'll have a compositor-specific configuration option.

When I try to use the flat profile, my mouse doesn't move at all for some reason.

(In reply to Peter Hutterer from comment #36)
> yes, it's merged. How you configure it depends on how you use libinput, with
> the xf86-input-libinput driver set the matching option (see man libinput),
> if you're using a wayland compositor it'll have a compositor-specific
> configuration option.

The manual is not too verbose about this. There is only a single mention about acceleration, that AccelSpeed ranges between -1 and 1. I am not sure about that's what I need.

Btw. as far as I understand this lib controls the keyboards as well. Is there a limit on how many keys are pressed simultaneously? In a game it does not handle a 4th key. (In win7 it works perfectly, so the problem is not with the keyboard.) Is there a forum we can discuss this?

You need to set the acceleration profile to "flat", the speed itself then just multiplies that with a number.
http://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

there is no software limit on key presses, whatever the kernel gives us we just forward. check with libinput-debug-events if the events come out of the library, if not then we can work on that (please file a separate bug for that though). If it works fine, the issue is somewhere higher up the stack, most likely the X server.

AnAkkk: please file a separate bug with an evemu-record of a mouse movement attached that doesn't move the pointer