Bug 1313939 - Random but consistent failure of touchpad/trackpoint after some usage
Random but consistent failure of touchpad/trackpoint after some usage
Status: NEW
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
25
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-02 11:19 EST by Jonas Thiem
Modified: 2017-05-30 19:54 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
full dmesg output. Please note the actual event seems to coincide with "Failed to enable mouse on ..." at the bottom (122.84 KB, text/plain)
2016-03-02 11:19 EST, Jonas Thiem
no flags Details
dmesg output starting when the trackpoint/touchpad stop working, and ending when they start working again (4.29 KB, text/plain)
2016-03-27 13:08 EDT, Steven D.
no flags Details
dmesg output with psmouse.synaptics_intertouch=1 set (69.01 KB, text/plain)
2016-07-18 12:11 EDT, Steven D.
no flags Details
ps2emu-record log with touchpad enabled (528.59 KB, text/plain)
2016-07-19 21:28 EDT, Steven D.
no flags Details
ps2emu-record log with touchpad disabled (255.10 KB, text/plain)
2016-07-19 21:29 EDT, Steven D.
no flags Details
0047-Input-elantech-fix-missed-byte-when-receiving-some-d.patch (1.75 KB, patch)
2016-07-20 12:06 EDT, Benjamin Tissoires
no flags Details | Diff
acpidump as root (536.99 KB, text/plain)
2016-08-18 10:07 EDT, Steven D.
no flags Details
0001-Input-elantech_i2c-add-trackstick-report-and-match-f.patch (4.81 KB, patch)
2016-08-18 11:50 EDT, Benjamin Tissoires
no flags Details | Diff
Output of ls -l /sys/bus/acpi/devices/ (15.01 KB, text/plain)
2016-08-29 11:08 EDT, Steven D.
no flags Details
dmesg output with new i2c driver (70.88 KB, text/plain)
2016-08-29 11:40 EDT, Steven D.
no flags Details
i2c-detect output (476 bytes, text/plain)
2016-09-20 11:38 EDT, Steven D.
no flags Details
status_output (2 bytes, text/plain)
2016-09-20 11:38 EDT, Steven D.
no flags Details
tree_output (548 bytes, text/plain)
2016-09-20 11:39 EDT, Steven D.
no flags Details
dmesg after trying to enable elan_i2c on rawhide kernel (70.80 KB, text/plain)
2017-01-03 16:13 EST, Steven D.
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 115421 None None None 2016-03-28 15:48 EDT

  None (edit)
Description Jonas Thiem 2016-03-02 11:19:24 EST
Created attachment 1132390 [details]
full dmesg output. Please note the actual event seems to coincide with "Failed to enable mouse on ..." at the bottom

Description of problem:
The trackpoint and touchpad randomly stop working after 30 minutes or longer of working fine. This happens quite reliably at some point, although the duration until it happens is random. A reboot always fixes it, but it's still annoying to be required to reboot every 30 minutes to 5 hours.

When it happens, it seems to coincide with the following line in dmesg: "[ 3265.497495] psmouse serio1: Failed to enable mouse on isa0060/serio1"

Full dmesg output is attached, where you will be able to see that psmouse is already quite unhappy for a while before (but the touchpad/trackpoint work fine during that period), until eventually it seems to break entirely.

Version-Release number of selected component (if applicable):
Linux localhost.localdomain 4.4.2-301.fc23.x86_64 #1 SMP Tue Feb 23 19:00:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:
99% (waiting period differs but it takes less than 5 hours of usage to reproduce with a very high probability)

Steps to Reproduce:
1. Use laptop's touchpad, trackpoint and occassionally the pen and touchscreen
2. Do this for a while (e.g. browsing documents is a good use case)
3. Eventually, touchpad/trackpoint suddenly stop working

Actual results:
Touchpad/trackpoint stop working. A reboot fixes it temporarily

Expected results:
Touchpad/trackpoint keep working

Additional info:
Comment 1 Jonas Thiem 2016-03-02 11:20:58 EST
The hardware showing this issue is a "Lenovo Thinkpad Yoga 260" with Fedora 23 running with latest fedora 23 packages, and the kernel grub boot options contain "nolapic" to work around the black screen boot bug.
Comment 2 Steven D. 2016-03-27 13:07:57 EDT
I am having a similar problem with my Thinkpad Yoga 12 on Fedora 23.
uname -r outputs: 4.4.6-300.fc23.x86_64

Description:
After using my computer normally for a while, my trackpoint and touchpad stop responding. So I am not able to move my mouse with them. My touch screen and digitizer pen still work. Sometimes, after waiting about 10mins, they start to work again. Other times, they stop functioning entirely and no longer show up in xinput. While the trackpoint and touchpad are not working, my keyboard also periodically lags, and the same keystroke is repeated many times. Keyboard freezes coincide with the following kernel messages:

[ 1859.197026] psmouse serio1: synaptics: queried min coordinates: x [1232..], y [1074..]

I have attached a snippet of my dmesg output starting at the point when my trackpoint and touchpad stop working, and ending when they start working again. I have also attached the output of lsmod.

How reproducible:
Happens every time I have used my computer for more than 30mins in the past four days.

How to reproduce / actual results / expected results are the same as Jonas.

Additional Info:
I have tried live booting other distributions and other kernel versions. This includes Ubuntu 15.10, Ubuntu 15.04, and the latest version of Elementary OS. I get the same problem and same kernel messages in all of these environments. This leads me to think it's a kernel issue? I have also tried reloading psmouse with the proto=bare option. This does not help.
Comment 3 Steven D. 2016-03-27 13:08 EDT
Created attachment 1140710 [details]
dmesg output starting when the trackpoint/touchpad stop working, and ending when they start working again
Comment 4 Steven D. 2016-03-27 13:10:58 EDT
A relevant AskUbuntu post with the same issue, posted a few days ago: http://askubuntu.com/questions/749280/trackpad-and-keyboard-erratic-behaviour-on-thinkpad-yoga-15-10/749890#749890
Comment 5 jonathan.bohren 2016-05-13 17:04:19 EDT
I'm also experiencing this problem on a Yoga 260, running Xubuntu 16.0 and kernel `4.4.0-22-generic`. My `dmesg` output resembles Jonas's and not the askubuntu post above.

I've found that the issue can be reproduced reliably by clicking one of the physical buttons while moving the trackpoint and "grazing" the top edge of the touchpad. The cursor will jump, and eventually stop responding. Then if you perform the maneuver several more times, you can get the cursor to start tracking again.
Comment 6 jonathan.bohren 2016-05-14 12:53:55 EDT
An even easier way to reproduce the problem:

First, place one finger on touchpad (without clicking), then use the trackpoint normally (i.e. dragging and clicking with the physical buttons. The cursor will jump about 300px in different directions, and then get "stuck."

Note that this still happens even when the touchpad is disabled via xinput or synclient.
Comment 7 Steven D. 2016-05-15 23:43:47 EDT
Two notes:

1. This turned out to be a hardware issue for me. Lenovo had to repair my machine.

2. Jonathan: I had the same issue when I used Ubuntu. I think xinput treats the mouse movement and mouse clicking functionalities of the touchpad differently somehow. Disabling mouse movement did not fully disable mouse clicking for me either... though I don't have a resolution for this. The bug no longer occurs in Fedora though.
Comment 8 jonathan.bohren 2016-05-16 12:15:13 EDT
> The bug no longer occurs in Fedora though.

You mean on Fedora 23 or on Rawhide?
Comment 9 Jonas Thiem 2016-05-16 12:27:19 EDT
I'm on Fedora 23 with latest updates and it's definitely not fixed here
Comment 10 jonathan.bohren 2016-05-17 13:08:31 EDT
So I think when you click(button) and drag(trackpoint) while touching the touchpad, the device sends a packet of type `0x03` which is not getting handled here:
https://github.com/torvalds/linux/blob/9256d5a308c95a50c6e85d682492ae1f86a70f9b/drivers/input/mouse/elantech.c#L813-L822

This is what it looks like when this happens:
https://www.youtube.com/watch?v=QH-tYESsgSI

So this is looks like a driver issue in psmouse.
Comment 11 jonathan.bohren 2016-05-17 13:32:58 EDT
I found the other thread on the kernel bugzilla that Jonas opened, and this probably belongs there: https://bugzilla.kernel.org/show_bug.cgi?id=115421#c5
Comment 12 Steven D. 2016-05-25 09:44:47 EDT
(In reply to jonathan.bohren from comment #8)
> > The bug no longer occurs in Fedora though.
> 
> You mean on Fedora 23 or on Rawhide?

I was referring to Fedora 23. Though I actually did find an issue. Fedora automatically disables the touchpad when using the trackpoint (which is the correct behaviour). But when resting my palm on the touchpad while using the trackpoint, my left clicks are recognized as "click and drags". i.e. The mouse release event is ignored when my palm is resting on the touchpad.

My cursor does not, however, jump around.

What tool can I use to log these events?
Comment 13 Jonas Thiem 2016-07-03 21:07:42 EDT
This is still broken in Fedora 24. Bumping version.
Comment 14 Adam Williamson 2016-07-04 03:21:58 EDT
whot: any ideas, by any chance?
Comment 15 Peter Hutterer 2016-07-04 03:42:55 EDT
Steven: your issue is unrelated and most likely in libinput. Please file a separate bug and assign it to me, thanks.
Comment 16 Benjamin Tissoires 2016-07-04 04:53:44 EDT
The t450s has a similar touchpad, though a different board id:
 psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xf004a3/0x943300/0x12e800/0x10000, board id: 3053, fw id: 2560
(while yours is 
 psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xf002a3/0x943300/0x12e800/0x10000, board id: 3075, fw id: 2560)

I can't reproduce the bug locally, but given the errors, I would say it's a firmware issue. Given that the 2 boards are similar, I think Windows is not using plain PS/2, but RMI4 over SMBus. So it would be interesting to see if RMI4 over SMBus works for you and fixes the bug.

Could you give a shot at http://koji.fedoraproject.org/koji/taskinfo?taskID=14759166 (still building)?

To enable RMI4 over SMBus, you'll need to append "psmouse.synaptics_intertouch=1" to the kernel boot.

Once enabled, xinput should show a touchpad similar to "Synaptics TM3053-004".

Note: I am still trying to push these patches upstream. But if this fixes your problems, that will be one more argument to push them.
Comment 17 Steven D. 2016-07-05 18:43:23 EDT
Apologies for the confusion. It turns out I was dealing with two bugs/problems at once and I muddled them. I will clarify here:

Peter: I will file a bug report for libinput this week. Thank you!

Jonas: I experienced the exact same bug as you on my Yoga 12. I flashed a windows image and it persisted. I had the computer replaced. And on my new Yoga 12 I have the same issue on windows and Linux. Which is why I suspect hardware? 

Jonathan: I do not seem to have the same issue as you. I'm not sure if it is the same problem as Jonas'? Was Jonas able to reproduce his problem the same was as you?

Benjamin: Even though I had the same issue on windows, I will try your fix and report back when I get the chance.
Comment 18 Steven D. 2016-07-16 21:38:26 EDT
Got my hands on a ThinkPad Yoga 260. I can confirm both Jonathan and Jonas' issues.

Benjamin: I'm not sure how to apply your fix - I'm sort of new to this. If you give me slightly more specific instructions I can try it
Comment 19 Peter Hutterer 2016-07-17 20:03:54 EDT
Steven: download and install the packages from the scratch build, reboot. during boot, hit the left key [1] until grub shows you the list of kernels. select the one you installed (likely already selected), hit 'e' to see the full commandline. Go down to where the various kernel options are, and append the psmouse options Benjamin suggested. I don't remember the exact keys off-heart but arrow keys and typing will get you there ;) And there's a legend at the bottom anyway. Then boot once the option added and you're good to go

[1] least likely to accidentally select something
Comment 20 Steven D. 2016-07-17 21:49:58 EDT
Peter: I'm able to get as far as installing most of the RPMs, but I'm running in to some dependency errors:

```
error: Failed dependencies:
        kernel-headers < 4.7.0-0.rc5.git3.1.rmi4.wacom.fc25 is obsoleted by kernel-headers-4.7.0-0.rc5.git3.1.rmi4.wacom.fc25.x86_64
        libpci.so.3(LIBPCI_3.5)(64bit) is needed by kernel-tools-4.7.0-0.rc5.git3.1.rmi4.wacom.fc25.x86_64
        libperl.so.5.24()(64bit) is needed by perf-4.7.0-0.rc5.git3.1.rmi4.wacom.fc25.x86_64
Updating / installing...
   1:kernel-4.7.0-0.rc5.git3.1.rmi4.wa################################# [100%]

```

I don't know what the first error means, though I tried googling it.

I seem to have the necessary libpci lib in my /lib64. I tried symlinking it to my /lib but that didnt work.

I cant find the version of libperl I need, even though I installed perl 5.24 from source.

I can keep trying, but might it be possible that you (or someone else) point me in the right direction? Once I get this done I should be able to boot with the required kernel options - I've done that before. Thanks
Comment 21 Benjamin Tissoires 2016-07-18 04:41:04 EDT
(In reply to Steven D. from comment #20)
> Peter: I'm able to get as far as installing most of the RPMs, but I'm
> running in to some dependency errors:
> 
> ```
> error: Failed dependencies:
>         kernel-headers < 4.7.0-0.rc5.git3.1.rmi4.wacom.fc25 is obsoleted by
> kernel-headers-4.7.0-0.rc5.git3.1.rmi4.wacom.fc25.x86_64
>         libpci.so.3(LIBPCI_3.5)(64bit) is needed by
> kernel-tools-4.7.0-0.rc5.git3.1.rmi4.wacom.fc25.x86_64
>         libperl.so.5.24()(64bit) is needed by
> perf-4.7.0-0.rc5.git3.1.rmi4.wacom.fc25.x86_64
> Updating / installing...
>    1:kernel-4.7.0-0.rc5.git3.1.rmi4.wa#################################
> [100%]
> 
> ```

Try upgrading only your current package, not install everything. Those packages are build against f25, and though it's safe to use kernel, kernel-core, kernel-modules, kernel-extra (from the top of my head), other kernel tools packages (perf, etc...) might have dependencies you don't want to pull.

> 
> I don't know what the first error means, though I tried googling it.
> 
> I seem to have the necessary libpci lib in my /lib64. I tried symlinking it
> to my /lib but that didnt work.

Please don't. That's a system issue, (using f25 pakcages on f23), and playing with your lib files might just break things.

> 
> I cant find the version of libperl I need, even though I installed perl 5.24
> from source.

You don't need to install perf, so you don't need perl 5.24.

> 
> I can keep trying, but might it be possible that you (or someone else) point
> me in the right direction? Once I get this done I should be able to boot
> with the required kernel options - I've done that before. Thanks

What I usually do is: download all files in a separate folder, in that folder:
sudo dnf upgrade *

If kernel-headers (or -devel) is installed on your system and refuses to upgrade, try removing it first, and make sure to only install the bare minimum (kernel, -core, -modules, -modules-extra)
Comment 22 Steven D. 2016-07-18 10:10:30 EDT
Thanks Benjamin and Peter. I did `sudo dnf upgrade *` and was able to install the new kernel. I booted with `psmouse.synaptics_intertouch=1` and `nolapic`, and I can still reproduce Jonas' and Jonathan's issues. So I guess your build doesn't fix this problem :(

Just for reference, some issues I ran in to and solved:

- I got `double free at 0xb8488700` when I tried and boot from the new kernel, but disabling secureboot fixed that.

- I was able to consistently boot into the new kernel without appending `psmouse.synaptics_intertouch=1` to the kernel options. However, in order to boot with `psmouse.synaptics_intertouch=1`, I had to also add `nolapic` to deal with the skyalake pstate bug. Took a while to boot.

Any ideas where to go from here?
Comment 23 Steven D. 2016-07-18 10:12:44 EDT
Oh I just realized. My xinput does not show anything similar to `Synaptics TM3053-004`. It shows `ETPS/2 Elantech Touchpad`. So maybe I didn't install Benjamin's patch properly... I'll look in to it tonight
Comment 24 Benjamin Tissoires 2016-07-18 11:41:30 EDT
(In reply to Steven D. from comment #23)
> Oh I just realized. My xinput does not show anything similar to `Synaptics
> TM3053-004`. It shows `ETPS/2 Elantech Touchpad`. So maybe I didn't install
> Benjamin's patch properly... I'll look in to it tonight

Sigh. I hope 4.7-rc* doesn't break the detection (again) of your touchpad...
Could you append the dmesg while `psmouse.synaptics_intertouch=1` is set?
Comment 25 Steven D. 2016-07-18 12:11 EDT
Created attachment 1181174 [details]
dmesg output with psmouse.synaptics_intertouch=1 set

As requested by Benjamin. psmouse.synaptics_intertouch=1 and nolapic

I can't consistently boot in to 4.7, with or without `nolapic`. Additionally, `nolapic` breaks my wifi and increases the boot time significantly... odd...
Comment 26 Steven D. 2016-07-18 12:48:32 EDT
Clarification:

With no additional parameters, 4.7 sometimes boots.

With nolapic alone, 4.7 sometimes boots, but takes longer and breaks the wifi

With psmouse.synaptics_intertouch=1 alone, 4.7 does not boot

With both, 4.7 does boot, takes longer, and breaks wifi
Comment 27 Jonas Thiem 2016-07-18 14:47:38 EDT
Wild guess since that also affected me (I'm not a kernel developer):
Maybe 4.7 doesn't boot because of this bug? https://bugzilla.redhat.com/show_bug.cgi?id=1353103 You can try specifying the kernel option dis_ucode_ldr as a workaround to see if that's the cause
Comment 28 Steven D. 2016-07-18 15:39:29 EDT
Good call Jonas, `dis_ucode_ldr` allows me to boot smoothly on 4.7. Though the same issue with the Trackpoint/Touchpad persists.
Comment 29 Benjamin Tissoires 2016-07-19 10:27:39 EDT
OK, I think I am starting to understand a little bit more here:
- Steven, your first dmesg was not on a Yoga 260, but on a Yoga 12.
- Looks like the Yoga 12 is using a Synaptics touchpad, while the Yoga 260 is using an Elantech one
- If I understand correctly the issue on the Yoga 12 was solved by a hardware replacement
- The Yoga 260 issue (with Elantech touchpad) is still not resolved.

If that's accurate, that means that the kernel build I sent has no chances of fixing this bug given that it targets only Synaptics touchpads, not Elantech.

This build I posted contained a quite up to date driver (we are at 4.7-rc7), so this means that the bug has not been fixed in recent kernels either.

So, on the Yoga 260 (Elantech), could you record a trace using ps2emu-record[1] while exposing the bug? This way I might be able to reproduce locally and understand where the pitfall is.
(please use the 4.7-rc5 kernel with any kernel paramter that allows to boot from it)

[1] https://github.com/Lyude/ps2emu
Comment 30 Steven D. 2016-07-19 21:27:41 EDT
Yes you're correct. My Yoga 12 seems to have had hardware issues, but the dmesg logs happened to look a lot like Jonas', hence the confusion. Hardware issues kept appearing with my Yoga 12 until Lenovo upgraded it to a Yoga 260, which is what I have now.

I've attached the ps2emu-record logs for the cursor-jumping scenario Jonathan described. Both with and without my touchpad disabled using the Fedora settings. However in both cases my palm was on the touchpad (like in Comment 10). I did not push it to the point of failing completely like in the original post, but I will do that if you find it helpful. The log will just be quite long.
Comment 31 Steven D. 2016-07-19 21:28 EDT
Created attachment 1181884 [details]
ps2emu-record log with touchpad enabled
Comment 32 Steven D. 2016-07-19 21:29 EDT
Created attachment 1181885 [details]
ps2emu-record log with touchpad disabled
Comment 33 Benjamin Tissoires 2016-07-20 12:06 EDT
Created attachment 1182169 [details]
0047-Input-elantech-fix-missed-byte-when-receiving-some-d.patch

Thanks for the logs. I could reproduce a bunch of "lost sync at byte 6" and it appears most of them come from a missing byte in the sequence "0x80, 0x80, 0x36, 0x00, 0x00"

So I tried inserting this missing byte in the attached patch. I just started http://koji.fedoraproject.org/koji/taskinfo?taskID=14959240 which contains the patch, so please give it a try when it will be done.

This might not be the final solution, but if this fixes most issues, then we will have a better understanding of what is going on.
Comment 34 Benjamin Tissoires 2016-07-20 12:08:04 EDT
Comment on attachment 1140710 [details]
dmesg output starting when the trackpoint/touchpad stop working, and ending when they start working again

Unrelated hardware, so obsoleting the logs to not introduce confusion.
Comment 35 Benjamin Tissoires 2016-07-20 12:26:40 EDT
Looks like I shot too fast, and I was missing a few bits in the configuration of the kernel I tried to build.

http://koji.fedoraproject.org/koji/taskinfo?taskID=14959333 should be in a better shape. Please test and report :)

Note: each time the patch fixes the wrong incoming data, it will output a "elantech: fixed bad incoming data" in the dmesg. This shouldn't stay in a final version.
Comment 36 Steven D. 2016-07-20 20:33:12 EDT
Thanks Benjamin. Unfortunately, this doesn't stop the cursor from jumping everywhere like before. I do get some "elantech: fixed bad incoming data" messages, but maybe 1 for every 5-10 "psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6" message. I can send more logs if needed.
Comment 37 Steven D. 2016-07-20 20:41:50 EDT
Just realized this: I get almost entirely "elantech: fixed bad incoming data" messages when I have three fingers stationary on the touchpad while clicking/clicking-and-dragging the mouse. However other interactions with the touchpad (e.g. palm resting on part of it while clicking and dragging) don't produce that message as often. My mouse did still jump in the three-finger case, but it seems less frequent (though I can't confidently comment on the frequency).

So maybe you've fixed one case here?
Comment 38 Benjamin Tissoires 2016-07-21 06:02:29 EDT
I just tried to reach out to Elan to see whether they are aware of it or if they do not see this under Windows. We might have more information in the next couple of days (weeks?).
Comment 39 Steven D. 2016-07-21 10:14:08 EDT
Alright thanks! Just FYI, I am dual-booting and do not experience the issue on Windows 10.
Comment 40 Benjamin Tissoires 2016-08-08 12:20:52 EDT
Quick update after having some information from Elan. It seems that this is a firmware issue: depending on how the trackstick/buttons/touchpad are used, the trackstick might lose 1-3 bytes at the end of its report :/

If Windows 10 is not impacted, that would suggest that the Windows driver is not using the PS/2 bus but an other. I'll try to get some more information on this from Elan. However, it could be interesting to check which bus is used under Windows 10.
Comment 41 Steven D. 2016-08-08 12:24:51 EDT
Thanks for the update! Do you know how I could figure out which bus is used on Windows?
Comment 42 Benjamin Tissoires 2016-08-08 12:40:38 EDT
(In reply to Steven D. from comment #41)
> Do you know how I could figure out which bus is used on Windows?

I think you should go to the Device Manager, and look for the mouse attached to the touchpad. You should see a PS/2 one, and maybe a different one. The thing is Synaptics attaches the SMBus connection behind the PS/2 node, so with this vendor, you can't see which bus you are using. Elan might do something different.
Comment 43 Steven D. 2016-08-08 20:52:56 EDT
I see a "ELAN SMBus Driver 15.6.0.3" under system devices! Going to `Driver Details` shows that one of the driver files is `TouchpadEnableDisable.exe`, so I think this is what you were looking for?
Comment 44 Benjamin Tissoires 2016-08-09 04:01:40 EDT
(In reply to Steven D. from comment #43)
> I see a "ELAN SMBus Driver 15.6.0.3" under system devices! Going to `Driver
> Details` shows that one of the driver files is `TouchpadEnableDisable.exe`,
> so I think this is what you were looking for?

Yep, and meanwhile, Elan replied and confirmed that they are using SMBus under Windows. They should allocate some resources to Linux on this topic soon (no ETA unfortunately). There is already an elantech-smbus driver in the kernel so I hope it won't take too long.

Meanwhile, could you attach the output of acpidump (as root)? I'll try to look for the SMBus touchpad in the DSDT though the few logs I found elsewhere are not very promising :(
Comment 45 Benjamin Tissoires 2016-08-18 05:58:29 EDT
I'd really need to have a look at the DSDT. I have some more information from ELAN to start working on this, but without the DSDT I won't be able to produce anything.
Comment 46 Steven D. 2016-08-18 10:07 EDT
Created attachment 1191881 [details]
acpidump as root

Sorry for the delay. Attached as requested. Thanks Benjamin!
Comment 47 Benjamin Tissoires 2016-08-18 11:50 EDT
Created attachment 1191926 [details]
0001-Input-elantech_i2c-add-trackstick-report-and-match-f.patch

Thanks for the logs. Kind of a long shot, but attached is a patch that might help you.

Please grab http://koji.fedoraproject.org/koji/taskinfo?taskID=15296246 when it's done (in a couple of hours from now) and report:
- is module elan_i2c automatically loaded?
- does the touchpad still works?
- does the trackstick still works?
- does it solves the bug? :)

I am not entirely sure whether elan_i2c will take over the PS/2 driver. If not, please give us the output of "ls -l /sys/bus/acpi/devices/".

Also, if things go well and the bug gets fixed by this, I'll need a little bit more of iterations to polish the patch before sending it upstream.

Last, note I kept some debug information in the dmesg, so if this works, I'll update the patch to remove them too.
Comment 48 Steven D. 2016-08-28 20:24:47 EDT
Hey Benjamin,

I wasn't able to boot to your patched kernel. I get `double free at 0xb931b349`. Note that I'm booting this off a flash drive that has a full install of Fedora on it. Could this be related to the problem?

I'd be happy to install the patch on my main Fedora install if I can sandbox it / cleanly uninstall it. Do you know of a way?
Comment 49 Josh Boyer 2016-08-29 07:15:50 EDT
(In reply to Steven D. from comment #48)
> Hey Benjamin,
> 
> I wasn't able to boot to your patched kernel. I get `double free at
> 0xb931b349`. Note that I'm booting this off a flash drive that has a full
> install of Fedora on it. Could this be related to the problem?

That is a problem in grub with unsigned kernels (all scratch builds are unsigned).  That has nothing to do with this problem.

> I'd be happy to install the patch on my main Fedora install if I can sandbox
> it / cleanly uninstall it. Do you know of a way?

If you have secure boot enabled, you'll need to turn it off.  Then you should be able to install it normally.
Comment 50 Steven D. 2016-08-29 11:07:27 EDT
Oops thanks I was able to boot.

What I've seen:
- elan_i2c is loaded by default
- The touchpad and trackpoint function the same way as before the patch
- The bug was not fixed. In fact, the touchpad and trackpoint failed completely a few minutes into using the patched kernel
- I don't see any of your "fixed bad incoming data" messages in dmesg

I've attached the output of `ls -l /sys/bus/acpi/devices/`

Thanks for your time and help
Comment 51 Steven D. 2016-08-29 11:08 EDT
Created attachment 1195411 [details]
Output of ls -l /sys/bus/acpi/devices/
Comment 52 Benjamin Tissoires 2016-08-29 11:17:22 EDT
(In reply to Steven D. from comment #50)
> What I've seen:
> - elan_i2c is loaded by default

\o/

> - The touchpad and trackpoint function the same way as before the patch

\o/

> - The bug was not fixed. In fact, the touchpad and trackpoint failed
> completely a few minutes into using the patched kernel

not very surprising given that no one ever tested the driver with your system before :)

Please upload a new dmesg with the new kernel

> - I don't see any of your "fixed bad incoming data" messages in dmesg

That's because this was sent by the PS/2 driver, and now you are using I2C. So different driver, different error messages.

> 
> I've attached the output of `ls -l /sys/bus/acpi/devices/`
> 
> Thanks for your time and help

glad we managed to make some steps.
Comment 53 Steven D. 2016-08-29 11:40 EDT
Created attachment 1195419 [details]
dmesg output with new i2c driver

Corresponds to clicking and dragging the mouse using the trackpoint while resting my palm on the touchpad. Log ends when the trackpoint and touchpad lose sync and stop working entirely.
Comment 54 Benjamin Tissoires 2016-08-29 12:10:34 EDT
thanks for the logs.

Actually, you are not using elan_i2c, but still PS/2... sigh.

I'll need to request some more tests for you later when I get a new build.
Comment 55 Benjamin Tissoires 2016-09-02 05:59:25 EDT
I am trying to understand why the elan_i2c driver doesn't show up in the dmesg at all.

Could you tell me what is the content of the "status" file of ETDFF00:00 (would be "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2c/ETDFF00:00/status")

And also, I'd like to check if the driver is actually bound.
Please give me the output of tree on "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2c/ETDFF00:00" and on "/sys/bus/i2c/devices/*"

And to be sure, please modprobe i2c-dev, install i2c-tools, and run "sudo i2cdetect -l", note which adapter is the SMBus one, and run "sudo i2cdetect X" where X is the number of the SMBus adapter, and share the output :)
Comment 56 Benjamin Tissoires 2016-09-07 09:13:20 EDT
ping?
Comment 57 Steven D. 2016-09-20 11:38 EDT
Created attachment 1202952 [details]
i2c-detect output
Comment 58 Steven D. 2016-09-20 11:38 EDT
Created attachment 1202953 [details]
status_output
Comment 59 Steven D. 2016-09-20 11:39 EDT
Created attachment 1202954 [details]
tree_output
Comment 60 Steven D. 2016-09-20 11:39:49 EDT
There you go! Let me know what else you need!
Comment 61 Benjamin Tissoires 2016-09-21 03:33:13 EDT
Thanks!

So the 'status' output shows that ACPI finds that the device is not there, which explains why the driver is not picking up the device.

On the Thinkpad series 13, there is no ETD* ACPI device, so for the time being, we just used a workaround by manually declaring the device by calling
echo elan_i2c 0x15 > /sys/bus/i2c/devices/i2c-N/new_device
(where i2c-N is the bus number of the SMBus adapter given by i2cdetect -l).

We made good progress on the SMbus driver, and you can give a shot at it by cloning https://github.com/bentiss/elan_i2c

If you are running v4.6 or v4.7, you'll need to also install the i2c-smbus.ko and i2c-801.ko modules, but starting with v4.8-rcX, you just need elan_i2c.ko.

Please note that you might need to rmmod/modprobe the module after resume, it seems like it doesn't survive after a suspend/resume.

We are currently working on instantiating the SMBus device from PS/2, this should come soon and then we will be able to submit the series.
Comment 62 Laura Abbott 2016-09-23 15:22:40 EDT
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.
 
Fedora 24 has now been rebased to 4.7.4-200.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 25, and are still experiencing this issue, please change the version to Fedora 25.
 
If you experience different issues, please open a new bug report for those.
Comment 63 Steven D. 2016-09-25 18:00:39 EDT
(In reply to Benjamin Tissoires from comment #61)
> Thanks!
> 
> So the 'status' output shows that ACPI finds that the device is not there,
> which explains why the driver is not picking up the device.
> 
> On the Thinkpad series 13, there is no ETD* ACPI device, so for the time
> being, we just used a workaround by manually declaring the device by calling
> echo elan_i2c 0x15 > /sys/bus/i2c/devices/i2c-N/new_device
> (where i2c-N is the bus number of the SMBus adapter given by i2cdetect -l).
> 
> We made good progress on the SMbus driver, and you can give a shot at it by
> cloning https://github.com/bentiss/elan_i2c
> 
> If you are running v4.6 or v4.7, you'll need to also install the
> i2c-smbus.ko and i2c-801.ko modules, but starting with v4.8-rcX, you just
> need elan_i2c.ko.
> 
> Please note that you might need to rmmod/modprobe the module after resume,
> it seems like it doesn't survive after a suspend/resume.
> 
> We are currently working on instantiating the SMBus device from PS/2, this
> should come soon and then we will be able to submit the series.

Just to be clear, do I need to `echo elan_i2c 0x15 > /sys/bus/i2c/devices/i2c-N/new_device`, or was that problem resolved in your updates on GitHub?
Comment 64 Benjamin Tissoires 2016-09-26 03:24:39 EDT
(In reply to Steven D. from comment #63)
> Just to be clear, do I need to `echo elan_i2c 0x15 >
> /sys/bus/i2c/devices/i2c-N/new_device`, or was that problem resolved in your
> updates on GitHub?

Please run the command once after boot. The automatic loading is still not pushed on the github tree.
Comment 65 Steven D. 2016-10-30 13:30:53 EDT
(In reply to Laura Abbott from comment #62)
> *********** MASS BUG UPDATE **************
>  
> We apologize for the inconvenience.  There is a large number of bugs to go
> through and several of them have gone stale.  Due to this, we are doing a
> mass bug update across all of the Fedora 24 kernel bugs.
>  
> Fedora 24 has now been rebased to 4.7.4-200.fc24.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
>  
> If you have moved on to Fedora 25, and are still experiencing this issue,
> please change the version to Fedora 25.
>  
> If you experience different issues, please open a new bug report for those.

Bug is still present on the new kernel
Comment 66 Steven D. 2016-10-30 13:44:50 EDT
Sorry for the delay. I am not able to compile the elan_i2c repo:

[steven@thinkpad-yoga-test elan_i2c]$ make
make -C /lib/modules/4.6.7-300.elantech.1313939.1.fc24.x86_64/build SUBDIRS=/home/steven/elan_i2c modules
make[1]: *** /lib/modules/4.6.7-300.elantech.1313939.1.fc24.x86_64/build: No such file or directory.  Stop.
Makefile:15: recipe for target 'default' failed
make: *** [default] Error 2

I am still using the custom 4.6.7-300.elantech.1313939.1.fc24.x86_64 kernel from earlier.

What should I do to resolve this?
Comment 67 Benjamin Tissoires 2016-10-31 06:58:04 EDT
(In reply to Steven D. from comment #66)
> What should I do to resolve this?

Please upgrade to the latest kernel, and install kernel-devel and kernel-headers.
Make should work when you switch to the kernel that has the -devel rpm installed.
Comment 68 Steven D. 2016-12-29 15:36:44 EST
So I installed the elan_i2c kernel driver, and it seems to be loaded. But my trackpoint and trackpad don't work anymore :-P What logs or info do you need?
Comment 69 Benjamin Tissoires 2017-01-03 04:20:00 EST
I have the feeling using the out of the tree might not work properly with recent kernels.

Could you try enabling the rawhide nodebug kernel[1], and see if the touchpad works after the `echo elan_i2c 0x15 > /sys/bus/i2c/devices/i2c-N/new_device` step? (not installing anything else than just the plain rawhide kernel).

Please provide the dmesg messages in any cases.

[1] https://fedoraproject.org/wiki/RawhideKernelNodebug
Comment 70 Steven D. 2017-01-03 16:11:16 EST
Done. When I run that command, the trackpoint stops working, but the touchpad continues to work, unlike before when both failed.
Comment 71 Steven D. 2017-01-03 16:13 EST
Created attachment 1237000 [details]
dmesg after trying to enable elan_i2c on rawhide kernel

elan_i2c 6-0015: invalid report id data (5e) corresponds to me trying to move the trackpoint.
Comment 72 Benjamin Tissoires 2017-01-03 16:16:42 EST
(In reply to Steven D. from comment #70)
> Done. When I run that command, the trackpoint stops working, but the
> touchpad continues to work, unlike before when both failed.

OK, so that means elan_i2c is working properly. The trackstick code is not upstream (yet), and this adds something on my todo list then.

I'll try updating the out-of-the-tree driver and re-ask you to do some more tests.
Comment 73 Benjamin Tissoires 2017-01-10 11:30:09 EST
I just submitted a series with all the required fixes[1] (crossing fingers). By default the touchpad won't get unbound from PS/2, but this can be enabled by appending psmouse.elan_smbus=1 to the kernel command line.

[1] https://lkml.org/lkml/2017/1/10/743
Comment 74 Steven D. 2017-01-13 18:03:10 EST
What would you like me to test? I'm not really sure how to install your changes. By kernel command line you mean the boot parameters right? The ones I can edit through GRUB?
Comment 75 Jonas Thiem 2017-01-20 16:30:54 EST
With kernel 4.9.3-200.fc25.x86_64 it seems to be better (mouse can still be moved with trackpoint while a finger touches the touchpad), but it still desyncs after a while:

(dmesg output:)

[88576.271902] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
[88576.278892] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
[88576.285980] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
[88576.293086] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
[88576.302506] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
[88576.302509] psmouse serio1: issuing reconnect request
[88576.699639] psmouse serio1: Failed to enable mouse on isa0060/serio1
[88600.769135] psmouse serio1: elantech: PS/2 packet [12 31 c1 c6 10 00]
[88600.885176] psmouse serio1: elantech: PS/2 packet [80 26 fe 06 34 00]
[88601.111165] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.131141] psmouse serio1: elantech: PS/2 packet [80 26 fe 06 10 00]
[88601.151163] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.181085] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.220955] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.230927] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.260862] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.280875] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.290807] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.300793] psmouse serio1: elantech: PS/2 packet [80 26 fd 06 10 00]
[88601.350721] psmouse serio1: elantech: PS/2 packet [80 26 fc 06 10 00]
[88601.380603] psmouse serio1: elantech: PS/2 packet [80 26 fc 06 10 00]
[88601.420521] psmouse serio1: elantech: PS/2 packet [80 26 fc 06 10 00]
[88601.430510] psmouse serio1: elantech: PS/2 packet [80 26 fc 06 10 00]
[88601.829733] psmouse serio1: elantech: PS/2 packet [80 36 04 06 00 80]
[88603.416165] psmouse serio1: elantech: PS/2 packet [80 36 0d 06 00 80]
[88603.655656] psmouse serio1: elantech: PS/2 packet [00 16 08 f6 20 80]
[88603.665656] psmouse serio1: elantech: PS/2 packet [00 16 08 f6 20 80]
[88604.024871] psmouse serio1: elantech: PS/2 packet [80 26 fa 06 10 00]
[88604.034830] psmouse serio1: elantech: PS/2 packet [80 26 fb 06 10 00]
[88604.054950] psmouse serio1: elantech: PS/2 packet [80 26 fb 06 10 00]
[88604.224470] psmouse serio1: elantech: PS/2 packet [80 26 f4 06 10 00]
[88604.234390] psmouse serio1: elantech: PS/2 packet [80 26 f6 06 10 00]
[88604.570304] psmouse serio1: elantech: PS/2 packet [13 31 50 e6 44 10]
[88604.584747] psmouse serio1: elantech: PS/2 packet [3f 31 70 f6 44 10]
[88604.783239] psmouse serio1: elantech: PS/2 packet [9d 51 55 46 64 25]
[88604.863110] psmouse serio1: elantech: PS/2 packet [e2 51 34 56 74 35]
[88604.873029] psmouse serio1: elantech: PS/2 packet [e8 51 44 46 64 35]
[88604.962905] psmouse serio1: elantech: PS/2 packet [c1 51 74 06 74 35]
[88604.972865] psmouse serio1: elantech: PS/2 packet [a5 51 84 16 74 35]
[88608.564989] psmouse serio1: elantech: PS/2 packet [80 26 fa 06 10 00]
[88608.584981] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88608.644772] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88608.684683] psmouse serio1: elantech: PS/2 packet [80 26 fa 06 10 00]
[88608.704705] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88608.724669] psmouse serio1: elantech: PS/2 packet [80 26 fb 06 10 00]
[88608.744652] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88608.754563] psmouse serio1: elantech: PS/2 packet [80 26 fa 06 10 00]
[88608.764530] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88608.774589] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88609.073907] psmouse serio1: elantech: PS/2 packet [00 16 05 f6 20 80]
[88609.093913] psmouse serio1: elantech: PS/2 packet [00 16 06 f6 20 80]
[88609.123858] psmouse serio1: elantech: PS/2 packet [00 16 06 f6 20 80]
[88609.143804] psmouse serio1: elantech: PS/2 packet [00 16 06 f6 20 80]
[88609.443215] psmouse serio1: elantech: PS/2 packet [80 26 f8 06 10 00]
[88609.463091] psmouse serio1: elantech: PS/2 packet [80 26 fa 06 10 00]
[88609.692556] psmouse serio1: elantech: PS/2 packet [80 26 f9 06 10 00]
[88609.702546] psmouse serio1: elantech: PS/2 packet [80 26 fb 06 10 00]
[88609.712609] psmouse serio1: elantech: PS/2 packet [80 26 fa 06 10 00]
[88618.681635] psmouse serio1: elantech: PS/2 packet [f4 52 19 f6 24 39]
[88618.726290] psmouse serio1: elantech: PS/2 packet [db 52 40 d6 54 07]
[88618.755639] psmouse serio1: elantech: PS/2 packet [e5 72 12 f6 34 17]
[88618.771735] psmouse serio1: elantech: PS/2 packet [ed 32 09 f6 44 63]
[88618.841445] psmouse serio1: elantech: PS/2 packet [eb 72 0c f6 24 68]
[88619.001039] psmouse serio1: elantech: PS/2 packet [7d 52 c3 46 64 82]
Comment 76 Steven D. 2017-02-09 22:48:58 EST
I still have the same issues on rawhide 4.10 though
Comment 77 Benjamin Tissoires 2017-02-27 03:54:44 EST
(In reply to Steven D. from comment #76)
> I still have the same issues on rawhide 4.10 though

Sorry, things take time to get merged. I have updated the series for synaptics and dropped the Elan change in the hope this would make 4.11, but neither did. I am still waiting for reviews on one serio change that would allow to properly bind elan_i2c in place of psmouse. So don't lose hope, it will eventually get merged in one form or one other. Once Synaptics gets merged, adding elan will be a piece of cake :)
Comment 78 Justin M. Forbes 2017-04-11 11:03:02 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-100.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.
Comment 79 Feng Yu 2017-04-14 01:54:10 EDT
I can confirm the bug still exists with kernel-4.10.8-200.fc25.x86_64.

I am updating the version of the bug to 25.
Comment 80 Benjamin Tissoires 2017-04-14 09:56:13 EDT
Update:
- The synaptics code has been merged and will be in v4.12-rc0. I have requested the changes to be backported in Fedora 26/rawhide, but I am still waiting for answers
- I have a piece of code running locally but untested on actual Elan device that is I2C capable. I have asked help from the Elan engineers I know.
Comment 81 Feng Yu 2017-04-16 14:49:59 EDT
Hi Ben, 

Thanks for all this work! I can offer some testing if you let me know how. 

A easier (but not proper) fix is to implement an error-correction in the current serio based driver. Because we know the pattern of the error (a few bytes are missing at the tail of the events), it is very likely we can identify the partial events from the stream, and instead of dropping the broken event, fix it by filling in some 'reasonable' values based on the current state of the device -- to preserve the continuity of events.

This would significantly enhance the probability of recover from a broken event. The current model (4.10.8) seems to be waiting for the stream to be aligned with the event width again, which means we need to manually trigger the right number of broken events. For instance, suppose the rate for triggering the error event is 1/2 (purposely with the three finger trick), and we miss 3 byte out of a 8 byte window on each error, we can recover after ~ 16 three finger tricks on average..
 
I'd like to play with the idea but I then realized the psmouse module is a builtin -- thus any modification will need to reinstall the entire kernel ... not quite ideal for hacking around ...  Is there anything (documentation / packages) from Fedora that eases kernel driver development?
Comment 82 Benjamin Tissoires 2017-04-18 04:04:47 EDT
(In reply to Feng Yu from comment #81)
> A easier (but not proper) fix is to implement an error-correction in the
> current serio based driver. Because we know the pattern of the error (a few
> bytes are missing at the tail of the events), it is very likely we can
> identify the partial events from the stream, and instead of dropping the
> broken event, fix it by filling in some 'reasonable' values based on the
> current state of the device -- to preserve the continuity of events.

I already tried that. The issue is that the eaten bytes are somewhat random and they can be 1, 2 or 3 bytes. Given that the PS/2 protocol doesn't provide anyway of segmenting the data in frames, it gets tricky to detect those on top of the current solution.

> 
> This would significantly enhance the probability of recover from a broken
> event. The current model (4.10.8) seems to be waiting for the stream to be
> aligned with the event width again, which means we need to manually trigger
> the right number of broken events. For instance, suppose the rate for
> triggering the error event is 1/2 (purposely with the three finger trick),
> and we miss 3 byte out of a 8 byte window on each error, we can recover
> after ~ 16 three finger tricks on average..

I doubt we can detect and recover.

I'll give some local tests (got the info from Elan) and provide a scratch-build for you to test here.

>  
> I'd like to play with the idea but I then realized the psmouse module is a
> builtin -- thus any modification will need to reinstall the entire kernel
> ... not quite ideal for hacking around ...  Is there anything (documentation
> / packages) from Fedora that eases kernel driver development?

Not really. The easier is to grab the sources from upstream, the config from /boot/ and recompile everything. You can then change the psmouse module as not builtin.
Comment 83 Rashi 2017-05-30 05:18:26 EDT
Hi, 

I'm a Thinkpad T450s user who suffers same issue as Jonathan posted (comment #10), the only difference is my touchpad is the Synaptics one. The issue doesn't exist in Windows OS, only affecting linux.

I would like to know the current status of the fix or patch for the issue. Would we see the fix on the new kernel release?
Comment 84 Benjamin Tissoires 2017-05-30 06:00:27 EDT
(In reply to Rashi from comment #83)
> I'm a Thinkpad T450s user who suffers same issue as Jonathan posted (comment
> #10), the only difference is my touchpad is the Synaptics one. The issue
> doesn't exist in Windows OS, only affecting linux.

Different driver means different bug. It's hard to keep track of the bugs if many people give a "me too" with a different hardware :)
See if bug #1228566 is not the same than yours, and if so, please switch over to it.

> 
> I would like to know the current status of the fix or patch for the issue.

The fixes for Synaptics have been pushed upstream in kernel v4.12-rc1. So you can try a fedora-rawhide-nodebug[1] kernel and report if you still see the issue (but in a different bug, please)

> Would we see the fix on the new kernel release?

It'll end up in Fedora eventually. Whether it'll be backported is not guaranteed.

[1] https://fedoraproject.org/wiki/RawhideKernelNodebug
Comment 85 Rashi 2017-05-30 06:58:21 EDT
> See if bug #1228566 is not the same than yours, and if so, please switch over to it.

I think it's not a same bug. And I even think the bug reported by jonathan in comment 10 partially might be a different bug from the bug reported by OP here, if looking from the symptoms, as I never got a problem of trackpoint suddenly stop working. But underlying root cause might be same, not sure about this though.

Basically my issue is about "click lock" behavior genereated when clicking the trackpoint's left button and at the same time the touchpad is being touched with two fingers, while the touchpad has been disabled.

Somehow the issue reported by jonathan in his video is same as mine except the jumping cursor part. I haven't met the jumping cursor issue yet.

Here is the detailed description about my issue:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/1694225

I was thinking it's xserver-xorg-input-synaptics bug before found this thread.
Comment 86 Benjamin Tissoires 2017-05-30 07:38:08 EDT
(In reply to Rashi from comment #85)
> Basically my issue is about "click lock" behavior genereated when clicking
> the trackpoint's left button and at the same time the touchpad is being
> touched with two fingers, while the touchpad has been disabled.

This is definitively solved by the switch to RMI4 over SMBus, which is what the Windows driver does. Please test v4.12-rc2, it should be fixed.
Comment 87 Rashi 2017-05-30 12:37:59 EDT
> This is definitively solved by the switch to RMI4 over SMBus, which is what the Windows driver does. Please test v4.12-rc2, it should be fixed.

I just tested it, I can confirm it's been fixed! I hope ubuntu will get the kernel update too.
Comment 88 Steven D. 2017-05-30 19:54:29 EDT
I'm still experiencing the mouse-jumping issue on 4.12-rc2. `lsmod` shows that `i2c_dev` is loaded. What should I do?

Note You need to log in before you can comment on or make changes to this bug.