→ uname -a Linux x1.local 4.16.0-300.fc28.x86_64 #1 SMP Tue Apr 3 03:44:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux From the log: Apr 10 09:07:40 x1.local /usr/libexec/gdm-x-session[1630]: (EE) libevdev: BUG: Device "Synaptics TM3288-011" received a double tracking ID 15 in slot 0. Apr 10 09:08:13 x1.local /usr/libexec/gdm-x-session[1630]: (EE) libevdev: BUG: Device "Synaptics TM3288-011" received a double tracking ID 44 in slot 1. Apr 10 09:08:14 x1.local /usr/libexec/gdm-x-session[1630]: (EE) libevdev: BUG: Device "Synaptics TM3288-011" received a double tracking ID 49 in slot 2. ... Apr 10 15:53:58 x1.local org.gnome.Shell.desktop[977]: libinput error: libevdev: BUG: Device "Synaptics TM3288-011" received a double tracking ID 85 in slot 0. Seems to be printed when starting X11/Wayland
Could you provide an evemu-record of the device when the bug occurs?
Created attachment 1421027 [details] evemu-record log touchpad.log.2018-04-12-21:00:28 I think I got one: Apr 12 21:00:29 x1.local org.gnome.Shell.desktop[1716]: libinput error: libevdev: BUG: Device "Synaptics TM3288-011" received a double tracking ID 141 in slot 0. Log is from touchpad.log.2018-04-12-21:00:28 Btw, I am also seeing something that might be related: Apr 12 20:54:02 x1.local org.gnome.Shell.desktop[1716]: libinput error: client bug: timer event17 debounce short: offset negative (-0ms) [...] Apr 12 20:53:43 x1.local org.gnome.Shell.desktop[1716]: libinput error: client bug: timer event17 debounce short: offset negative (-4ms)
Thanks for the logs. There is indeed a new tracking ID without changing slot, and this occurs when there is a new tool type: E: 0.122769 0003 0035 0620 # EV_ABS / ABS_MT_POSITION_X 620 E: 0.122769 0003 0036 0053 # EV_ABS / ABS_MT_POSITION_Y 53 E: 0.122769 0003 0000 0620 # EV_ABS / ABS_X 620 E: 0.122769 0003 0001 0053 # EV_ABS / ABS_Y 53 E: 0.122769 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +15ms E: 0.138191 0003 0039 0141 # EV_ABS / ABS_MT_TRACKING_ID 141 <--- here E: 0.138191 0003 0037 0002 # EV_ABS / ABS_MT_TOOL_TYPE 2 E: 0.138191 0003 0035 0634 # EV_ABS / ABS_MT_POSITION_X 634 E: 0.138191 0003 0036 0055 # EV_ABS / ABS_MT_POSITION_Y 55 E: 0.138191 0003 003a 0078 # EV_ABS / ABS_MT_PRESSURE 78 E: 0.138191 0003 0000 0634 # EV_ABS / ABS_X 634 E: 0.138191 0003 0001 0055 # EV_ABS / ABS_Y 55 E: 0.138191 0003 0018 0078 # EV_ABS / ABS_PRESSURE 78 E: 0.138191 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +16ms The reason is how input_mt_report_slot_state() reports the change of tool type: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/input/input-mt.c#n154 Peter, do you think this is something that needs to be changed in the kernel or better handled in libinput?
I'll have to fix this in libevdev first (it suppresses the double tracking ID), then in libinput to handle that case. The libevdev bit is easy https://lists.freedesktop.org/archives/input-tools/2018-April/001466.html Proper handling of this in libinput is going to be nasty, it's just not designed for that. But it's probably fine to just ignore the tracking ID changes in libinput. For the most part, it won't have an effect because we'll pick up the tool type independently.
Just for the record: the only effect of the libevdev behaviour here is the log message. The tracking id is transparently discarded and the upper levels of the stack just continue to see a touch point. In this case, the touch point changes to a palm which should cause libinput to discard the touch's events. The only real bug that may be exposed by this behaviuor is that in some tap-to-click cases the tap may not trigger correctly as it looks like a continuous touch instead. But here the second touch is a palm anyway and the whole thing is triggered by the touch->palm transition in the kernel. Thus I'd even argue that's the more correct behaviour. The alternative would be to release the touch (causing a tap) and then starting a new touch (now palm) that is ignored. That's worse than missing a tap... Also, whoah, that case is going to be even nastier to implement in libinput than I thought... Regarding the timer message: https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_timer_offset
libinput-1.10.4-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7697fc0b90
FTR, I'm changing this bug to libinput. There are a few issues with this device, the one pointed out here is just a side-effect of the real issue. The kernel creates a new tracking ID when switching to a new ABS_MT_TOOL_TYPE. This causes libevdev to log an error message, a patch to accommodate for that is proposed upstream, see comment #4. But other than the log message there is no visibie effect, libinput proceeds to treat the device as palm because the tool change suggests so. And herein lies the real problem: this device randomly switches to MT_TOOL_PALM, causing the pointer to randomly stop moving. Hence I'm switching this to libinput, we need a quirk to ignore this on the Lenovo Carbon X1 6th. That's what the libinput build in comment #7 fixes.
libinput-1.10.4-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7697fc0b90
libinput-1.10.4-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
I am also receiving the above message regularly since a few days. But I am seeing an effect: "Tap to Click" doesn't work anymore. After a few minutes it starts working again for a while, then failing again. Do I need to wait for "libevdev 1.6.0"? Which logs should I provide to investigate the issue?
I missed the move to Gitlab. My "Tap to Click" issue is already tracked here: https://gitlab.freedesktop.org/libinput/libinput/issues/46