Bug 98845 - Touchpad pointer acceleration off with Sony VAIO Pro 13
Summary: Touchpad pointer acceleration off with Sony VAIO Pro 13
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 98839
Blocks: 98535
  Show dependency treegraph
 
Reported: 2016-11-24 19:39 UTC by Jan Niklas Hasse
Modified: 2018-04-20 05:53 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Evemu output with fast finger movement (29.15 KB, text/plain)
2016-11-28 22:31 UTC, Daniel Serpell
Details
Evemu output with slow finger movement (187.68 KB, text/plain)
2016-11-28 22:31 UTC, Daniel Serpell
Details
Fast movement all the way from left to right, recorded using evemu GIT. (22.13 KB, text/plain)
2016-11-29 15:36 UTC, Daniel Serpell
Details
First try to hit small target, overshots a lot. (71.10 KB, text/plain)
2016-11-29 21:30 UTC, Daniel Serpell
Details
Second try to hit small target. (84.62 KB, text/plain)
2016-11-29 21:30 UTC, Daniel Serpell
Details

Description Jan Niklas Hasse 2016-11-24 19:39:45 UTC
After reading https://who-t.blogspot.de/2016/11/libinput-touchpad-pointer-acceleration.html I want to report, that libinput is unuseable for me on my Laptop, a Sony VAIO Pro 13.

I don't know how to post udev info "with the correct event node for [my] device" (see https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html#udev_info). How can I find out what is the correct event node?

$ cat /sys/class/dmi/id/modalias
dmi:bvnAmericanMegatrendsInc.:bvrR1044V7:bd03/24/2014:svnSonyCorporation:pnSVP1321C5E:pvrC60C18CT:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:

Dimensions of my touchpad: 105mm x 65 mm

Description of the problem: It feels a little bit like there's an input lag.
Comment 1 Peter Hutterer 2016-11-28 06:02:31 UTC
run evemu-record without arguments, that should list all devices and tell you which event node your touchpad has.

The input lag is probably caused by bug 90735, update to 1.5.2 and that should be gone.
Comment 2 Jan Niklas Hasse 2016-11-28 11:30:06 UTC
evemu-record shows me no available devices :(

> The input lag is probably caused by bug 90735, update to 1.5.2 and that should be gone.

Okay, I'll wait until it lands in Fedora 25.
Comment 3 Peter Hutterer 2016-11-28 20:30:00 UTC
run evemu as root/sudo, that should show the devices then. Fedora update is this one btw: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c53d9044dd
Comment 4 Daniel Serpell 2016-11-28 22:31:03 UTC
Created attachment 128257 [details]
Evemu output with fast finger movement
Comment 5 Daniel Serpell 2016-11-28 22:31:41 UTC
Created attachment 128258 [details]
Evemu output with slow finger movement
Comment 6 Daniel Serpell 2016-11-28 22:31:59 UTC
Hi!

I have (almost) the same notebook, and touchpad is unuseable for me also, slow finger motion moves the cursor too fast; and fast finger motion moves the cursor too slow.

My notebook is a Sony Vaio Pro 13 from 2012, SVS13A15GLB.

My info, in Debian sid:

daniel@daniel-vaio:~$ sudo evemu-record > touchpad-move-slow.evemu
  # Slow finger movement

daniel@daniel-vaio:~$ sudo evemu-record > touchpad-move-fast.evemu
  # Fast finger movement

daniel@daniel-vaio:~$ sudo udevadm info /sys/class/input/event1
P: /devices/platform/i8042/serio1/input/input2/event1
N: input/event1
E: DEVNAME=/dev/input/event1
E: DEVPATH=/devices/platform/i8042/serio1/input/input2/event1
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=60
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_TOUCHPAD_INTEGRATION=internal
E: ID_INPUT_WIDTH_MM=117
E: LIBINPUT_DEVICE_GROUP=11/2/7/1b1:isa0060/serio1
E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1
E: MAJOR=13
E: MINOR=65
E: SUBSYSTEM=input
E: USEC_INITIALIZED=4394288

daniel@daniel-vaio:~$ cat /sys/class/dmi/id/modalias
dmi:bvnInsydeCorp.:bvrR0142C5:bd05/17/2012:svnSonyCorporation:pnSVS13A15GLB:pvrC60ALELD:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:
Comment 7 Daniel Serpell 2016-11-28 22:33:10 UTC
Sorry, forgot to include my touchpad dimensions: 119x62mm.
Comment 8 Peter Hutterer 2016-11-28 23:50:43 UTC
Daniel - have you tried libinput 1.5.2 yet?
Comment 9 Daniel Serpell 2016-11-29 02:00:37 UTC
Hi,

(In reply to Peter Hutterer from comment #8)
> Daniel - have you tried libinput 1.5.2 yet?

As 1.5.2 is not available in Debian yet I made a package by applying the diff from 1.5.1->1.5.2 over the 1.5.1 source deb.

After testing a little, it seems (but my be a placebo effect) that the really slow movements are better in this version, but the main problem persists: the acceleration is too low, or triggers when the movement is still too low.

This means that you have to adjust the "touchpad speed" in the gnome settings to a low value to be able to use the touchpad reliably, but then you need to move the finger about three times over the touchpad to move the pointer from one corner to the opposite one in the screen.
Comment 10 Peter Hutterer 2016-11-29 09:19:29 UTC
Daniel, please get evemu from git. Debian hasn't updated the package in 2 years and some information that I rely on is missing.
https://cgit.freedesktop.org/evemu/

What I need:
Move the pointer to the left-most edge of the screen. Then start the recording,
put your finger close into the left-most quarter of the touchpad. In one quick motion move to the right edge on the touchpad. should only take as long as it takes to say "pop" and it should be a natural motion. One motion only, no corrections. Attach the recording here and tell me how far the cursor got, approximately.
Comment 11 Daniel Serpell 2016-11-29 15:35:59 UTC
Hi!

(In reply to Peter Hutterer from comment #10)
> Daniel, please get evemu from git. Debian hasn't updated the package in 2
> years and some information that I rely on is missing.
> https://cgit.freedesktop.org/evemu/
> 
> What I need:
> Move the pointer to the left-most edge of the screen. Then start the
> recording,
> put your finger close into the left-most quarter of the touchpad. In one
> quick motion move to the right edge on the touchpad. should only take as
> long as it takes to say "pop" and it should be a natural motion. One motion
> only, no corrections. Attach the recording here and tell me how far the
> cursor got, approximately.

Ok, the cursor moved all the way from the left to the right of the screen. Notie that I set the speed to slow in the gnome settings:

 $ gsettings get org.gnome.desktop.peripherals.touchpad speed
 -0.65441176470588236

As the touchpad measures 119mm, moving the finger all the way from left to right is not really confortable, as I have to move not only the wrist but the whole arm to reach from one side to the other :-P
Comment 12 Daniel Serpell 2016-11-29 15:36:37 UTC
Created attachment 128268 [details]
Fast movement all the way from left to right, recorded using evemu GIT.
Comment 13 Peter Hutterer 2016-11-29 21:06:43 UTC
apologies, had to turn everything off yesterday when an electrician came around and didn't finish my comment. 

Second recording I'll need:
Select a target a few pixels across, e.g. the tab-close icon of a Firefox browser tab. move the cursor to ca 2 cm down and 2 cm right of that icon. Start the recording, put your finger down and try to click the cross in one motion. If you overshoot significantly, stop and restart (attach the recording here with a note though, could be useful). If you overshoot only slightly, correct and stop when you're ready to click (don't actually click). Make the whole thing a natural motion, don't try to force yourself to go slow so you hit the target on the first go. And please do so with a speed setting of 0.0, otherwise it's too hard to compare.
Comment 14 Daniel Serpell 2016-11-29 21:29:10 UTC
Hi!,

(In reply to Peter Hutterer from comment #13)
> apologies, had to turn everything off yesterday when an electrician came
> around and didn't finish my comment. 
> 
> Second recording I'll need:
> Select a target a few pixels across, e.g. the tab-close icon of a Firefox
> browser tab. move the cursor to ca 2 cm down and 2 cm right of that icon.
> Start the recording, put your finger down and try to click the cross in one
> motion. If you overshoot significantly, stop and restart (attach the
> recording here with a note though, could be useful). If you overshoot only
> slightly, correct and stop when you're ready to click (don't actually
> click). Make the whole thing a natural motion, don't try to force yourself
> to go slow so you hit the target on the first go. And please do so with a
> speed setting of 0.0, otherwise it's too hard to compare.

I had to practice a while, as the pointer moves fast with the 0.0 speed setting.

Also, I noticed that if I reply the file with "./evemu-play /dev/input/event1  < ~/touchpad-click-tab.evemu", the pointer ends up in a different position than when recording... should that be repeatable?
Comment 15 Daniel Serpell 2016-11-29 21:30:09 UTC
Created attachment 128274 [details]
First try to hit small target, overshots a lot.
Comment 16 Daniel Serpell 2016-11-29 21:30:41 UTC
Created attachment 128275 [details]
Second try to hit small target.
Comment 17 Peter Hutterer 2016-11-30 06:58:07 UTC
(In reply to Daniel Serpell from comment #14)
> Also, I noticed that if I reply the file with "./evemu-play
> /dev/input/event1  < ~/touchpad-click-tab.evemu", the pointer ends up in a
> different position than when recording... should that be repeatable?

it should be, but timing matters a lot here given it's acceleration. I re-recorded the recording and get slightly different results. That's unavoidable afaict because evemu injects events into the kernel, so there's always a bit of a delay and it's hard to predict.

The problem is that for pointer acceleration purposes it makes it hard to reproduce the exact issue, even accounting for the fact that it's hard to guess the 'feel' of a device just based on a recording.
Comment 18 Peter Hutterer 2016-12-15 08:03:11 UTC
https://github.com/whot/libinput/tree/wip/touchpad-pointer-accel-v3
if you're willing to try. It's still WIP but tell me I'm at least going in the right direction.
Comment 19 Peter Hutterer 2016-12-21 03:20:48 UTC
See bug 98535, please try libinput master and report back whether this improves things. Thanks
Comment 20 Daniel Serpell 2016-12-23 23:40:39 UTC
Hi,

I tried libinput-master from GIT, I had to apply the patch from https://github.com/systemd/systemd/pull/4772/commits/f644a6da7a6f11d20116842e2ce1c7e9c0b0ad64 to fix a failing test, and the library versions went down from the installed 1.5.3.

Pointer movement is a lot better after this, I would say the bug is fixed :)

Thanks!
Comment 21 Peter Hutterer 2017-01-03 00:49:28 UTC
great, thanks!
Comment 22 Jan Niklas Hasse 2017-01-12 14:00:04 UTC
Will this fix be released with 1.5.4?
Comment 23 Peter Hutterer 2017-01-13 00:41:17 UTC
no, sorry. too many changes for what's supposed to be a stable branch. 1.6 is fully backwards compatible with 1.5 though so you can update as you desire.
Comment 24 Jan Niklas Hasse 2017-07-14 21:37:20 UTC
Hi, I've just updated to Fedora 26 from 25 which now comes with libinput 1.7.3. Unfortunately I have to say that it isn't fixed for me :(

It feels better than with 1.5.4 (the input lag is gone, but precise movements are still hard), but not as good as with the synaptics driver.

I've tried all three profiles (default, adaptive, flat) and also Xorg vs Wayland: I'm always missing buttons since very short movements are really off. I can no longer compare it with synaptics, since Fedora removed that. But I could run that from a live USB stick and record a comparison video, would that help?
Comment 25 Nate Graham 2017-07-14 22:09:23 UTC
Precise movements being bad is probably hysteresis, which is tracked by https://bugs.freedesktop.org/show_bug.cgi?id=98839
Comment 26 Peter Hutterer 2018-04-20 05:53:25 UTC
Closing, libinput 1.8 or so had new touchpad accel code, this bug is now half a year old. The current bug to complain about touchpad acceleration is Bug 101139


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.