I'll need an evemu-record from one of these cursor jumps so I can replay it here please, thanks.

Here is the output of evemu-record

https://paste.ee/p/JfaS3

The jump happen near the end. By the way the "tap to click" feature is enabled.

(In reply to Peter Hutterer from comment #1)
> I'll need an evemu-record from one of these cursor jumps so I can replay it
> here please, thanks.

Hello Peter, did you found something ?

Created attachment 123042 [details]
jump.evemu

Please don't use pastebins for bugzilla attachments, they expire randomly and don't work with tools that interact with bugzilla.

Content of the pastebin attached here

sorry, this recording is too noisy, i can't identify the jump here. Please try to record a single sequence that reproduces it, as short as possible.

Also note that we just changed the hwdb for cyapa touchpads so their behaviour may change a bit. Please make sure you're either on git master or libinput 1.2.4, thanks.

Created attachment 123051 [details]
Cursor jump

(In reply to Peter Hutterer from comment #4)
> Please don't use pastebins for bugzilla attachments, they expire randomly
> and don't work with tools that interact with bugzilla.

Ok, sorry.

(In reply to Peter Hutterer from comment #5)
> sorry, this recording is too noisy, i can't identify the jump here. Please
> try to record a single sequence that reproduces it, as short as possible.
> 
> Also note that we just changed the hwdb for cyapa touchpads so their
> behaviour may change a bit. Please make sure you're either on git master or
> libinput 1.2.4, thanks.
I installed libinput 1.2.4 and checked that the hwdb integrate the patch.
Here is a shortest sequence that I can record. I hope it's ok.

whoah. this is a kernel tracking issue, the device jumps straight from 806/395 to 154/881. Benjamin, what's the deal with kernel tracking on cyapas?


  E: 0.150323 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +11ms
  E: 0.161217 0003 0035 0806      # EV_ABS / ABS_MT_POSITION_X    806
  E: 0.161217 0003 0036 0395      # EV_ABS / ABS_MT_POSITION_Y    395
  E: 0.161217 0003 003a 0014      # EV_ABS / ABS_MT_PRESSURE      14
  E: 0.161217 0003 0000 0806      # EV_ABS / ABS_X                806
  E: 0.161217 0003 0001 0395      # EV_ABS / ABS_Y                395
  E: 0.161217 0003 0018 0014      # EV_ABS / ABS_PRESSURE         14
  E: 0.161217 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +11ms
  E: 0.172303 0003 0035 0154      # EV_ABS / ABS_MT_POSITION_X    154
  E: 0.172303 0003 0036 0881      # EV_ABS / ABS_MT_POSITION_Y    881
  E: 0.172303 0003 003a 0016      # EV_ABS / ABS_MT_PRESSURE      16
  E: 0.172303 0003 0000 0154      # EV_ABS / ABS_X                154
  E: 0.172303 0003 0001 0881      # EV_ABS / ABS_Y                881
  E: 0.172303 0003 0018 0016      # EV_ABS / ABS_PRESSURE         16
  E: 0.172303 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +11ms

(In reply to Peter Hutterer from comment #7)
> whoah. this is a kernel tracking issue, the device jumps straight from
> 806/395 to 154/881. 

Yeah pretty annoying :( I hope Benjamin can help :)
Thanks.

Hmm, there is no kernel tracking for cyapa. The events are forwarded from the device to the user space, so this is either a firmware bug, or a driver bug. 

Before using the hammer and force the kernel tracking for every Gen 3 Cyapa device, I'd like to talk to the author of the driver first.

It's more likely a driver bug because that doesn't happen with synaptics driver.

Can't it be a libinput bug since synaptic work ?

(In reply to Paviluf from comment #11)
> Can't it be a libinput bug since synaptic work ?

synaptics in fedora has a patch that discards any movement larger than 20mm. this patch isn't upstream though, so a vanilla synaptics would have the same jumps.

for libinput we try to fix the issue properly, i.e. in the kernel driver or through hw-specific fixes. so let's see what the cyapa driver author says first.

Created attachment 123293 [details]
V2.1 firmware to Cypress CYTRA-101008-00 trackpad device.

The v2.1 firmware image for Cypress CYTRA-101008-00 trackpad device which may be used on HP Chromebook 14 (Falco).

Dudley: attaching a firmware to a bugzilla is not a good idea. The firmware is a binary blob and impossible to verify, so I can't really recommend to anyone to download this and use it locally. Can you provide a link to the official distribution site?

Also, I'm a bit worried about the "may be used" - so you're not sure if this is the right device?

Hi,

After communicated with Jeremy, I got the following information:
product_id: CYTRA-101008-00
firmware_version: 2.0
baseline <max, min>: 103 93

Based on the reported baseline values, it's not bad, it should not affect the performance of the trackpad device.

And after the v2.0 firmware image, I found there was a v2.1 firmware that have the FH parameter turned to improve the noise immunity.
Could you try if this v2.1 firmware image can help on this cursor jump issue.
Steps to update with the v2.1 firmware image:
1) Make the Chromebook enter development mode;
2) Copy the v2.1 firmware image to the /lib/firmware/ on the system.
   # mount / -o rw,remount
   # mv /lib/firmware/cyapa.bin /lib/firmware/cyapa_v2.0.bin
   # cp /path/to/v2.1_firmware_image.bin /lib/firmware/cyapa.bin
3) Force to update the firmware image.
   # echo cyapa.bin > /sys/bus/i2c/devices/i2c-7/7-0067/update_fw

4) After the update, you can double check the baseline (normally, should be no problem).
   # cat /sys/bus/i2c/devices/i2c-7/7-0067/baseline
5) If the baseline is not good, can force the trackpad device to re-calibrate the trackpad device. This operation can be done multi-time until get good baseline (normally, at most two).
   # echo 1 > /sys/bus/i2c/devices/i2c-7/7-0067/calibrate

If the v2.1 firmware has no help on the cursor jump issue, or any other driver issue  of this trackpad device, please freely send email to Dudley Du <dudl@cypress.com>.
And I have reported this issue to our firmware team. But since the Gen3 trackpad device has out of life, so I'm not sure if there would be fully support from the firmware team. I will update any information in this report if there any.

Thanks,
Dudley

Hello Dudley,
Thank you for joining us here after our communication by email.
I tried this 2.1 firmware but the problem is still here.

Hi Jeremy,

Thanks for your try and response.
It seems that the noise immunity improvement has no help on this issue, so this issue should not be caused by the noise.

After analysized the captured report data in jump.evemu file, I got following inforamtion:
1) it seems that the first finger doing tapping on the trackpad device. Because in most case, the finger touch data located in a very small area.
2) when the first finger appearred on the trackpad device, the second finger may appear later and disappeared before the first figner left;
   Such as the fingers data of TRACKING_ID of 92, 93.
3) When the first figner appeared on the trackpad device, the second finger may appear later and disappeared after the first finger left;
   Such as the fingers data of TRACKING_ID of 68, 72,94, 96,99, 101.
4) When the first finger appeared on the trackpad device, the second finger may appear immediaterly after the first finger left.
   At this situation, the first finger left event won't be seen, because it was immediately replaced by the second finger when it left, so the second finger would be recognized as the first finger.
   Such as the finger data of TRACKING_ID of 104.
5) Beside the first appeared finger, the second finger would appeare within a almoust fixed area. This fixed area exists in the area as the rectangle from <61, 833> to <169, 877>.
6) The second finger would appeare and disappear, would not exist all the time. When there was an finger on the trackpad, the ghost finger then may appear.

Based on the above apalysis, I think there may be a ghost finger issue onthe the trackpd device. The second appeared finger was just the ghost finger.
So when the symptom of item 4) happpend, it's sure that the cursor jump will be seen on the screen.

To doulbe confirm on these symptoms, could you help double check that if it was possible that there was a ghost finger reported even there was no finger touch on the trackpad device?
Or could you try to press the trackpad with a non-conductor object on the trackpad device, which may help to reproduce the ghost finger issue.
Because the ghost may appear and disapper by itself, so it seems that the ghost finger was on the edge to be triggered or not on the trackpad device.

If the ghost finger happened on the trackpad device, it may indicate the hardware has been broken. For example, in the manufacture, there is a foreign matter or air was brought in between the malar and the PCB. Or some other factors, that has affect the sensors on the fixed area.
So could you also try anohter trackpad on anthoer HP Falco Chromebook?

Thanks,
Dudley

(In reply to Dudley Du from comment #17)
Hi Dudley,

Thank you for your analysis.

> To doulbe confirm on these symptoms, could you help double check that if it
> was possible that there was a ghost finger reported even there was no finger
> touch on the trackpad device?

Sorry but I don't know how I can do this.

> Or could you try to press the trackpad with a non-conductor object on the
> trackpad device, which may help to reproduce the ghost finger issue.
> Because the ghost may appear and disapper by itself, so it seems that the
> ghost finger was on the edge to be triggered or not on the trackpad device.

With a non conductor object the jump doesn't occur but the click is not taken into account. The click is triggered only when I have something conductor on the touchpad. If I let a finger on the touchpad and click with a non conductive thing there is no jump. 

I don't know if it's relevant because the jump happen when I move the cursor with the right finger, quickly release it and click with the left finger.

> If the ghost finger happened on the trackpad device, it may indicate the
> hardware has been broken. For example, in the manufacture, there is a
> foreign matter or air was brought in between the malar and the PCB. Or some
> other factors, that has affect the sensors on the fixed area.

I would say that is, even if it's possible, very unlikely.

> So could you also try anohter trackpad on anthoer HP Falco Chromebook?

I can't do that.

I don't know if that matter but in GalliumOS and ChromeOS (they both use the ChromeOS driver and I don't know if there is some kind of patch that discards any movement larger than 20mm like in synaptics) there is no jump too.

fwiw, I just pushed a patch to libinput to at least detect these jumps and discard them. This doesn't fix the problem (and indeed it can only be fixed in the kernel) but it should at least make the behaviour a bit nicer.

https://wayland.freedesktop.org/libinput/doc/latest/touchpad_jumping_cursor.html

I found a same CYTRA-101008-00 trackpad with v2.0 firware for the HP Falco, and did many tests on it, no siliar issue found. So it's highly possible that the trackpad device was broken, and the cursor jump was caused by the hardware issue.

To filter out the cursor jump, the trackpad doesn't support the accurate detect of moving speed faster than 2m/s, so when the jump speed exceed the limited distance based on the time, it should be discard and won't affect the fast swipe gesture. But for the jump less 2m/s, a balence may required bewteen the swipe gesture and the cursor jump detect/discard.

Thanks,
Dudley

(In reply to Peter Hutterer from comment #19)
> fwiw, I just pushed a patch to libinput to at least detect these jumps and
> discard them. This doesn't fix the problem (and indeed it can only be fixed
> in the kernel) but it should at least make the behaviour a bit nicer.

Thank you very much Peter ! If that do the same thing than synaptics it's a perfect workaround for me :)

The patch will be in libinput 1.3 it seems ?

(In reply to Dudley Du from comment #20)
> I found a same CYTRA-101008-00 trackpad with v2.0 firware for the HP Falco,
> and did many tests on it, no siliar issue found. So it's highly possible
> that the trackpad device was broken, and the cursor jump was caused by the
> hardware issue.

Great you found one ! How did you made the tests ? Like I said, in ChromeOS it's not happening. To make a reliable test it should be on Fedora 23 + updates.

(In reply to Dudley Du from comment #20)
> I found a same CYTRA-101008-00 trackpad with v2.0 firware for the HP Falco,
> and did many tests on it, no siliar issue found. 

To make the jump happen move the cursor to up right with the right finger, quickly release it and click with the left finger.

alternatively tapping with the two fingers (like playing an old-style arcade game) usually reproduces the issue, at least on all other touchpads we've seen this on. The key is to get the finger to move from one position to the other faster than the HW refresh rate. It's a race condition, so it'll take a few tries.


(In reply to Paviluf from comment #21)
> The patch will be in libinput 1.3 it seems ?

yep, it's queued for 1.3

(In reply to Peter Hutterer from comment #24)
> yep, it's queued for 1.3
Great ! Thanks.

Peter can you confirm that a proper fix should be in the Kernel driver or the firmware ?

yes, the fix should be in either of those two. libinput relies on the kernel to do finger tracking, if the finger tracking is incorrect that should be fixed there.

(In reply to Peter Hutterer from comment #26)
> yes, the fix should be in either of those two. libinput relies on the kernel
> to do finger tracking, if the finger tracking is incorrect that should be
> fixed there.

Thank you ! I hope Dudley Du will fix this :)

Sorry, for the Gen3 trackpad device, I could not help to fix it.

Indeed, for the alternatively tapping with the two fingers, there is a balance with the fast swipe operation. If turned the alternatively tapping with the two fingers gesture with more accurate finger tracking, then the fast swipe gesture will be broken in much short limited distance, it may become not acceptable for fast swipe gesture.
So as I know, for all Gen3 trackpad device, it was much more focused on the fast swipe gesture performance.

Thanks,
Dudley

Dudley: so if I read this right, this cannot/won't be fixed in the firmware. And I suspect not in the kernel either then. We can put a device-specific quirk into libinput to discard some of these events. What's the best way to identify Gen3 devices from userspace?

(In reply to Dudley Du from comment #28)
> Sorry, for the Gen3 trackpad device, I could not help to fix it.

Really, there is nothing we can do to properly fix this problem ?

As I learned, it is YES.
I discussed it with with our FW engineers, they said that there was a balance with the fast swipe gesture and the quick drum gesture for those Gen3 trackpad devices. So if returned for the special case, it would break other gestures' performance, and all things and process should be rerun and retest.

I think the best way filter it in the libinput currently.
The method to identify the Gen3 trackpad device is to read the product_id of the device. I will collect and send out all the Gen3 trackpads' product_id list a little later.

Thanks,
Dudley

There two method to detect the trackpad device,
1) export the value of cyapa->gen information through sysfs system from the cyapa driver;
2) read the product_id information from sysfs system of the trackpad device, then check it with following product id list.

The full list of Gen3 trackpad devices are listed below:
CYTRA-101003-00
CYTRA-101008-00
CYTRA-101009-00
CYTRA-102001-00
CYTRA-102003-00
CYTRA-102004-00
CYTRA-102005-00
CYTRA-102006-00
CYTRA-102007-00
CYTRA-102008-00
CYTRA-102010-00

CYTRA-103002-00
CYTRA-103003-00
CYTRA-103006-00
CYTRA-103007-00

CYTRA-104006-00
CYTRA-104007-00
CYTRA-104008-00
CYTRA-104009-00

CYTRA-115001-00
CYTRA-116001-00
CYTRA-116002-00
CYTRA-116003-00
CYTRA-116004-00
CYTRA-116005-00
CYTRA-116006-00
CYTRA-116007-00
CYTRA-116008-00

Thanks,
Dudley

Paviluf, please attach the udevadm info --export-db output so I can check if the product_id is hiding in udev somewhere (where it'd be easily discoverable by libinput)

Created attachment 123643 [details]
Output of "udevadm info --export-db"

can you give me this one as well please: udevadm info -a /sys/class/input/event14

Created attachment 123645 [details]
Output of "udevadm info -a /sys/class/input/event14"

Of course, here it is.

Hi  Peter Hutterer,

One more information, hope it can help to you.
As I know, for the Gen3 trackpad device shipped currently, the I2C/SMBus address are all 0x67. The later Gen5/Gen6 trackpad devices are all 0x24.
So if it is cyapa trackpad device, then based on the I2C address 0x67, the old Gen3 trackpad device can be identified also.

Thanks,
Dudley

As the data shown in the event14.txt file, I found the ATTRS{baseline}="155 27",
This baseline value should be abnormal, it should be force re-calibrated through the calibrate interface without any finger/conductor on it.

The attirbute "mode" - ATTRS{mode}=="gen3 operational" can also be used to identify the Gen3 trackpad device, it exprots the trackpadd device's running mode with the generation value. Such as "gen3 operational"/"gen3 bootloader".
Note, this attribute "mode" has been removed in the latest driver in the kernel.

(In reply to Dudley Du from comment #38)
> As the data shown in the event14.txt file, I found the ATTRS{baseline}="155
> 27",
> This baseline value should be abnormal, it should be force re-calibrated
> through the calibrate interface without any finger/conductor on it.

An other bug for this touchpad I guess... No one should have to force re-calibrated his touchpad...

Dudley can you give me the v. 2.0 of the firmware please. Just in case there is more bug in 2.1. Thanks !

(In reply to Dudley Du from comment #38)
> As the data shown in the event14.txt file, I found the ATTRS{baseline}="155
> 27",
> This baseline value should be abnormal, it should be force re-calibrated
> through the calibrate interface without any finger/conductor on it.

sorry, I can't quite parse this: what do you mean this needs to be force recalibrated? how is this done, and how can we automate this?

> The attirbute "mode" - ATTRS{mode}=="gen3 operational" can also be used to
> identify the Gen3 trackpad device, it exprots the trackpadd device's running
> mode with the generation value. Such as "gen3 operational"/"gen3 bootloader".
> Note, this attribute "mode" has been removed in the latest driver in the
> kernel.

if it's been removed we can't use it then, so we'll have to do some hacky match on the 67 address.


(In reply to Paviluf from comment #39)
> An other bug for this touchpad I guess... No one should have to force
> re-calibrated his touchpad...

true, but if the touchpad is out of whack and we can fix it in the firmware/device I'd rather do that than putting exceptions into libinput.

Created attachment 123765 [details]
V2.0 frimware for Cypress CYTRA-101008-00 trackpad device

The last formally released v2.0 firmware image for all chipped Cypress CYTRA-101008-00 trackpad devices.

(In reply to Dudley Du from comment #41)
> Created attachment 123765 [details]
> V2.0 frimware for Cypress CYTRA-101008-00 trackpad device
> 
> The last formally released v2.0 firmware image for all chipped Cypress
> CYTRA-101008-00 trackpad devices.

Thank you Dudley !

(In reply to Peter Hutterer from comment #19)
> fwiw, I just pushed a patch to libinput to at least detect these jumps and
> discard them. This doesn't fix the problem (and indeed it can only be fixed
> in the kernel) but it should at least make the behaviour a bit nicer.
> 
> https://wayland.freedesktop.org/libinput/doc/latest/touchpad_jumping_cursor.
> html

For now I didn't had any "jump" with the "fix" ! Thank you so much Peter !

do you see the error message in the logs though? that should tell us whether the fw above fixed it or whether it's the fix in libinput.

(In reply to Peter Hutterer from comment #44)
> do you see the error message in the logs though? that should tell us whether
> the fw above fixed it or whether it's the fix in libinput.

I'm still on firmware 2.1 so it's the libinput fix that fix it. I will test the 2.0 firmware.

In what logs can I see the error message ?

either in the systemd journal or Xorg.log, depending whether your distro uses the journal for the server.

but it's easier to do by running libinput-debug-events as root and reproducing the jump, it will print to stdout

(In reply to Peter Hutterer from comment #46)
> either in the systemd journal or Xorg.log, depending whether your distro
> uses the journal for the server.
> 
> but it's easier to do by running libinput-debug-events as root and
> reproducing the jump, it will print to stdout

I'm still on firmware 2.1 and with "libinput-debug-events" I have this message that appear (when a jump should occur I guess) :

libinput error: kernel bug: Touch jump detected and discarded.
See https://wayland.freedesktop.org/libinput/doc/1.2.4/touchpad_jumping_cursor for details

So the fix in libinput work perfectly ! Thanks !

(In reply to Dudley Du from comment #41)
> Created attachment 123765 [details]
> V2.0 frimware for Cypress CYTRA-101008-00 trackpad device
> 
> The last formally released v2.0 firmware image for all chipped Cypress
> CYTRA-101008-00 trackpad devices.

Dudley what firmware version do you recommend ?
I would say 2.1 but I prefer to be sure ;)
Thanks.

(In reply to Dudley Du from comment #41)
> Created attachment 123765 [details]
> V2.0 frimware for Cypress CYTRA-101008-00 trackpad device
> 
> The last formally released v2.0 firmware image for all chipped Cypress
> CYTRA-101008-00 trackpad devices.

Dudley can you say me what firmware version do you recommend ?
I would say 2.1 but I prefer to be sure ;)
Thanks.

Created attachment 124386 [details]
attachment-1227-0.html

Hi Paviluf,

I suggest to use the v2.0 firmware, it’s the final firmware that verified by Google Chrome team.

Thanks,
Dudley

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: bugzilla-daemon@freedesktop.org<mailto:bugzilla-daemon@freedesktop.org>
Sent: 2016年6月7日 2:50
To: dudlx@hotmail.com<mailto:dudlx@hotmail.com>
Subject: [Bug 94910] The cursor "jump" sometimes


Comment # 49<https://bugs.freedesktop.org/show_bug.cgi?id=94910#c49> on bug 94910<https://bugs.freedesktop.org/show_bug.cgi?id=94910> from Paviluf<mailto:jeremy9856@gmail.com>

(In reply to Dudley Du from comment #41<show_bug.cgi?id=94910#c41>)
> Created attachment 123765 [details]<attachment.cgi?id=123765> [details]<attachment.cgi?id=123765&action=edit>
> V2.0 frimware for Cypress CYTRA-101008-00 trackpad device
>
> The last formally released v2.0 firmware image for all chipped Cypress
> CYTRA-101008-00 trackpad devices.

Dudley can you say me what firmware version do you recommend ?
I would say 2.1 but I prefer to be sure ;)
Thanks.

________________________________
You are receiving this mail because:

  *   You are on the CC list for the bug.

(In reply to Dudley Du from comment #50) 
> Hi Paviluf,
> 
> I suggest to use the v2.0 firmware, it’s the final firmware that verified by
> Google Chrome team.
> 
> Thanks,
> Dudley

OK Thank you !

(In reply to Peter Hutterer from comment #44)
> do you see the error message in the logs though? that should tell us whether
> the fw above fixed it or whether it's the fix in libinput.

I just switched to the v2.0 firmware and if I run "libinput-debug-events" I still have this message that appear (when a jump should occur I guess) :

libinput error: kernel bug: Touch jump detected and discarded.
See https://wayland.freedesktop.org/libinput/doc/1.2.4/touchpad_jumping_cursor for details

So again the fix in libinput work perfectly ! Thanks !

(In reply to Dudley Du from comment #50)
> I suggest to use the v2.0 firmware, it’s the final firmware that verified by
> Google Chrome team.

For the record the v2.0 firmware seem to work much better than the v2.1. With v2.1 I have a problem of imprecise click ( https://bugs.freedesktop.org/show_bug.cgi?id=96259 ) that is almost not present in v2.0.

I think we can close this bug now? v2.0 works fine from the above comment, the libinput fix to discard the cursor jump takes care of the jump itself. Beyond that there isn't much we can do, I think.

A proper fix should be in the Kernel driver or in the firmware but since that won't happen and your libinput fix work perfectly, I think we can close this bug.

Thank you so much Peter !