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:
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.
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.
Created attachment 1140710 [details] dmesg output starting when the trackpoint/touchpad stop working, and ending when they start working again
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
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.
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.
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.
> The bug no longer occurs in Fedora though. You mean on Fedora 23 or on Rawhide?
I'm on Fedora 23 with latest updates and it's definitely not fixed here
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.
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
(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?
This is still broken in Fedora 24. Bumping version.
whot: any ideas, by any chance?
Steven: your issue is unrelated and most likely in libinput. Please file a separate bug and assign it to me, thanks.
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.
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.
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
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
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
(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)
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?
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
(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?
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...
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
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
Good call Jonas, `dis_ucode_ldr` allows me to boot smoothly on 4.7. Though the same issue with the Trackpoint/Touchpad persists.
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
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.
Created attachment 1181884 [details] ps2emu-record log with touchpad enabled
Created attachment 1181885 [details] ps2emu-record log with touchpad disabled
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 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.
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.
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.
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?
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?).
Alright thanks! Just FYI, I am dual-booting and do not experience the issue on Windows 10.
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.
Thanks for the update! Do you know how I could figure out which bus is used on Windows?
(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.
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?
(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 :(
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.
Created attachment 1191881 [details] acpidump as root Sorry for the delay. Attached as requested. Thanks Benjamin!
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.
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?
(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.
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
Created attachment 1195411 [details] Output of ls -l /sys/bus/acpi/devices/
(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.
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.
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.
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 :)
ping?
Created attachment 1202952 [details] i2c-detect output
Created attachment 1202953 [details] status_output
Created attachment 1202954 [details] tree_output
There you go! Let me know what else you need!
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.
*********** 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.
(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?
(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.
(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
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?
(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.
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?
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
Done. When I run that command, the trackpoint stops working, but the touchpad continues to work, unlike before when both failed.
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.
(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.
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
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?
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]
I still have the same issues on rawhide 4.10 though
(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 :)
*********** 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.
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.
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.
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?
(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.
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?
(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
> 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.
(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.
> 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.
I'm still experiencing the mouse-jumping issue on 4.12-rc2. `lsmod` shows that `i2c_dev` is loaded. What should I do?
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.