Bug 1509017

/dev/input/event17:	TPPS/2 IBM TrackPoint

$ udevadm info /sys/class/input/event17
P: /devices/rmi4-00/rmi4-00.fn03/serio3/input/input22/event17
N: input/event17
E: DEVNAME=/dev/input/event17
E: DEVPATH=/devices/rmi4-00/rmi4-00.fn03/serio3/input/input22/event17
E: ID_BUS=rmi
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: LIBINPUT_DEVICE_GROUP=11/2/a:synaptics-rmi4-pt/serio1
E: MAJOR=13
E: MINOR=81
E: POINTINGSTICK_CONST_ACCEL=1.0
E: POINTINGSTICK_SENSITIVITY=200
E: SUBSYSTEM=input
E: USEC_INITIALIZED=9457066

Created attachment 1347083 [details]
scroll.evemu

example movement

please run sudo libinput measure trackpoint-range and follow its instructions, then attach the output here, thanks.

Created attachment 1347402 [details]
trackpoint-range

Here it is. However, please note that the instructions say I should do fast movements (which I did). But this issue is not about fast movements, but slow-to-medium ones.

I see the same problem on Thinkpad T500 with libinput 1.9 on Fedora 26. The trackpoint movement speed increased noticeably on shorter distances.

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

iirc the "mouse speed" slider is the one that affects the trackpoint, not the touchpad one. So you should be able to control the speed independently for trackpoint and touchpad. What speed is that slider set to?

There's a bug for GNOME to have the trackpoint independent: https://bugzilla.gnome.org/show_bug.cgi?id=789989

The T450s was one of the test laptops I used during the development of the new acceleration, so I'm surprised it doesn't work. Mine is still in box somewhere (I just moved) but I'll try to give this a test later this week. The range of the trackpoint is actually larger than the T440, so the obvious fix (adjusting the range) would make it even faster.

Having said all this, the range from slowest to fastest has also increased, so chances are just reducing the speed should be enough.

You're correct. Mouse speed slider affects the trackpoint (what a bad idea). I have currently set it to 0:
org.gnome.desktop.peripherals.mouse speed 0.0

I've tried to lower it and it helps somewhat, but overall it seems to me that the trackpoint is faster over short distances and slower over long distances than it used to be. If I slow it down to e.g. -0.5, the short distances are fine, but then it's very slow when trying to move from edge to edge (long distances). So in the previous acceleration scheme it had a large range of movement speed - light presses were slow and hard presses were fast. With the new acceleration scheme you can have both slow, or both fast, but not the full range. You say the opposite in your comment - perhaps you're talking about the hardware range, and I'm talking about the physically possible range. Yes, I can do extremely light touches that move the cursor just over a few pixels. But using the trackpoint in this way (being very careful about each touch) is not something that can be used all day. Or maybe you have a much better muscle control :)

Of course using the mouse slider to adjust this is suboptimal anyway, I also use a mouse with this notebook regularly and don't want to affect it. I'll comment in the gnome bug.

Basically what we did in this cycle was to remove the libinput acceleration and rely on the trackpoint firmware's acceleration. Which would explain why it feels slower and faster at the same time, depending on the range. The internal acceleration curve is mostly unknown, so overlaying a custom curve gives you weird behaviours. libinput still accelerates, but in a much more linear fashion.

"range" refers to the coordinates the trackpoint gives us. It works like a joystick with x/y axes - the harder you push the bigger the x/y coordinates are.
it's the only reference point we have, unlike touchpads or mice there is absolutely no physical reference point so a lot of this is guesswork.

I have a Dell Latitude E7470 and in it:

Device:           AlpsPS/2 ALPS DualPoint Stick
Kernel:           /dev/input/event5
Group:            10
Seat:             seat0, default
Capabilities:     pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   *button
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   flat *adaptive
Rotation:         n/a

and I've tried a few things, but the pointer goes with speed of light through the screen.
I do not think there is any de/acceleration working as the slightest touch jumps the pointer as quickly as it moves when I constantly press it.
I've tried xset, xinput --set, also this in /etc/X11/xorg.conf.d/01-pointer.conf:

Section "InputClass"
        Identifier "AlpsPS/2 ALPS DualPoint Stick"
        Driver "libinput"
        Option "Device" "/dev/input/event5"
        Option "AccelProfile" "float"
        Option "AccelSpeed" "-1"
EndSection

Nothing helps, it's really difficult to work.
If it's purely the firmware then it seems to working ok in laptop's BIOS which if I enter I can use the pointer it behaves very differently, normally.

regards.

see comment #3

Trackpoint sends: max x: 65, max y: 58 samples [2064, 2054]^C

Histogram for x axis deltas, in counts of 5
 -64: 
 -63: 
 -62: +
 -61: +++++
 -60: +++
 -59: +
 -58: ++++
 -57: 
 -56: +
 -55: +++++++++++
 -54: +
 -53: +
 -52: +++
 -51: +++
 -50: +
 -49: +
 -48: +
 -47: +
 -46: ++
 -45: ++
 -44: +++
 -43: +
 -42: +++
 -41: ++++
 -40: +++++
 -39: +
 -38: +++
 -37: ++
 -36: +++
 -35: +++++++
 -34: ++++++++
 -33: ++++
 -32: +++++++++
 -31: +++++
 -30: ++++
 -29: ++++
 -28: ++
 -27: ++++++
 -26: ++++++
 -25: ++
 -24: ++
 -23: +
 -22: +++
 -21: ++++++++
 -20: +++
 -19: +++
 -18: ++
 -17: +++
 -16: +++
 -15: +
 -14: ++
 -13: +
 -12: ++++
 -11: +++++++
 -10: ++++++++++++
  -9: +
  -8: ++
  -7: +++
  -6: ++
  -5: +
  -4: 
  -3: +
  -2: +++
  -1: 
   0: ++++
   1: +
   2: +++
   3: +
   4: +
   5: ++
   6: +
   7: ++
   8: +++
   9: ++
  10: ++++
  11: ++
  12: ++
  13: +
  14: ++
  15: +
  16: +++
  17: +++++
  18: +++
  19: +++
  20: ++
  21: +++++++++
  22: +++++
  23: +++++
  24: +++
  25: ++++++
  26: +++++++
  27: ++++
  28: ++
  29: ++
  30: +++
  31: +++
  32: +++
  33: +
  34: +
  35: +++
  36: ++++
  37: +
  38: +++++
  39: ++++
  40: +++++++++
  41: ++
  42: +
  43: ++
  44: +
  45: +++
  46: ++++
  47: +
  48: ++++++++
  49: ++
  50: ++
  51: +++
  52: +
  53: 
  54: 
  55: +
  56: +
  57: 
  58: +
  59: ++++++
  60: +
  61: +
  62: +
  63: 
  64: ++
  65: +
Histogram for y axis deltas, in counts of 5
 -58: +++
 -57: 
 -56: 
 -55: +++
 -54: 
 -53: 
 -52: 
 -51: +
 -50: +
 -49: 
 -48: 
 -47: ++
 -46: ++
 -45: +++
 -44: +
 -43: +
 -42: +
 -41: ++++
 -40: ++
 -39: ++++++
 -38: ++++
 -37: +
 -36: +
 -35: ++++
 -34: ++
 -33: +
 -32: +
 -31: 
 -30: +
 -29: +++++
 -28: +++
 -27: +
 -26: ++++
 -25: ++
 -24: ++++
 -23: +++
 -22: +
 -21: ++++++
 -20: +++++
 -19: ++
 -18: ++
 -17: ++++++++++
 -16: ++++++++++
 -15: +++++++
 -14: ++++
 -13: +++++++++
 -12: ++++
 -11: +++++++++++
 -10: +++++
  -9: ++++
  -8: +++++
  -7: ++++++++
  -6: +++++
  -5: ++
  -4: +++
  -3: +
  -2: ++++++
  -1: ++
   0: ++++++
   1: 
   2: ++++
   3: +
   4: +
   5: ++
   6: +++++
   7: ++++
   8: ++
   9: ++
  10: ++
  11: +++++
  12: +++
  13: +
  14: ++
  15: ++++++
  16: ++++++
  17: ++++++
  18: ++
  19: ++
  20: +++++
  21: +++++++
  22: ++++
  23: ++
  24: ++++
  25: +++
  26: ++++
  27: ++++
  28: ++++++
  29: +++
  30: +++++++++
  31: ++++++++++
  32: ++++++++++
  33: +++++++++++++++++++++++
  34: +++++++++++++++++++++++++++++++++
  35: ++++++
  36: 
  37: ++
  38: 
  39: 
  40: 
  41: 
  42: 
  43: 
  44: 
  45: 
  46: 
  47: 
  48: 
  49: 
  50: 
  51: +
Average for abs deltas: x:  31 y:  23
Median for abs deltas: x:  31 y:  23
95% percentile for abs deltas: x:  59 y:  45

please attach information that spans more than 10 lines or so. it makes it hard to read through bugs when the information is separated by multiple pages of logs.

Looks like a LIBINPUT_ATTR_TRACKPOINT_RANGE=60 hwdb entry would be useful for you. Add that with a dmi match to /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb and read https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_hwdb_changes on what to do. This should adjust the range to the real trackpoint range. Let me know how you go and whether it changes/improves things, thanks.

I don't think I understand. I paste a complete out the tool gave, there is certainly more than 10 lines there. I do not know what you mean by multiple pages neither.

I add following:

# DELL Latitude E7470
libinput:name:*AlpsPS/2 ALPS DualPoint Stick:dmi:*
 LIBINPUT_ATTR_TRACKPOINT_RANGE=60

but it does not seem has an effect on the speed of the pointer.

Dear Peter,

Where can I find a list of the configurables for (Lenovo) trackpoints? I
am using in my /etc/udev/hwdb.d/99-trackpoint.hwdb:

POINTINGSTICK_SENSITIVITY=300
POINTINGSTICK_CONST_ACCEL=1.5

but the trackpoint is still very slow and develops a lot of resistance.
One solution would be to increase the "Mouse Speed" in the GNOME control
panel, but that would affect my external mouse as well...

Maybe I am using the wrong config, putting them in the wrong file, or
perhaps there are some other configurables that may be useful?

Also, how are you determining that LIBINPUT_ATTR_TRACKPOINT_RANGE=60 is
appropriate for @lejeczek, judging from the provided histogram?

Thanks,
Justin

Just typed this one which should hopefully clarify things a bit: https://wayland.freedesktop.org/libinput/doc/latest/trackpoints.html


POINTINGSTICK_SENSITIVITY=300 - maximum is 255 so you're effectively setting it to 45 here which is the reason why it's so slow. and CONST_ACCEL is ignored by libinput now.

for Dell Latitude E7470 user,
in /usr/lib/udev/hwdb.d/70-pointingstick.hwdb first two lines existed, two more and my Latitude with 14" FHD screen together make my track-point usable, finally!

# Latitude E7470
evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE7470*:pvr*
 POINTINGSTICK_CONST_ACCEL=0.1
 LIBINPUT_ATTR_TRACKPOINT_RANGE=30
 POINTINGSTICK_SENSITIVITY=100

probably bit more tweaking coulg get it even more smooth.
thanks.

Dear Peter,

Thank you for the documentation.

libinput is telling me that "measure is not a libinput command or not installed. See 'libinput --help"

Indeed, it is not installed:

➜  ~ sudo libinput --version
1.9.3
➜  ~ ls /usr/bin/libinput*
/usr/bin/libinput  /usr/bin/libinput-debug-events  /usr/bin/libinput-list-devices

In libinput --help:

  measure <feature>
	Measure various device properties. See the man page for more info

I am using Fedora 27. I installed the latest version of libinput from the updates-testing repository.

Interestingly, the build log for this package [1], found here [2] shows that "libinput-measure" and "libinput-measure-trackpoint-range" were configured, built, and installed...

This can probably be fixed by compiling libinput from source instead of installing it from the Fedora repository...but that still leaves the question of why it is missing?! I tried a dnf reinstall too.

[1] https://kojipkgs.fedoraproject.org//packages/libinput/1.9.3/1.fc27/data/logs/x86_64/build.log

[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1005544

Thanks,
Justin

lejeczek:

try sensitivity 128 please, that's the default (iirc). I'd rather have it working well on the default sensitivity so that over time we can remove those udev hwdb entries.

CONST_ACCEL is ignored, setting it doesn't have any effect.

justin: dnf install libinput-utils

has anything changed with either:
libinput-1.9.3-1.fc27.x86_64
xorg-x11-drv-libinput-0.26.0-1.fc27.x86_64
?
for still with:

 # Latitude E7470
evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE7470*:pvr*
 LIBINPUT_ATTR_TRACKPOINT_RANGE=30
 POINTINGSTICK_SENSITIVITY=90

in /usr/lib/udev/hwdb.d/70-pointingstick.hwdb 
my trackpoint is again crazy super sensitive.

no updates to that in recent libinput, sorry. ETIME so far

Is there a way to request the old default configuration from 1.8?  The acceleration differences continue to drive me batty.  The range and sensitivity options aren't enough to get back the original behavior.

(I'm being picky, but I even game with trackpoint, and this has thrown me for enough of a loop that I'm going to try to downgrade back to 1.8 now)

@#21 - any idea why it stopped working, with above settings I've had  which had made my trackpoint finally normal?

As an update, downgrading to 1.8 did in fact get me back what I wanted.  I'll continue to use it for now.

There are ~ 5 problems with the new code:

1) There's a new bug where the cursor often jumps 5-20 pixels in a random direction before moving the direction you push.

2) The dead-zone around neutral is either gone or reduced to near-irrelevancy; putting a finger on or lifting a finger off the nub often causes the pointer to jump.

3) Accel starts much earlier--- there's now very little unaccelerated zone, causing repeated overshoots back and forth when trying to move slowly.

4) The 'sensitivity' and trackpoint range adjustment scale both the unaccelerated and accelerated zones. You can get one end of the scale right with an extreme adjustment, but then the other is way off.

5) The max delta is capped to low.  There's no way to use more pressure to flick to an edge.... it's a slow crawl across multiple monitors.

I'm sorry to be picky.  The trackpoint is my only pointing device across multiple machines, laptop and desktop, with multiple generations of Trackpoint (mostly TP II and TP IV) and has been for decades.  I don't even own a mouse.  Trackpoint feel is a major input comfort issue, enough so that I'm happy to give a shot at a patch and whatever testing you may like.

(Also, it's well known that different manufacturers' trackpoints feel and behave differently.  Trying to force Toshiba, Dell, HP, IBM, etc, all behave exactly the same is only going to annoy the dedicated users of each.)


Up to this point, everything had always been consistent and predictable across all the machines and various upgrades.  If it takes half as long to unlearn the muscle memory as it took to learn it, we're looking at over a decade before these changes will feel right.

fwiw, working on anything acceleration related is the most frustrating work I have done with libinput. I get almost daily reminders that someone doesn't like whatever current acceleration we have and how their muscle memory is ruined now.

Whenever I actually do work on it, I get near-zero testing of patches. When I do the feedback is almost always "nah, don't like it" with little to go on from there. When I do get some positive feedback and testing and things appear to improve and we merge it, I get complaints a month later from someone else. 

Meanwhile, no one affected seems to be motivated enough to even put a little bit of time into this. Because it's much easier to say "put a configuration option in" that actually figuring out what that option should actually *do*. So it always comes back to just me anyway. And I have a lot of other things on my slate, so forgive me for this dragging out beyond any reasonable time.

Hi Peter,

I didn't mean to pile on, only to make it clear it matters to me enough that I've dropped all my own work to get up to speed on it. I reported as soon as I was aware of the change, read the code, and could characterize it in detail (Fedora _just_ shipped it, it showed up in my update yesterday).  If this is frustrating enough that you want to just hurl it at me for now, I'm cool with that.  I want to work with upstream, not against it.

I also didn't want to start tossing off patches or change suggestions without first getting input. 

My biggest question: Was the impetus here a cleanup, an attempt at rationalization across hardware, an attempt at consistency with Windows (which does use a different acceleration), or an improvement to how the Trackpoint feels for beginners?

(In reply to Peter Hutterer from comment #25)
> Meanwhile, no one affected seems to be motivated enough to even put a little
> bit of time into this.

I'm sorry, I might have missed this, but what can we do to provide helpful feedback?

Thank you Peter for your work. I am happy with libinput 1.9 on my Thinkpad T470. I just needed to adjust the pointing stick acceleration and the "mouse speed" inside GNOME control panel. Please continue your good work.

Monty:

The goal of the refactor in 1.9 was:
* better predictability
* no magic system configuration, libinput takes over all acceleration
* larger configuration range
* ability for per-device quirks (but these quirks are standardised/reliably measured)

Previously we had an acceleration curve in libinput that applied on top of the acceleration curve in the hardware. So that gave you a different, oddly shaped curve with different slopes, plateaus, etc. Based on whatever magic the firmware does.
Look at the mouse curve in https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html#ptraccel-trackpoint and imagine two of those randomly on top of each other.

Now we just apply a linear acceleration and make use of the firmware curve instead. which in theory makes it more predictable. and you can shout at lenovo, dell, or whoever instead of me for having a terrible acceleration curve.

No magic system configuration: a few years ago we made the mistake of putting two udev values into systemd hwdb with the intention of making trackpoints feel the same out of the box. This doesn't really work, either libinput is in charge of all acceleration or the results are unpredictable. But as a side effect and for the time being this means that we have to hope that the POINTINGSTICK_SENSITIVITY property refers to the value set in sysfs. So we can undo its effect and go to a 'normalised' range (haha. hahahaha. /me wipes a tear)

larger configuration range: the difference between slowest and fastest before was quite narrow. Now it goes from "how do you like swimming in tar" to "ACME rocket-fueled ice-skates". Again in the hope that while the default value is reliably insufficient at least the range is wide enough to make it useful.
https://github.com/whot/libinput/blob/master/src/filter.c#L1207

ability for device quirks: we now have the ability to set the LIBINPUT_ATTR_TRACKPOINT_RANGE property on a per-device basis so libinput can know the range the device will give it.

I also just noticed that the branch name that got merged was trackpoint-accel-v6, so this wasn't my first attempt...

Anyway, to fix this, here are the moving parts:
* trackpoints have no physical reference point and we cannot measure pressure consistently across devices. any testing comes down to 'feels good on the devices I have access too'.
* some trackpoints have sysfs knobs that change the behaviour, particularly the sensitivity setting. That's the udev property mentioned above.
* some trackpoints have in-firmware acceleration curves. I don't have a list of which ones. The closest to figuring this out would be to check for some sysfs files and hope.
* the actual data you get is messy,  sequences like [7, 7, 9, 8, 14, 7, 9, 8] for perceived identical physical pressure are common. That's a 100% deviation. 
* once you get to the higher pressure ranges, the sequences get even more unreliable, think [30, 40, 35, 55], etc.

For simplicity, let's assume at least the scanout rate is consistent and the same across devices.

So in libinput the only datapoints you really have are:
* the maximum delta value I get is N
* "I think this feels ok"

Everything else is highly variable or garbage.

The range can be 0-30, 0-128 and in one memorable device 0-1. The x/y range may not be the same but for our own sanity we assume it is.

Oh, and to top it off: you're working on *acceleration*, not movement. Which is (at least for me) one level removed from what the brain can grasp.


The argument "it worked great before" is a bit like "lottery tickets make you a millionaire". Only a select few would agree on that from first-hand experience.

(In reply to Justin Chiu from comment #28)
> Thank you Peter for your work. I am happy with libinput 1.9 on my Thinkpad
> T470. I just needed to adjust the pointing stick acceleration and the "mouse
> speed" inside GNOME control panel. Please continue your good work.

Justin, would you kindly share your final satisfying settings for ThinkPad T470 trackpoint? Trying to make something viable but with no success.

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

(In reply to Peter Hutterer from comment #29)

Thanks for the detailed reply despite lack of time.  It's much appreciated.

> The goal of the refactor in 1.9 was:
> * better predictability
> * no magic system configuration, libinput takes over all acceleration
> * larger configuration range
> * ability for per-device quirks (but these quirks are standardised/reliably
> measured)

OK.  And since commenting, I've talked to a few other Desktop folks about how libinput and the hwdb take on autoconfiguration.

> Previously we had an acceleration curve in libinput that applied on top of
> the acceleration curve in the hardware. So that gave you a different, oddly
> shaped curve with different slopes, plateaus, etc. Based on whatever magic
> the firmware does.

Noted. I can only comment in detail on IBM Trackpoint firmware (Trackpoint II through IV).

IBM's stated intent through development and refinement, as I've read in histories and interviews, was to keep the feel 'linear', that is, come up with a flat-feeling behavior, as mouse-like as possible, and let users layer their own desired feel on top using userspace configuration.  My experience matches this. So mouse acceleration curves work pretty well, and the IBM trackpoints have always felt the same in X.

The different trackpoints do have internal time-invariant force shaping techniques (especially TPIV), but I believe the intent is generally to make the Trackpoint feel more like a mouse. 

(Related, the negative-inertia on the TrackPointIV appears to be what is causing the averaging code to make the pointer jump in weird directions at the beginning of movement)

> Look at the mouse curve in
> https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.
> html#ptraccel-trackpoint and imagine two of those randomly on top of each
> other.

Well, I'm not talking bout anything random, I intend to collect data and determine in detail. :-)  It would also not be a huge stretch to collect a whole bunch of trackpoints from multiple manufacturers and track output vs force input.  I fully believe you they're quite different.  I even wonder what Lenovo has changed recently.

I'm making my own little logging app right now to show the raw input and force accel differences between old and new code.

> Now we just apply a linear acceleration and make use of the firmware curve
> instead. which in theory makes it more predictable. and you can shout at
> lenovo, dell, or whoever instead of me for having a terrible acceleration
> curve.

I'll shout (nicely/civilly) at you because you took away the behavior I've always liked, and I either have to convince you to change that, or fork the lib.

> No magic system configuration: a few years ago we made the mistake of
> putting two udev values into systemd hwdb with the intention of making
> trackpoints feel the same out of the box. This doesn't really work, either

Oh huh, some of the Desktop people think this is still the goal (lots of hwdb quirk entries).  I was repeatedly pointed to all the HWDB rules for eg touchpad.

> libinput is in charge of all acceleration or the results are unpredictable.
> But as a side effect and for the time being this means that we have to hope
> that the POINTINGSTICK_SENSITIVITY property refers to the value set in
> sysfs. So we can undo its effect and go to a 'normalised' range (haha.
> hahahaha. /me wipes a tear)

Agreed, configuration should all be in one place. I can see why evdev isn't it.

> larger configuration range: the difference between slowest and fastest
> before was quite narrow. Now it goes from "how do you like swimming in tar"
> to "ACME rocket-fueled ice-skates". Again in the hope that while the default
> value is reliably insufficient at least the range is wide enough to make it
> useful.
> https://github.com/whot/libinput/blob/master/src/filter.c#L1207

No problem with widening the possibility.  My issues (aside from bugs) are the point where acceleration starts, and the removal of the dead zone.  The default behavior with the new code, I can move my trackpoint by blowing on it.  And I can only stop that by setting the single config knob to 'swimming in tar'.

> Anyway, to fix this, here are the moving parts:
> * trackpoints have no physical reference point and we cannot measure
> pressure consistently across devices. any testing comes down to 'feels good
> on the devices I have access too'.

They translate force (and to an extent, rate of change of force) to pixels.  So I'm not really sure I buy that there's no physical refence, just that it's more challenging to measure than dpi.

In any case, I intend to measure it.  I have calibrated force measuring equipment (though not set up to do this, it'll take a little fabrication)

> * some trackpoints have sysfs knobs that change the behaviour, particularly
> the sensitivity setting. That's the udev property mentioned above.
> * some trackpoints have in-firmware acceleration curves. I don't have a list
> of which ones. The closest to figuring this out would be to check for some
> sysfs files and hope.

HWDB will give us vendor and detailed model info though, yes?

> * the actual data you get is messy,  sequences like [7, 7, 9, 8, 14, 7, 9,
> 8] for perceived identical physical pressure are common. That's a 100%
> deviation. 

On which devices?  I never noticed or perceived this on IBM trackpoints, which is not to say it wasn't happening.  FTR, I don't notice the averaging code making anything smoother.

> Everything else is highly variable or garbage.

I would be surprised if it was variable within a single model (or even vendor). I'd expect it to be very different across makers.

> The argument "it worked great before" is a bit like "lottery tickets make
> you a millionaire". Only a select few would agree on that from first-hand
> experience.

If I won the lottery daily/every time I played it over the past 25 years, I'd sure as hell keep playing the lottery.

Cheers, more in a bit. Taking this on is going to require some bootstrapping, and I was serious about being serious.

in /usr/lib/udev/hwdb.d/99-pointingstick.hwdb I have:


# Latitude E7470
evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE7470*:pvr*
 POINTINGSTICK_SENSITIVITY=20
 POINTINGSTICK_CONST_ACCEL=1.0
 LIBINPUT_ATTR_TRACKPOINT_RANGE=10

Changing some of those settings made my trackpoint useable, but a few days ago it stopped working, now changing values does not seem to have any effect.
Is there anything else I could try?

many thanks.

(In reply to Monty from comment #32)
> OK.  And since commenting, I've talked to a few other Desktop folks about
> how libinput and the hwdb take on autoconfiguration.

short answer: there are two parts, the hwdb is used to label things, then
other bits use those labels to actually do something. there are some system
properties (e.g. EV_ABS_*) that are parsed by a udev builtin and change the
devices directly and others (e.g. MOUSE_DPI) that are just system-wide
labels in the hope that they're useful (only libinput uses the dpi value
right now).

generally the rule is: if it's a hardware-specific thing that describes the
hardware in more detail, then it should be a system-wide property. but
behaviours should not be there. Hence why touchpad axis ranges are in the
hwdb, keycode overrides are too. but things like the pointer acceleration
should not be because it's too dependent on the user behaviour.

Also note: the hwdb is just a match&label vehicle. It doesn't do anything on
its own but export properties, external bits use those properties to do more,
like udev builtins that parse the EV_ABS overrides. but on its own it's just
a labelling system. libinput uses the hwdb too for its own private
configuration but that's just because the hwdb has convenient ways of
matching devices. so just "the hwdb" is a bit ambiguous because we usually
talk about the *effect* of what happens rather than the pure match&label
system that the hwdb is.

> > Previously we had an acceleration curve in libinput that applied on top of
> > the acceleration curve in the hardware. So that gave you a different, oddly
> > shaped curve with different slopes, plateaus, etc. Based on whatever magic
> > the firmware does.
> 
> Noted. I can only comment in detail on IBM Trackpoint firmware (Trackpoint
> II through IV).
> 
> IBM's stated intent through development and refinement, as I've read in
> histories and interviews, was to keep the feel 'linear', that is, come up
> with a flat-feeling behavior, as mouse-like as possible, and let users layer
> their own desired feel on top using userspace configuration.  My experience
> matches this. 

don't get me wrong, but unless you had jumped through hoops to disable
pointer acceleration under X, you didn't get any linear movement because the
X acceleration was always on top. It just happened that that acceleration
topped out really quickly, leaving to a pseudo-linear behaviour.

Anyway, main source I have here: https://blogs.epfl.ch/icenet/documents/Ykt3Eext.pdf
Page 43. This does not look like a linear power->movement ratio but more
like a standard linear acceleration function. Mind you, for all I know this
document is all out of date, I'd love to have more sources if you have them
because I'm doing a lot of darkness-stabbing here.


> Well, I'm not talking bout anything random, I intend to collect data and
> determine in detail. :-)  It would also not be a huge stretch to collect a
> whole bunch of trackpoints from multiple manufacturers and track output vs
> force input.  I fully believe you they're quite different.  I even wonder
> what Lenovo has changed recently.
> 
> I'm making my own little logging app right now to show the raw input and
> force accel differences between old and new code.

somewhat related: libevdev-python is on pip3 and probably the easiest to
track kernel events. Now sure you you'd measure force vs output without
some robot thing?

> > No magic system configuration: a few years ago we made the mistake of
> > putting two udev values into systemd hwdb with the intention of making
> > trackpoints feel the same out of the box. This doesn't really work, either
> 
> Oh huh, some of the Desktop people think this is still the goal (lots of
> hwdb quirk entries).  I was repeatedly pointed to all the HWDB rules for eg
> touchpad.

still the case, see first comment above. The specific ones I'm talking about
here that were a mistake are the POINTINGSTICK_SENSITIVITY and
POINTINGSTICK_CONST_ACCEL properties here. The rest is just fine in the
hwdb.

> > Anyway, to fix this, here are the moving parts:
> > * trackpoints have no physical reference point and we cannot measure
> > pressure consistently across devices. any testing comes down to 'feels good
> > on the devices I have access too'.
> 
> They translate force (and to an extent, rate of change of force) to pixels. 
> So I'm not really sure I buy that there's no physical refence, just that
> it's more challenging to measure than dpi.
> 
> In any case, I intend to measure it.  I have calibrated force measuring
> equipment (though not set up to do this, it'll take a little fabrication)

oh, in that case that'd be great! I know there's a physical reference but
let's be honest, if we can't reliably measure it it might as well not
exist, hence my previous comment.

> 
> > * some trackpoints have sysfs knobs that change the behaviour, particularly
> > the sensitivity setting. That's the udev property mentioned above.
> > * some trackpoints have in-firmware acceleration curves. I don't have a list
> > of which ones. The closest to figuring this out would be to check for some
> > sysfs files and hope.
> 
> HWDB will give us vendor and detailed model info though, yes?

the hwdb is just a matching mechanism, but we can use it to store
configuration based on vendor and model, yes. see the dmi matches we already
have in place for a lot of touchpads.

> 
> > * the actual data you get is messy,  sequences like [7, 7, 9, 8, 14, 7, 9,
> > 8] for perceived identical physical pressure are common. That's a 100%
> > deviation. 
> 
> On which devices?  I never noticed or perceived this on IBM trackpoints,
> which is not to say it wasn't happening.  FTR, I don't notice the averaging
> code making anything smoother.

Lenovo T440s which was the main development machine for this, but I had a
T450p around too (which behaves quite differently, interestingly enough).

Anyway, I'll take anything you can give me both in terms of data and in
terms of patches (or formulas) to apply as acceleration.

I just wanted to let you know, I love the result on Lenovo Thinkpad Yoga 260. Finally, the maxed out speed is actually fast. Thanks for the good work.

However, I agree that the acceleration feels a bit explosive - there is a point where it shoots through the roof, not in a way that is a problem for me on this device, but it does feel a little unnatural. I already got used to it in practical use, but I wouldn't mind if it was tweaked a bit.

Maybe it's time for the good old acceleration slider to return?

> Maybe it's time for the good old acceleration slider to return?

sigh. and what *exactly* should this slider do? that's the question I've been chasing down for way too long now.

You have obviously put much more thought into this than anyone else, so forgive me if this suggestion isn't very useful: however, if I were to implement it, I'd probably try something which takes A.) a curve that perceived as most non-accelerating - not necessarily linear, but something that feels like it to users - and B.) another curve that accelerates in a ludicrous manner, and C.) does a linear interpolation between the values of the two based on the slider. The curves themselves of course would be scaled by the regular speed slider as usual.

the code is in src/filter.c, it's relatively straightforward in that it gets timestamps and deltas (in device coordinates) and returns a normalized delta that can be passed to the caller. Feel free to experiment.

As I replied to you in https://bugs.freedesktop.org/show_bug.cgi?id=103244, adding things without knowing what/why we're adding things doesn't help anyone.

Hi, everyone,

I’ve been experiencing the same issue. Currently I have to downgrade to libinput-1.8.2 to use my TrackPoint (ThinkPad X1 Carbon 5th). Any update on this front? Any plan has been made? How can I best help? I’d be very happy to help debugging & testing on my device.

Best bet is updating to libinput git master (it's stable, don't worry) and using the new acceleration code, see:
https://wayland.freedesktop.org/libinput/doc/latest/trackpoints.html

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I have been woefully remiss in following up.  However: The new 'adaptive' mouse acceleration provides exactly the behavior I wanted.  Thanks to Peter and others for adding it.