(In reply to Jonas Thiem from comment #0)
> libinput api should be changed to allow window managers/desktop environments
> to specify higher mouse speeds. Basically, I like somewhat obscene mouse
> speeds which I understand are beyond what a usual user might be using since
> I prefer to use my input devices precisely rather than make huge movements.

I'm confused, that last statement is add odds with itself. A high speed generally means huge movements rather than precision (though we try to work around this in libinput's accel curve).

> On all Thinkpad laptops (3 entirely different models) I have seen the
> highest trackpoint mouse device sensitivity possible in Linux/GNOME is below
> what I find preferable, with varying degrees of uncomfortableness. Also,
> most low-dpi cheaper mouses move way too slow for my likings even at maximum
> speed (tested a logitech, acer and another vendor I forgot).

the trackpoint is often slow out of the box which is why we have this:
https://github.com/systemd/systemd/blob/master/hwdb/70-pointingstick.hwdb
do you have any of these settings applied to your device?

also, did the low-dpi mice have hwdb entries to specify their DPI?


> However, the GNOME developers say they cannot even provide a hidden(!)
> option somewhere in gconf/dconf for a multiplier to speed up the mouse speed
> like 2x or even 3x times in overall, since the libinput API clamps at some
> arbitrary 1.0 speed limit which is exactly the not-very-fast maximum
> available using the slider in the GNOME mouse settings.

the [-1, 1] range is simply a normalization of the speed into some range, for the range where the acceleration curve is defined. it doesn't correspond to anything, on most mice the value 1.0 means 4x the native device speed so you have 1/1000 of an inch correspond to 4 pixels of movement.

(In reply to Peter Hutterer from comment #1)
> I'm confused, that last statement is add odds with itself. A high speed
> generally means huge movements rather than precision (though we try to work
> around this in libinput's accel curve).

What I meant is I like to use my hand as attached to my body precisely with small movements. (sorry for the weird description, just trying to be super clear)

> the trackpoint is often slow out of the box which is why we have this:
> https://github.com/systemd/systemd/blob/master/hwdb/70-pointingstick.hwdb
> do you have any of these settings applied to your device?
> 
> also, did the low-dpi mice have hwdb entries to specify their DPI?

At least one affected trackpoint of this problem is listed, which is the X230T trackpoint. The maximum setting of that device is more bearable, but still too slow for my likings.

> the [-1, 1] range is simply a normalization of the speed into some range,
> for the range where the acceleration curve is defined. it doesn't correspond
> to anything, on most mice the value 1.0 means 4x the native device speed so
> you have 1/1000 of an inch correspond to 4 pixels of movement.

Why would you not define the behavior outside of such a maximum though? This question is what the bug report was meant to address. Inaccuracies in the hardware db amplify this problem, but the question itself remains even with accurate hardware db for people who love their pointing device unusually fast like me. If you really need such a finite relatively-low limit, you should consider setting it a magnitude higher than what it currently is..

Unrelated question:

Is the movement directly translating to pixels? This could be another reason this device I'm having right now (Thinkpad Yoga 260) is affected worse than my previous ones, since the pixel density is relatively unusually high. However, the device listed in the hardware db, the X230T, has a usual pixel density and has the same problem for me, even if less pronounced.

If that helps, I consider the pointer speed resulting from my mouse speed to slow at all velocities, including the lower ones. So if there was a simple unlimited multiplier available to evenly speed up everything at any device velocity, that would most likely be sufficient.

Though I wouldn't object to a more sophisticated solution either :-)

(In reply to Jonas Thiem from comment #3)
> If that helps, I consider the pointer speed resulting from my mouse speed to
> slow at all velocities, including the lower ones. So if there was a simple
> unlimited multiplier available to evenly speed up everything at any device
> velocity, that would most likely be sufficient.
> 
> Though I wouldn't object to a more sophisticated solution either :-)

this doesn't work. let's assume you have a multiplier of 2. This means that the slowest motion will produce a 2 pixel movements, resulting in some pixels being unreachable and this just gets worse as you increase the factor.

(In reply to Jonas Thiem from comment #2)
> What I meant is I like to use my hand as attached to my body precisely with
> small movements. (sorry for the weird description, just trying to be super
> clear)

sounds like you may be better off with the flat profile then? 
https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

> At least one affected trackpoint of this problem is listed, which is the
> X230T trackpoint. The maximum setting of that device is more bearable, but
> still too slow for my likings.

right, so this indicates that changing the trackpoint sensitivity at least makes things more useful. Is suspect the others you tried still need that then.

> > the [-1, 1] range is simply a normalization of the speed into some range,
> > for the range where the acceleration curve is defined. it doesn't correspond
> > to anything, on most mice the value 1.0 means 4x the native device speed so
> > you have 1/1000 of an inch correspond to 4 pixels of movement.
> 
> Why would you not define the behavior outside of such a maximum though? 

because by definition it's outside of the defined range? :)
I've always said that we can revisit the pointer acceleration curves, but I never go to it with too many other things to be completed. Raising the maximum accel threshold is not that hard as long as the accel curves are well defined. Feel free to have a go at it, the acceleration code isn't that complicated to get a grasp of (I hope :)

> Is the movement directly translating to pixels? 

sort-of. libinput doesn't have a concept of pixels because we don't handle outputs. but what we hand out usually translates into pixels in the compositor unless there's a custom multiplication factor applied that accounts for pixel density on the screen the pointer is on.

(In reply to Peter Hutterer from comment #4)
> this doesn't work. let's assume you have a multiplier of 2. This means that
> the slowest motion will produce a 2 pixel movements, resulting in some
> pixels being unreachable and this just gets worse as you increase the factor.

Maybe make it raise the acceleration speed then? So that the faster it is, the even more faster it gets...

See, if this wasn't obvious I'm not an expert on any of this and I'm certainly not trying to dictate a specific approach.

All I'm saying is it seems weird that there is such a hard maximum limit which is relatively low, and it would really improve the experience for me as a user immensively if this wasn't the case.

(In reply to Peter Hutterer from comment #4)
> right, so this indicates that changing the trackpoint sensitivity at least
> makes things more useful. Is suspect the others you tried still need that
> then.
> 

It certainly does, but it doesn't entirely solve the problem which is why I opened this bug report.

---

Alright, I'm gathering from your remarks that at this point the main problem is that someone with the skill needs to find the time to implement the code that generates proper accel curves for higher values?

(In reply to Jonas Thiem from comment #5)
> All I'm saying is it seems weird that there is such a hard maximum limit
> which is relatively low, and it would really improve the experience for me
> as a user immensively if this wasn't the case.

fwiw, the hard limit exists mainly because it was close to the defaults in X, without the ConstantAcceleration bits applied. Which themselves are rarely used, especially now that we have the mouse dpi database.
A properly configured mouse device is almost uncontrollable on the highest speed.

> (In reply to Peter Hutterer from comment #4)
> Alright, I'm gathering from your remarks that at this point the main problem
> is that someone with the skill needs to find the time to implement the code
> that generates proper accel curves for higher values?

pretty much...

I'd like to point out that implementing this would make the impact of bugs like https://bugs.freedesktop.org/show_bug.cgi?id=91369 (where there are problems applying the hwdb) would be much less severe if this was implemented so users could have an easy workaround without resorting to recompiling libinput..

it'd be a lot easier to fix this if someone would spend the time investigating what's going on here and why the values are so far out. Adding more multipliers doesn't really help if we don't know why we're adding them.

It's been over a year, no-one has really bothered to do anything about it so it can't be that bad... Since I get little to no feedback on anything pointer-acceleration related I'm closing this as wontfix, I probably won't touch that code for a while.

You're welcome to work on it though.

I use DPIScaleFactor with scale factors decidedly ABOVE what they should be on all my devices because on all of them, I consider libinput maximum speed to be universally too low.

(4.0 on my laptop with 1.0 interface scale and trackpoint - a 4x higher max speed, 3.0 on my desktop with 2.0 interface scaling on a 4K screen - a 1.5x higher max speed)

Since not doing that causes me to get RSI-like pain symptoms, I am very unlikely to ever move to Wayland unless a similar option becomes available, or libinput ever adds a significant increase of max speed across the board for all devices.

I can't speak for others of course, so I don't know if I'm the only one affected by this. However, I have anecdotal advice from other linux users that had similar issues with their trackpoints, but probably aren't heavy users enough to care.

> Adding more multipliers doesn't really help if we don't know why we're adding them.

I would say it works just fine given it lets me use my computer without notable discomfort - as evidenced by my abuse of DPIScaleFactor, which I'm sure wasn't meant to be used the way I do. But that's just my personal experience of course, I'm not an expert on input devices.

The fact that the normalized range isn't sufficient is a sign that something is broken. Hacking around this by just adding another option doesn't fix the bug, it just adds maintenance burden. And it doesn't fix it for anyone else with the same hardware, they now have to figure out where the config option is, what it does, how to set it, etc.

In an ideal world it wouldn't be needed, but given how often I ran into this, at least it would help *me* significantly - again, can't speak for others. The Xorg option that happens to exist for other reasons is pretty much the difference of "usable with ugly workaround" and "install Microsoft Windows to be able to use computer" for me.

I'll provide data wherever I can to fix the device entries themselves for the fundamental issue, but just given on my experience I think a workaround option wold be a real life saver for some people.