Synaptics kernel driver does not report finger width information, breaking usermode driver's palm detection

Bug #1245328 reported by Daniel Colascione
64
This bug affects 13 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

While doing some work on the Xorg synaptics driver, I noticed that we never actually detect palm blocking even after running synclient PalmDetect=1. Digging in a bit, the driver claims in its capability bits that it should be sending ABS_TOOL_WIDTH records, but according to evtest(1), the driver never sends these advertised records to userspace. As a result, the Xorg synaptics driver never sees hw->fingerWidth become non-zero in SynapticsDetectFinger and never detects that I've mashed my palm into the large touchpad on this machine.

Expected:

Kill X. Run evtest(1). Select touchpad device. Move touchpad. See ABS_TOOL_WIDTH records in the event stream.

Actual:

No ABS_TOOL_WIDTH records even though the device claims to support them in its capability bits.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-12-generic 3.11.0-12.19 [modified: boot/vmlinuz-3.11.0-12-generic]
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dancol 2258 F.... pulseaudio
Date: Sun Oct 27 21:43:01 2013
HibernationDevice: RESUME=UUID=7da7377a-42c7-49f8-a060-8dee466c61fd
InstallationDate: Installed on 2013-10-23 (4 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MachineType: LENOVO 34601F5
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.11.0-12-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-12-generic N/A
 linux-backports-modules-3.11.0-12-generic N/A
 linux-firmware 1.116
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/29/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: G6ET96WW (2.56 )
dmi.board.asset.tag: Not Available
dmi.board.name: 34601F5
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: 2059198
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG6ET96WW(2.56):bd04/29/2013:svnLENOVO:pn34601F5:pvrThinkPadX1Carbon:rvnLENOVO:rn34601F5:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 34601F5
dmi.product.version: ThinkPad X1 Carbon
dmi.sys.vendor: LENOVO

Revision history for this message
Daniel Colascione (dcolascione) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.12 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc7-saucy/

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Gabriele (questaemia) wrote :

Same exact problem with another machine (Dell XPS13 9333).

I'm not using Ubuntu, but Debian. I can confirm it happens with v3.12 and v3.13.

Here what Xorg.log.0 says:
[ 5.548] (--) synaptics: SynPS/2 Synaptics TouchPad: finger width range 0 - 15

Still, ABS_TOOL_WIDTH is never reported.

Here the patch I'm currently using to have a working palm detection: http://xps13-9333.appspot.com/root/0001-Don-t-use-finger-width-for-the-palm-detection.patch
It's not perfect, but better than nothing.

Changed in linux (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Maxwell Anselm (silverhammermba) wrote :

Same problem on Arch with kernel 3.14.4-1 and xf86-input-synaptics 1.8.0-1. Xorg log reports "finger width range 0-15" but hw->fingerWidth is always 0.

I'm a little confused about where the problem lies. Is this something to be fixed in the synaptics driver or elsewhere?

Revision history for this message
Gabriele (questaemia) wrote :

The kernel is not reporting to the userspace the width of the fingers with new touchpads, even if the hardware is capable of that. The reason is that pressure and width are not independent, so knowing one of them is enough (at least according to what's written here: https://lkml.org/lkml/2011/8/15/73).

The problem here is that the userspace driver was not updated to meet this decision and hence the patch I posted here above is required.

Revision history for this message
Maxwell Anselm (silverhammermba) wrote :

I'm not getting the same impression from that. They claim that ABS_MT_PRESSURE and ABS_MT_TOUCH_MAJOR are mutually exclusive, but that makes sense because they are reporting the Z as ABS_MT_TOUCH_MAJOR. It still seems to me that the touchpad should either report valid ABS_TOOL_WIDTH values or say that it doesn't support that event at all.

Revision history for this message
Gabriele (questaemia) wrote :

What I understood is that the hardware is capable of detecting either the width or the pressure. I suppose that the one which is not really detected is calculated starting from the same informations, so it's actually not useful having both of them reported.

The following kernel patch will make the kernel report the width again if you want to test whether they are really dependent or not: http://pastebin.com/rjGyM5pC

Either way, you have to recompile something.

Revision history for this message
Maxwell Anselm (silverhammermba) wrote :

But there's also this bit on line 1158:

 if (SYN_CAP_PALMDETECT(priv->capabilities))
  input_report_abs(dev, ABS_TOOL_WIDTH, finger_width);

And my touchpad does report that it has the palm detection capability. It looks like I should be seeing widths reported then.

Revision history for this message
Gabriele (questaemia) wrote :

The lines you posted are never executed with certain touchpads, look right above them:

if (SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)) {
 synaptics_image_sensor_process(psmouse, &hw);
 return;
}

synaptics_image_sensor_process() uses synaptics_report_slot() to send the events to the userspace. The last patch I posted makes synaptics_report_slot() send ABS_TOOL_WIDTH.

Revision history for this message
Maxwell Anselm (silverhammermba) wrote :

Ah, I see now that there are several points at which it could return early and not reach the ABS_TOOL_WIDTH code.

I tried out your little patch to force the width to be reported and captured evtest output during a session of normal computer use. First, I noticed that still the width was not always reported, though it seemed to be reported most often when I brushed my palm against the pad. Secondly, I wanted to test the claim that it is not meaningful to report pressure and width simultaneously so I parsed out the (width, pressure) pairs from evtest and plotted them. While there is a positive correlation between the two, it is definitely possible to have low pressure/high width touches and vice versa.

Here are my data if you are curious:
https://gist.github.com/silverhammermba/43abb0fde7b17d557d2b

From what I've read about the kernel multitouch protocol, the claim from your previous link that "ABS_MT_PRESSURE and ABS_MT_TOUCH_MAJOR are normally mutually exclusive" only makes sense if the tool width (i.e. ABS_MT_WIDTH_MAJOR) is being reported. In that case the pressure should be equivalent to the ratio of TOUCH_MAJOR to WIDTH_MAJOR and it would not make sense for a device to report both. Thus there are two acceptable situations for a device that claims to report tool width: report tool width and pressure or report tool width and touch width.

The second problem - the palm detection code not working without width - seems like it could be more generally useful if there are touchpads that only report pressure. However I don't see that as the issue here since it seems clear that my touchpad *can* report width.

Revision history for this message
Gabriele (questaemia) wrote :

I did the same test once and because of my lazyness I just saw that the pressure and the width were not completely uncorrelated. I didn't analyze the result of my tests carefully and just assumed that what I read on the emails I linked was correct (or at least my interpretation of them).

Anyway, I did the same test once more and obtained your same result: http://pastebin.com/raw.php?i=7SZupHuz

At this point, I really don't know the reason of why ABS_TOOL_WIDTH is not reported.

I guess that opening a bug report on https://bugzilla.kernel.org/ will clear all the doubts. This is an upstream kernel bug after all.

Revision history for this message
Maxwell Anselm (silverhammermba) wrote :
Revision history for this message
Biep (biep) wrote :

Can someone help an Ubuntu n00b (16.04) - how do I switch from synaptics to libinput?
What setting should I change, and how dangerous is doing so?
If e.g. the touchpad stops working, how do I undo my changes?

Thank you!

Revision history for this message
ALinuxUser (buntulongername-new) wrote :

@Durieux

I am unsure this is the place for such questions, but the answers are as follows (at least for Linux Mint).

Run the package manager that is called (confusingly) Synaptics. You should be able to find it in a menu under that name or under a name such as 'package manager'. Search for and install the package 'xserver-xorg-input-libinput'. Search for and uninstall the package 'xserver-xorg-input-synaptics'. Were you to have both installed at once, one - I do not know which - would likely take precedence over the other. The worst that could happen with any of this is that you end up with no functioning driver and have to use the keyboard and/or terminal to ensure that you have one of the drivers installed.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.