run evtest and udevadm info against the device in question please, that should tell us more.

evtest reports:
```
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x2 product 0x8 version 0x310
Input device name: "AlpsPS/2 ALPS DualPoint Stick"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
Properties:
  Property type 0 (INPUT_PROP_POINTER)
  Property type 5 (?)
Testing ... (interrupt to exit)
Event: time 1437394475.517959, type 2 (EV_REL), code 1 (REL_Y), value 1
Event: time 1437394475.517959, -------------- EV_SYN ------------
Event: time 1437394475.532280, type 2 (EV_REL), code 1 (REL_Y), value 1
```

udevadm info
```
P: /devices/platform/i8042/serio1/input/input95/event16
N: input/event16
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
E: DEVNAME=/dev/input/event16
E: DEVPATH=/devices/platform/i8042/serio1/input/input95/event16
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=11/2/8/310:isa0060/serio1
E: MAJOR=13
E: MINOR=80
E: POINTINGSTICK_CONST_ACCEL=2
E: SUBSYSTEM=input
E: USEC_INITIALIZED=3921364
```

confirmed, introduced in 83028604513641e9bd7c8ad7c864d52c8f313d62

commit c096bedd8b21864b5ce27403a628c519ad00e148
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jul 21 09:33:47 2015 +1000

    evdev: restore pointing stick const accel property parsing

Hi, I compiled the git version and `libinput-debug-events --verbose` reports:
```
input device 'AlpsPS/2 ALPS DualPoint Stick', /dev/input/event16 is tagged by udev as: Mouse Pointingstick
Device 'AlpsPS/2 ALPS DualPoint Stick' set to const accel 4.00
```

But the pointer speed is still slow (unaccelarated)

Thank you for your work!

Cheers,

can you do me a favour and bisect then to find the commit that broke it? thanks

83028604513641e9bd7c8ad7c864d52c8f313d62 is the first bad commit, you were right. 
It seems there is still another bug. 
I added a `log_info` of device DPI before `evdev_device_create` returns,  83028604513641e9bd7c8ad7c864d52c8f313d62 reports 1000 (DEFAULT_DPI), while c096bedd8b21864b5ce27403a628c519ad00e148 reports 250 (DEFAULT_DPI/POINTINGSTICK_CONST_ACCEL), that means DPI has been properly read.

I also tried to force specify DPI to 250, the pointer is still slow.

So there must be another bug somewhere else.

Cheers,

Could be a fallout from 3928f32281, what happens if you change evdev_init_accel to always pick the normal accel?

By modifying `pointer_accel_profile_linear_low_dpi` to directly returning max_accel, I got a good speed. The problem should be here. :)

yeah, with a const accel the pointing stick ends up as a low-dpi device and picks the new accel method. that's why I'd like you to test this diff here, it should restore the previous behaviour. Can you confirm that?
This is just to make sure the bug isn't elsewhere

diff --git a/src/evdev.c b/src/evdev.c
index 78d1f5d..590b1ea 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1862,9 +1862,11 @@ evdev_init_accel(struct evdev_device *device)
 {
        accel_profile_func_t profile;
 
+#if 0
        if (device->dpi < DEFAULT_MOUSE_DPI)
                profile = pointer_accel_profile_linear_low_dpi;
        else
+#endif
                profile = pointer_accel_profile_linear;
 
        return evdev_device_init_pointer_acceleration(device, profile);

pointer_accel_profile_linear ends up a slow pointer. I guess this bug isn't elsewhere. Does `pointer_accel_profile_linear_low_dpi` run frequently to determine dpi factor, or run once setting up the device? I guess the factor calculation might has a problem.

pointer_accel_profile_linear is what we used before 0.19, so given the same CONST_ACCEL value that should give you the same movement as before. the only other change is commit 6ea69c2b3d18ea39 but I doubt you're hitting that with the trackpoint much.


the DPI factor is set only once at startup, after that it's the same. what happens if you just return 1 from the acceleration function, does that feel natural enough? What's your device's x/y delta range anyway? run evemu-record against the kernel device and look at the REL_X/REL_Y values, what's the span?

simply letting `pointer_accel_profile_linear` return 1 does not make pointer natural, returning 2~4 got an acceptable speed.

evemu-record returned EV_REL / REL_X and EV_REL / REL_Y is within [-15, 15]

by modifiying `s2 = 1 + (speed_in - threshold)*incline/dpi_factor`, I got a reasonable speed and precision. 

I wonder have you ever tested trackpoint accel? Here 's2' increases too slow, and factor is dominated by the smaller one, i.e. s2, so udev's POINTINGSTICK_CONST_ACCEL has no effect.

pointer_accel_profile_linear did not change in these versions, but i guess the `speed_in` value has changed.

Cheers,

not all trackpoints are the same, so it's hard to get a one size fits all. the trackpoint on my lenovo t440 here has a [-30,30] range for example and dropping pointer acceleration (i.e. constant factor 1) is weird at first but still works ok.

and yes, you're correct, the speed_in value has changed. if you change the dpi_factor in filter.c:accelerator_filter() to 1, you should get the original behaviour again

https://github.com/whot/libinput/tree/wip/trackpoint-accel
this should restore the old trackpoint speed/behaviour and serve as a starting point for actual trackpoint-specific accel handling. I'll be rebasing that branch as we go.

Yes, this branch restored old speed but lost presision.

Could you test `s2 = 1 + (speed_in - threshold)*incline/dpi_factor` in `pointer_accel_profile_linear_low_dpi`? I got both speed and precision in my laptop.

Created attachment 117471 [details]
rendering of the acceleration function

this is your acceleration function in comparison to the linear one. For a 1000dpi trackpoint (i.e. one without a CONST_ACCEL, the function is identical to the linear one). For a low-dpi one, here a 400dpi one (const accel 2.5) the low-speed profile is the same but it accelerates faster and higher once it hits the threshold.

Interesting approach, I notice however that the pointer is still very hard to control, especially once I put any serious pressure down (e.g. when I want to cross the screen), the pointer immediately shoots off way too fast. I think my main problem is the threshold, I wonder if a more linear approach would work better.

Hi, version 0.21 and 0.99.1 still has this issue, is there any plan to change the behavior in future versions?

yeah, but not for 1.0. The code is in place now to easier add device-specific pointer accelerations without affecting others, but the actual implementation will have to wait until 1.1 or 1.2.

Good, thx!

Hi, happy to see the relase of libinput 1.1, and my trackpoint got even slower.
Any updates about this issue?

Each time libinput releases a new version, I would checkout the code and apply my patch:

--- a/src/filter.c
+++ b/src/filter.c
@@ -720,7 +720,7 @@ trackpoint_accel_profile(struct motion_filter *filter,
        else if (speed_in < threshold)
                factor = 1;
        else
-               factor = incline * v_us2ms(speed_in - threshold) + 1;
+               factor = incline * v_us2ms(speed_in - threshold)/dpi_factor + 1;
 
        factor = min(max_accel, factor);


The default incline is way tooooo slow for me, please consider adding a option to help people with slow mouse.

Not everybody uses thinkpad.

fwiw, there was only one accel fix between 1.0 and 1.1 and that affected the Lenovo x230 device only. what's more likely is that you updated systemd which contains the hwdb to 'normalize' pointing stick speed and your device is now affected.

What's the output of udevadm info /sys/class/input/eventX, the one of your trackpoint?

udevadmin info outputs:
```
P: /devices/platform/i8042/serio1/input/input18/event16
N: input/event16
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
E: DEVNAME=/dev/input/event16
E: DEVPATH=/devices/platform/i8042/serio1/input/input18/event16
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=11/2/8/310:isa0060/serio1
E: MAJOR=13
E: MINOR=80
E: POINTINGSTICK_CONST_ACCEL=3
E: SUBSYSTEM=input
E: USEC_INITIALIZED=5521806
```

My laptop is dell latitude E-7440.

I've been modifying libinput's code since 0.19, the problem is, the `incline` value 1.1 is tooooo small to me, so I need to modify the code to get a reasonable pointer speed.

And also, limiting linear accel from -1 to 1 is made it impossible for me to adjust pointer speed to an acceptable value using normal way.

Why not just like 0.18, give users the ability to adjust their trackpoint to the
speed as fast as they can? Or an option to modify the `incline` value for trackpoints?

I have to say that libinput know I have a low-DPI device as I've been debugging the code. The point is, the calculated (or adaptive) accel is unacceptablely slow. 

The point is the calculation equation, or coeffient used in that equation, not my configuration or other code.

E: POINTINGSTICK_CONST_ACCEL=3
this means we're treating it like a 333 dpi device which has a bit of a different acceleration, see http://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

the incline is the same but it should kick in a lot sooner than before, making the device a bit faster. tbh, your patch shouldn't even have an effect, the accel function used should be pointer_accel_profile_linear_low_dpi(). can you verify this please?

(In reply to Justin Wong from comment #25)
> And also, limiting linear accel from -1 to 1 is made it impossible for me to
> adjust pointer speed to an acceptable value using normal way.

-1 and 1 are just values for "slowest" and "fastest", they don't literally map to -1 and 1. See the curves in the first diagram of that link above, that's how they currently map for the normal accel function. We have much more liberty on how we handle this.

Feel free to come up with a separate trackpoint acceleration function (it really has to be completely separate, look at the x230 bits for help). Then we can fine-tune that. We may need different ones long-term because not all trackpoints behave the same, but I'm currently flat out with other stuff so if you get started, that's only going to help.

> E: POINTINGSTICK_CONST_ACCEL=3
> this means we're treating it like a 333 dpi device which has a bit of 
Yes, It's behaving like 333 dpi. 

> the incline is the same but it should kick in a lot sooner than before, making > the device a bit faster. 

The only thing that my patch did is mutiplies incline and dpi_factor, in my case, I made incline = incline * 3.

I mean that can we just add a hwdb option to modify this incline? That would cover many devices I thought.

Let me chime in here... I am using a Thinkpad x230 and the trackpoint *still* feels too slow (set to maximum speed in Gnome, that is). I'd like to have a bit of choice here,too. :)

(In reply to Justin Wong from comment #28)
> The only thing that my patch did is mutiplies incline and dpi_factor, in my
> case, I made incline = incline * 3.

The main question here is: is this a general requirement for these trackpoints, or just one on your specific laptop? I don't use the trackpoint that much, but I can tell even on the T440s I have it's not ideal - when it kicks in it's way too fast.

> I mean that can we just add a hwdb option to modify this incline? That would
> cover many devices I thought.

no. the hwdb is not a configuration system, it's a system to store hw-specific properties. the CONST_ACCEL property is there to roughly make pointing sticks behave the same, similar to setting/adjusting the resolution on touchpads, etc. The premise here is that libinput (or other input stacks) can use the hardware with a known baseline and then go from there.

Again, the best solution here would be to write the patches for a separate acceleration function and then go from there.

(In reply to Dominic from comment #29)
> Let me chime in here... I am using a Thinkpad x230 and the trackpoint
> *still* feels too slow (set to maximum speed in Gnome, that is). I'd like to
> have a bit of choice here,too. :)

Note that the x230 patches I mentioned above only affect the touchpad, which is pretty horrible. So I guess the same applies for you too - let's separate the trackpoint accel out first, then we can start fine-tuning it.

> no. the hwdb is not a configuration system, it's a system to store hw-specific properties. 

You mean that you wanna hard code for DELL D520 5150 E4300 E6400 E6420 E6410 D810 E7440, and Thinkpad T420 T430 T440 T450 X61 X200 X201 X210 X220 X230 X240 X250? That's horrible!

Of course I can simply submit a 7440 compatible patch, but what about other devices? Have you tested the code on devices other than T440s or Thinkpad?

> The main question here is: is this a general requirement for these trackpoints, or just one on your specific laptop? I don't use the trackpoint that much, but I can tell even on the T440s I have it's not ideal - when it kicks in it's way too fast.

I don't know, I can only test on my laptop. But according to
http://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
Why the accel of a 200DPI only a little bit faster than 400DPI device? I thought 
200DPI should be twice as fast as 400DPI to reach a reasonable speed.

(In reply to Justin Wong from comment #31)
> > no. the hwdb is not a configuration system, it's a system to store hw-specific properties. 
> 
> You mean that you wanna hard code for DELL D520 5150 E4300 E6400 E6420 E6410
> D810 E7440, and Thinkpad T420 T430 T440 T450 X61 X200 X201 X210 X220 X230
> X240 X250? That's horrible!

most of this is likely just adding a hwdb entry, there's some overlap between the devices. Will we end up with several different accel methods? yes. tens of them? hopefully not.

> Of course I can simply submit a 7440 compatible patch, but what about other
> devices? Have you tested the code on devices other than T440s or Thinkpad?

I have a x220 and a t440 here, Hans has a couple of other ones and we get feedback from people with misc other devices. We can push tests into Fedora and get feedback from there, but the situation is far from ideal.

> I don't know, I can only test on my laptop. But according to
> http://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
> Why the accel of a 200DPI only a little bit faster than 400DPI device? I
> thought 
> 200DPI should be twice as fast as 400DPI to reach a reasonable speed.

by feel mostly. and the fact that this accel method was largely aimed at mice and the number of 200dpi mice is so low we don't really need to care about them. and of course the obvious reason: it was relatively easy to implement and gave us some solution that was 80% of the way there, which is better than 0% :)

> by feel mostly. and the fact that this accel method was largely aimed at
> mice and the number of 200dpi mice is so low we don't really need to care
> about them. and of course the obvious reason: it was relatively easy to
> implement and gave us some solution that was 80% of the way there, which is
> better than 0% :)

I agree with you to make it 80% functional first.

According to my test using mouse-dpi-tool, my trackpoint seems to be even
slower than 200DPI. Maybe we should collect more feedbacks. Currently 200DPI
trackpoint has almost the same accel with 400DPI device, that's apparently
inappropriate.

I still think we should modify incline with `dpi_factor`, no need to 
use `incline * v_us2ms(speed_in - threshold)/dpi_factor + 1`, maybe
`incline * v_us2ms(speed_in - threshold)/(dpi_factor+0.5) + 1` or something,
we can try to find a good value.

don't get too hooked up on the dpi factor, that naming comes from mice that have actual DPI. A trackpoint works differently, so if there is a different base factor that we need (e.g. convert it back to a constant acceleration) then we should do this in the code. Likewise the acceleration function assumes that there is no built-in acceleration - some trackpoints seem to semi-accelerate based on the pressure applied so it'd be worth looking at raw data (evemu-record) first.

Is there any news of this bug? Is the HWDB still being ignored?

A short time ago I tried adjusting the HWDB in F25, but it had no effect, but I am not sure if I did it correctly.

Same as liro,

I have a Dell E5470

The CONST_ACCEL does show up, but has no effect on the trackpoint/pointstick:

sudo udevadm info /dev/input/event9
P: /devices/platform/i8042/serio1/input/input11/event9
N: input/event9
E: DEVNAME=/dev/input/event9
E: DEVPATH=/devices/platform/i8042/serio1/input/input11/event9
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: LIBINPUT_DEVICE_GROUP=11/2/8/800:isa0060/serio1
E: MAJOR=13
E: MINOR=73
E: POINTINGSTICK_CONST_ACCEL=8.0
E: SUBSYSTEM=input
E: USEC_INITIALIZED=5542197

I tried random values, 0.0 all the way to 8.0

Ubuntu 17.04 with libinput 1.6.3 on a Thinkpad Yoga 260, POINTINGSTICK_CONST_ACCEL is ignored.

The trackpoint is WAY too slow per default. I have been using this laptop for a while under linux with maximum mouse settings, and still I am starting to see slight RSI symptoms.

Is my only chance for a workaround to recompile libinput myself? Also, it would be nice if this bug was prioritized since it can actual health effects for people.

I forgot to mention, for some reason the hwdb is actually applied to the scrolling speed of the trackpoint, but not to the actual movement speed itself when not scrolling. (just in case that info helps you track down the issue)

(In reply to jonas@thiem.email from comment #37)
> Is my only chance for a workaround to recompile libinput myself? Also, it
> would be nice if this bug was prioritized since it can actual health effects
> for people.

Please help out! There's effectively only one person working on libinput, and every reporter wants their bug prioritised.

on that note, I don't even have evemu recordings to debug this...

Please attach three separate recordings, each about 2-3 seconds long, with evemu-record:

* slow pointer motion with light pressure
* medium pointer motion with 'normal' pressure
* fast pointer motion with strong pressure

Yes, I know these are subjective, focus more on how the pointer *should* behave than how it currently does when recording.

Created attachment 131277 [details]
My recordings

Here are my slow, medium and fast recordings. Two samples of each.

First analysis here. The range differs greatly. Pressing hard on the trackpoint I have here (which most of libinput's accel is tested against) I can easily get into the 30+ range for REL_X/Y. Both recordings in Commment 41 go up to a max of 15. In addition, the sample frequency is lower, ~70Hz vs my 100Hz.

This results in significantly different speeds being calculated. The CONST_ACCEL in libinput isn't just used as a straightforward multiplier but it adjusts the acceleration curve so that it accelerates sooner and has a higher maximum. [1]
This works provided we get into that range.

Looks like Iiro never gets close to the maximum. The data I get from this, overlaid onto the acceleration curve matches exactly. The problem is that it just never really gets into the differing range. For reference, look at the low-dpi graph here:
https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
The events are almost all left of the x:0.001 marker, where the difference isn't as pronounced yet and CONST_ACCEL has relatively little effect.

In other words: we need to a) rethink the trackpoint acceleration for these devices and b) possibly need some property to auto-scale the range of the trackpoint. I'm not sure CONST_ACCELERATION fits the bill as well as we hoped.

[1] A straightforward multiplication can make pixel-precision impossible, a delta of 1/1 would move 3/3 with a a simple const accel of 3

Yes, on my machine the pointing stick's reading seems to maximize at 15, no matter how hard I push it.

uhm, another thing I just noticed - does anyone use the POINTINGSTICK_SENSITIVITY value? It doesn't show up in the udevadm output and that is very likely the reason why the trackpoint is so slow.  the sensitivity must be set first before playing with CONST_ACCEL, see the 70-pointingstick.hwdb for more info.

I am not sure but I recall it is some kind of hardware-side tuning value that is communicated to the MCU of the pointing stick. It is available on some IBM/Lenovo devices but not on most other ones.

It is, but I don't know what laptop you have and it may just fix the issue for you or others. Unfortunately, the evemu version you're using is 3 years old and doesn't give me that information (I'm thus assuming you're using debian or ubuntu). The question is nonetheless - if you change the sensitivity, does it fix the issue?

My laptop is a Dell Latitude E6320. It was in the filename but maybe I should have been more clear. Defining that POINTINGSTICK_SENSITIVITY parameter on the local HWDB does not have any noticeable effect. Also, I can't find any "speed" or "sensitivity" virtual files in the /sys/devices/platform/i8042 hierarchy.

Yes, I am indeed currently running Ubuntu 16.04 LTS. My current configuration involves the legcy Alps driver (that 16.04 has by default). I have got the pointing stick behavior quite convenient by increasing the "Device Accel Velocity Scaling" option. So I think the solution for libinput would be having a more aggressive acceleration profile for either this pointing stick model or for pointing sticks in general.

I have a branch available for testing now:
https://github.com/whot/libinput/tree/wip/trackpoint-accel-v2

If you don't want to install this, build the source with the event-gui tool (requires gtk+ headers) and run that to check cursor motion speed. No install required.

The big change here is to switch from the mouse acceleration code to one more adjusted for trackpoints. Unlike the previous system which re-used the mouse accel function and relied on some system settings (sensitivity, const accel) this one is designed to have everything handled by libinput, so we can change it ourselves where needed without having to rely on systemd or other external repos.
The cursor motion at the default sensitivity matches the one seen by the evdev driver, one of the questions is if the configurable speed range is wide enough to cover for the use-case

A few comments first:
* the accel is designed to provide accuracy at low speeds, so making things faster won't change slow motions.
* this now completely ignores CONST_ACCEL, i.e. changing that will have no effect
* this now undoes the effect of the SENSITIVITY property, we scale back to the kernel default (128) based on the property value. If the property and the sysfs file mismatch, the behaviour is currently undefined, so don't test by echoing values into /sys/.../sensitivity
* A new property is exposed, LIBINPUT_ATTR_TRACKPOINT_RANGE=20, where 20 is the useful range of the trackpoint. See below.


Calibration:
Because we can't easily check the trackpoints, some calibration may be required. Might eventually be able to learn this heuristically, but not for now. There's a new tool available, "sudo ./tools/libinput analyze-trackpoint" which will prompt you to do the required things. Most importantly, it will require you to move the trackpoint around with what is effectively maximum reasonable pressure and print a histogram of what values have been hit. Use common sense to guess the range for your trackpoint from that, the output should look like a double bell curve, use as range the edge of either curve and ignore any outliers. If the range is 20 (or 30 at sensitivity 200), congrats, no further calibration needed.

Otherwise, save it as /etc/udev/hwdb.d/99-trackpoint-range.hwdb like this:
libinput:name:*TrackPoint*
  LIBINPUT_ATTR_TRACKPOINT_RANGE=30

run sudo udevadm hwdb --update, sudo udevadm test /sys/class/input/event7 (for your device) and make sure it shows up. If so, you're ready. If installed, restart X/Wayland and you're good to go. Look at the libinput docs for more info on building/updating udev properties, etc, I don't want to mess up the bug report with this.

Change the speed setting in GNOME/X/whatever, it will have an effect now. Let me know how you go, whether the default speed makes sense on the touchpad, etc.

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

Just tried 'libinput analyze-trackpoint' on Dell Precision 7510, the first histogram (x) spans through -50 to 50, the second one (y) spans through -40 to 40.
What LIBINPUT_ATTR_TRACKPOINT_RANGE should I use here?

Take the bigger one until we have separate x/y ranges, so 50 in your case.

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

anyone?

Sorry for the late reply.

Subjectively, I think 50 is quite good.
But trackpoint scrolling is way too fast. Do I miss some additional settings?

Hello guys. I have Dell Latitude 5470 running ubuntu 16.04.
And I have the exact same problem:

I am unable to achieve acceptable results with all the different knobs that are available. If I tune down acceleration, I am able to do detailed pointing, but the stick is generally so slow, that it takes ages to cross the screen. On the other hand, if I increase the acceleration, even the slightest movement of the stick makes it jump significantly on the screen so that I am unable to do detailed selections.

Is this bug relative to my issue? Is there any way to fix it right now?

(In reply to Peter Hutterer from comment #53)
> anyone?

Thanks a lot for the instructions on how to test your new code.  I compiled and ran analyze-trackpoint, and got ranges around 25 or 30.

For testing how to configure trackpoint speed from the GNOME preferences menu, I am more in difficulty.  I am using the computer at work and I have plenty of windows open, which makes it difficult to find the right moment to restart the X session.  I am also unfamiliar on how to install and uninstall C libraries cleanly (I fully rely on Debian packages for this).

Hi there,

My laptop is Dell Latitude E7440. I've compiled the trackpoint-accel-v2 branch, and the LIBINPUT_ATTR_TRACKPOINT_RANGE is [-15, 15]. 

Now my trackpoint speed is finally fast enough. However, I found the scroll speed slowed down, which was controlled by POINTINGSTICK_CONST_ACCEL attr.

Cheers,

Kai-Heng: I'll double-check the scrolling, it shouldn't be scaled and thus not be too fast. Thanks for testing!

Alexey: yes, this is the bug you're looking for. See comment 48.

Charles: You can get the repo and build it with the event-gui and run that directly from the repository, without restarting. That should at least give you a good indication whether the changes will improve (make sure the hwdb is updated), see the various instructions here:
https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html

I just compiled libinput with the latest trackpoint-accel-v2 and it is a tremendous improvement!

I use it with this hwdb entry right now and maxed out mouse speed in GNOME:


evdev:name:* Elantech TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadYoga260:*
 LIBINPUT_ATTR_TRACKPOINT_RANGE=20


.. and now it actually feels fast! One thing is still a bit suboptimal though: the acceleration ramps up a bit too slowly - it feels like I need to apply too much force to get to the decent speeds. Once I use more force though, it is extremely fast now, and feels much more like the "maximum barely usable speed" setting that it should be.

Is there any setting in the hwdb I can tweak to make it use quicker speeds for the middle value range of the reported raw input speed, while keeping the same actual speed for the low and high value range of the reported raw input speed?

Created attachment 131542 [details]
evdev-record output collected for the TrackPoint (Thinkpad Yoga 260)

I experimented around a bit more: I tried LIBINPUT_ATTR_TRACKPOINT_RANGE=2, LIBINPUT_ATTR_TRACKPOINT_RANGE=15, LIBINPUT_ATTR_TRACKPOINT_RANGE=20, LIBINPUT_ATTR_TRACKPOINT_RANGE=70. Strangely enough, they feel all pretty much the same... so I'm not sure I'm applying the setting correctly.

I also did a recording with evemu-record and LIBINPUT_ATTR_TRACKPOINT_RANGE=15 (possibly applied incorrectly as above) for my subjective feeling of low pressure, medium pressure and high pressure on the trackpoint.

jonas: this attribute is supposed to describe the hardware capabilities, don't try to use it as a configuration thing. It won't work, or have may some adverse side effects. Thanks for testing though, I'll try to make the acceleration function ramp up faster - I also noticed it was a bit slow but since I don't use the trackpoint very often, it's hard to tell whether that's a problem or just wrong expectation.

Ok, some updates pushed to:
https://github.com/whot/libinput/tree/wip/trackpoint-accel-v4

This one ramps up quicker but still provides precision on slow movements. Please give it a test, thanks.

And another commit on top of that branch, check that you have "filter: apply the same factor to x and y" before testing please. Mostly happy with this but I'm not 100% sure about the range yet, the slow one (-1.0) is still relatively fast. Not sure how much this matters.

How to test this:
First, run this from a fresh checkout, a bunch of tools have renamed so without a fresh checkout, you may be testing stale code. Preferably build with meson, it's easier to clean up after that.

Measure the trackpoint range with the libinput-measure-trackpoint-range tool. Note that this measures the hardware range as-is, don't press too hard, don't press too soft. The tool is supposed to capture the highest reasonable deltas that the device sends. If you press harder than you would use in normal usage, it'll skew the results. If you don't press hard enough, it'll skew the results.
Look at the histogram printed, pick a good number. Usually that's the edge of the bell curve or maybe a bit further out. Leaving this tool running in the background while using the trackpoint for a bit is a good idea to capture the full range.

Set the LIBINPUT_ATTR_TRACKPOINT_RANGE property. Note that this is not a configuration option, it's a description of the hardware. Thus, if you change the sysfs sensitivity, you need to measure again. There's a bit of room for error on the range property, especially if you get different ranges from the trackpoint on multiple measuring runs. Adjust as necessary to be as accurate as possible. Better to use a slightly smaller range than a larger range, I think.

Make sure the udev property shows up on the device before testing.

When testing, please do test with different speed settings. The default speed setting won't make everyone happy, that's why we have the slider. Test from -1 to +1 and see. In theory, no-one should need -1 or +1, the majority should be close to the 0 mark. Test for a bit to let your muscle memory adjust.

Also, set your sysfs drift_time to 30 or above, it'll spare you some accidental movements, see bug 93448.

If you have a trackpoint that does *NOT* have a sysfs sensitivity/drift_time file you're using a different kernel driver. I don't know what impact that has on this code, but make sure you mention it in any comments.

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

I tried the v4 and v5 repositories of the new libinput branch. I have POINTINGSTICK_CONST_ACCEL=2

I tried the v4 and v5 repositories of the new libinput branch. I have LIBINPUT_ATTR_TRACKPOINT_RANGE=15 and it shows at the output of "sudo udevadm test /sys/class/input/event1" command. The cursor speed is still little sluggish for me even at the highest acceleration speed. I would like a more aggressive acceleration profile for pointing stick use.

An old school "acceleration" slider would be handy here, but AFAIK libinput does not have an equivalent for that?

hmm, I got this error

libinput error: event19 - libinput error: Lite-On Technology Corp. ThinkPad USB Keyboard with TrackPoint: libinput error: trackpoint range property is present but invalid, using 20 instead


after upgrading my archlinux. I tried reinstalling wip/trackpoint-accel-v4 but still doesn't work.

I just tried building the latest wip/trackpoint-accel-v5 to check it out but it doesn't build for me on Fedora 26:

-bash-4.4$ ninja -C builddir/
ninja: Entering directory `builddir/'
[50/138] Linking target libinput-measure-touchpad-tap.
FAILED: libinput-measure-touchpad-tap 
cc  -o libinput-measure-touchpad-tap 'libinput-measure-touchpad-tap@exe/tools_libinput-measure-touchpad-tap.c.o' -Wl,--no-undefined -Wl,--as-needed libinput.so.10.12.2 -Wl,--start-group liblibinput-util.a libtools_shared.a -lmtdev -ludev -Wl,--end-group -levdev -lm -lrt -lwacom -lmtdev -ludev -levdev -lm -lrt -lwacom -levdev -ludev -lmtdev -ludev -levdev -lm -lrt -lwacom -levdev -ludev -ludev '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/home/jonas/Develop/libinput/builddir/  
libtools_shared.a(tools_shared.c.o): In function `open_udev':
/home/jonas/Develop/libinput/builddir/../tools/shared.c:404: undefined reference to `libinput_udev_create_context'
libtools_shared.a(tools_shared.c.o): In function `open_udev':
shared.c:(.text+0x886): undefined reference to `libinput_log_set_handler'
shared.c:(.text+0x897): undefined reference to `libinput_log_set_priority'
...

fwiw, the last branch got merged as

commit 2cadb5f4877e88198c543c76afa9d97bdd82f2da (tmp-today/wip/trackpoint-accel-v6, wip/trackpoint-accel-v6)
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue May 16 13:10:07 2017 +1000

    trackpoint: parse a trackpoint range property


and the few commits before. I'm considering this problem fixed for now, or at least this bug because 68 comments in we're not going to be any more productive at finding the remaining issues (which now depend on the above patchset). So any issues left, please file a new bug and assign it to me, thanks

What version should this be part of?

I use Fedora 27 with libinput 1.9.0 and again at maxed out mouse speed the trackpoint is back to almost unbearably slow unlike with the experimental branch I tested from here.

it's part of 1.9.0/ did you set the trackpoint range property correctly?

I found the trackpoint speed unbearably slow too even when maxed out, so I recompiled with TRACKPOINT_DEFAULT_MAX_DELTA bumped up to 120, and it feels a lot better. Perhaps 60 is too conservative, or a tweakable multiplier ought to be multiplied to max_delta?

Scrolling is still pretty slow though.

did you run the libinput measure trackpoint-range property yet?