| Summary: | Lenovo G50-45 ETPS/2 Elantech Touchpad strange behavior. | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Przemek <soprwa> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
evemu-record output
kernel config dmesg output finger pressure map over time full dmidecode output dmesg output after patches |
||
|
Description
Przemek
2017-11-28 10:21:11 UTC
You need to run udevadm hwdb --update whenever you add or change a hwdb entry. That seems to be the step missing here. But from your description I think you have a kernel or firmware issue. Run evemu-record --autorestart (see its man page) in the background and when it happens again, *attach* the output here, that should help figuring out what's going on. Created attachment 135823 [details]
evemu-record output
Thanks for the quick response.
I don't think that this would be kernel .config issue, but I could be wrong.
Dmidecode in the part about pointing device says that touchpad is connected thru PS/2 interface so I assumed that I2C should not be under consideration.
"Handle 0x0029, DMI type 21, 7 bytes
Built-in Pointing Device
Type: Touch Pad
Interface: PS/2
Buttons: 4"
I have both, Synaptic and Elanteh, PS/2 enabled in .config file and kernel choose Elantech driver by itself.
After executing "udevadm hwdb --update" and rebooting nothing changes in the output of "udevadm test"
I understand nothing if it's something wrong with the touchpad from the output of "evemu-record --autorestart=30 /dev/input/event9 evemu_record.txt" but here it goes. It was taken when problem occurred.
I have also attached my .config.
Created attachment 135824 [details]
kernel config
ok, this touchpad is busted, it sends ghost touches at more-or-less arbitrary locations. Either that our you had three cats tap-dancing on the touchpad. Has this laptop worked fine until a recent update? The ghost touches are there in the evemu output, which means they're there in the kernel output. So either your touchpad has recently died or some kernel update has broken the elantech driver. Always handy to attach your dmesg, maybe it tells us something. Created attachment 135834 [details]
dmesg output
It happened earlier very sporadically so I was blaming myself for not properly using touchpad. Now it happens more often, so after little investigation I have spotted that physical dimension of touchpad aren't equal to those reported by libinput and this could be the cause of this strange behavior. I have also checked videos about ghost/phantom clicks to see if this applies to my netbook. IMHO it is little bit different. In the "ghost trance" pointer does not move when I am not touching surface, and with mentioned in first post "hovering" pointer follow my finger as it would be on the surface. But when I place finger on the surface then touchpad gets crazy so i thought that it was to sensitive, but custom rules wont be applied by udevadm. You have to wait couple of seconds when touchpad comes down or click physical button to cancel this behavior.
But when those clicks comes from kernel this really sounds like its a problem with kernel driver or hardware/firmware.
Here is dmesg.
Created attachment 135846 [details]
finger pressure map over time
The dimensions only affect pointer acceleration etc, they don't produce the output this recording shows. Grab mtview and run it, then reproduce it. You'll see the jumping touches quickly. https://github.com/whot/mtview There is no single definition of ghost touches beyond "the hardware thinks there is a touch where there is none". That's definitely the case here because there's no way this was your physical input. Look at attachment 135846 [details], it illustrates the pressure the recording shows. It's all over the place, and that diagonal line from 20-42s is just odd, no way could you control your finger that precisely that you get a pressure increase like this. If I read comment 6 correctly: * no pointer movement when not touching * pointer movement ok when close to the surface without touching * pointer movement crazy when touching I don't know how we could possibly detect this. Your best bet would be to change the pressure ranges and hope that palm detection kicks in for most of the ghost touches. But that's not a guarantee. See https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html#hwdb for the instructions, this should make your earlier hwdb work. Created attachment 135862 [details]
full dmidecode output
Here is full dmidecode output.
I fogrot to attach it with previous post, but with such obvious evidence I see no point in playing with changing the pressure ranges. I really think it wont resolve anything.
I agree with your opinion that this touchpad is finished and laptop needed to be RMA'd.
Thank you very much for heping me to resolve this, and my apologies that I thought it was libinput problem.
fwiw, dmidecode doesn't usually matter for libinput's bits. The closest we get is using the dmi modalias, but that's just for hwdb entries. I'm closing the bug as wontfix, simply because I don't think there's anything we can do in libinput to fix it, sorry. Give the pressure bits a try anyway, it may still make it mostly usable. Fair enough. I will give it a chance witch changeing pressure ranges. I wil see how it goes. Thanks anyway. I mean "with" - T9 android dictionary. Once again thanks. It could be interesting to see if the touchpad is not using a SMBus connection after all. I would be surprised the Windows version of the driver suffer the same issues. Could you apply the last five commits from https://github.com/bentiss/linux/commits/elan_i2c-v4.15-rc2+ (on top of a v4.14 or this branch directly)? These patches should bind the touchpad over SMBus if the PS/2 interface says it is capable, and we might solve the issue. Once the patches are applied, please upload a dmesg, as the last commit says, there will be some debug information whether or not this touchpad is SMBus capable. Created attachment 136050 [details] dmesg output after patches Hi Benjamin, I cannot open link provided in comment 13, but I have applied last 5 commits from https://github.com/bentiss/linux/commits/elan_i2c-v4.15-rc2%2B - Input: elan_i2c - add trackstick report - Input: elantech - split device info into a separate structure - Input: elantech - query the resolution in query_info - Input: elantech - add support for SMBus devices - WIP: just pr_err to trace elantech initialization Here is dmesg output. > I cannot open link provided in comment 13,
Yeah, sorry, bugzilla messed up the final '+' in the address. You applied the correct patches BTW. And thanks for the fast tests!
As the dmesg shows, the device is not capable of anything but PS/2:
[ 5.079823] elantech_init bus: 0 drivers/input/mouse/elantech.c:1954
(bus '0' means ETP_BUS_PS2_ONLY)
So there is not much we can do besides quirks from libinput.
Arghhh, too fast clicking, I haven't notice the "+" sign at the end, either would not bother you to check if I was patching correct commits. Sorry. I was just packing laptop up cause it is going to be RMA anyway, so decided to make quick test with those patches hoping that we could change something, this would be better than week or two without work tool. At least we know that this touchpad is PS2 only. As for the quirks, as I wrote before, I don't think this could help a lot. Searching internet showed up that this malfunction is common with linux and windows on this model, so I have 99% probability that this touchpad is already dead or dying. Thank you very much for your help. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.