please run evemu-record against event15 and see if the events show up there. This is most likely a hardware problem, we don't generate touches in libinput and merely forward what the hardware gives us.

(In reply to Peter Hutterer from comment #1)
> please run evemu-record against event15 and see if the events show up there.
> This is most likely a hardware problem, we don't generate touches in
> libinput and merely forward what the hardware gives us.

That is what I suspected too, that it could be a hardware problem. But 2 machines showing similar symptoms got me thinking otherwise.

The best will be to record evemu data on both machines when they trigger.

Please let's continue to keep this open. As soon as I get the trigger, I'll try to extract the data. Thanks.

any success?

(In reply to Peter Hutterer from comment #3)
> any success?

No. I haven't been able to reproduce in the last week. I'm marking it closed. If I get enough data, I'll re-open this bug. Thanks.

Created attachment 130466 [details]
evemu-record data for touch screen

I got to capture the data, not from the xserver session itself, but over the modesetted terminal. I hope this has useful information in it.

ok, this is a bug, but definitely not with libinput. the recording has 63 seconds of events through all 10 slots but without a single x axis value. This looks like a device going crazy, I would suggest this is a hardware issue. There isn't much we can do here, the heuristics to detect this are likely to be tricky. This bugzilla doesn't have a CANTFIX, so I'm using wontfix instead.

CC-ing benjamin in case he's aware of some kernel-level fix to avoid this issue.

It looks like a HW defect indeed. Just to be sure, could you attach a hid-recorder [1] output of a few touches? (doesn't matter if the bug is exposed or not I think).

[1] project hid-replay http://bentiss.github.io/hid-replay-docs/

(In reply to Benjamin Tissoires from comment #7)
> It looks like a HW defect indeed. Just to be sure, could you attach a
> hid-recorder [1] output of a few touches? (doesn't matter if the bug is
> exposed or not I think).
> 
> [1] project hid-replay http://bentiss.github.io/hid-replay-docs/

I wouldn't conclude so quick. These are all talking over xHCI BUS, which has shown too many problems under Linux.

I also have Windows 8.1 running on the spare partition, where I have not had any of these errors.

I'll try to capture more data with the mentioned tool. I'm not sure when I can get back because the issue is intermittent.


@Peter: I'm still hoping to capture data from the other machine, which does not have touchscreen at all. I've seen similar (if not identical) behavior there, intermittently. The only common thing among the two is that they're both Haswell family machines.

Created attachment 130482 [details]
Elan Touchscreen hid data

Luckily, I was able to reproduce it today itself. Please find attached the log details you asked.

Looking at the Xorg logs, I see repetitive messages for the same input device. Is this expected ?



rrs@learner:~$ grep ELAN .local/share/xorg/Xorg.0.log
[    38.112] (II) config/udev: Adding input device ELAN Touchscreen (/dev/input/event15)
[    38.112] (**) ELAN Touchscreen: Applying InputClass "libinput touchscreen catchall"
[    38.112] (II) Using input driver 'libinput' for 'ELAN Touchscreen'
[    38.112] (**) ELAN Touchscreen: always reports core events
[    38.113] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[    38.113] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[    38.113] (II) XINPUT: Adding extended input device "ELAN Touchscreen" (type: TOUCHSCREEN, id 9)
[    38.113] (**) ELAN Touchscreen: (accel) selected scheme none/0
[    38.113] (**) ELAN Touchscreen: (accel) acceleration factor: 2.000
[    38.113] (**) ELAN Touchscreen: (accel) acceleration threshold: 4
[    38.113] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[    38.113] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[    38.114] (II) config/udev: Adding input device ELAN Touchscreen (/dev/input/mouse1)
[    56.898] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[    56.898] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[   481.416] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[   481.416] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[  1295.273] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[  1295.273] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[  3401.195] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[  3401.195] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[  3402.748] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[  3402.748] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[  3427.944] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[  3427.944] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[  8444.825] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[  8444.825] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 11666.309] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 11666.309] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 14478.226] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 14478.226] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 17175.361] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 17175.361] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 17290.441] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 17290.442] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 19715.230] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 19715.230] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 19883.063] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 19883.063] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 19974.331] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 19974.331] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 19974.546] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 19974.546] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 21107.535] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 21107.535] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
[ 23780.539] (II) SYN_DROPPED event from "ELAN Touchscreen" - some input events have been lost.
[ 24215.982] (II) input device 'ELAN Touchscreen', /dev/input/event15 is tagged by udev as: Touchscreen
[ 24215.982] (II) input device 'ELAN Touchscreen', /dev/input/event15 is a touch device
2017-03-27 / 17:25:13 ♒♒♒  ☺

The log clearly show a column of touches at coordinate X=967. From time to time we can see your true fingers, but the ghost line is still there. I doubt there is an issue in the USB communication but I strongly believe the FW fails at ignoring a ghost column of touches.

The weird part is that you do not have the same issue with Windows. It could be interesting comparing the USB events from Windows when inserting the driver from the ones we do under Linux. But I don't have high hope on whether it will help fixing the issue.

(In reply to Benjamin Tissoires from comment #11)
> The log clearly show a column of touches at coordinate X=967. From time to
> time we can see your true fingers, but the ghost line is still there. I
> doubt there is an issue in the USB communication but I strongly believe the
> FW fails at ignoring a ghost column of touches.
> 
> The weird part is that you do not have the same issue with Windows. It could
> be interesting comparing the USB events from Windows when inserting the
> driver from the ones we do under Linux. But I don't have high hope on
> whether it will help fixing the issue.

Thanks Benjamin.

I spent the rest of the day today, running it under Windows. Eventually, after a couple of hours, I was able to reproduce it under Windows 8.1 too.

That led me to check Lenovo Support Forums.

https://support.lenovo.com/in/en/solutions/ht103512
http://laptopmedia.com/news/lenovos-solution-to-the-yoga-ghost-touches-problem/
https://forums.lenovo.com/t5/forums/v3_1/forumtopicpage/board-id/ll06_en/page/10/thread-id/26944


Almost the entire Yoga series seems to suffer from the problem. Lenovo stated in some of the threads that it may be a software problem. But I doubt that. Let's see... I'm going to try a couple of sw fixes, with very less hope.


Thank you for your time in analyzing the logs.