"disable touchpad while typing" doesn't work on xps 13 and some other laptop

Bug #1672619 reported by Yuan-Chen Cheng
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Triaged
Medium
Unassigned
Xserver Xorg Input Synaptics
Unknown
Medium
xserver-xorg-input-synaptics (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

It's reported that there are lots of false action of touch pad as using keyboard on xps 13
with the factory image.

The factory image is based on xenial.

One propose that install xserver-xorg-input-libinput with modification 90-libinput.conf in /usr/share/X11/xorg.conf.d from

...
Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection
...

to

...
Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
        Option "Tapping" "on"
        Option "PalmDetection" "on"
EndSection
...

helps a lot.

Revision history for this message
Jonathan Keane (jon.keane) wrote :

Owning a XPS13 myself I have experienced this issue "first hand" and can confirm from making the change myself over the last 24 hours that the improvement is very noticeable.

Previously when typing the cursor would jump all over the place (mainly to the bottom left) and open up other windows, so much so I switched off the touch pad.

Now having carried out the change I have not experienced this and am currently working with the touch pad switched back on with no issues to report.

Revision history for this message
Jonathan Keane (jon.keane) wrote :

To clarify, I carried out the package install and didn't carry out the modification*

tags: added: 17.10
information type: Proprietary → Public
Revision history for this message
spike speigel (frail-knight) wrote :

This is indeed a quite annoying bug. I've disabled the touchpad on my Dell XPS 13 9360 because it is way too sensitive and registering false clicks.

I'm using 16.04 LTS.

So how might one fix the issue? Can I simply add those conf settings, or is it a combination of the settings changes and package install?

That package is currently not installed on my system. I do have xserver-xorg-input-synaptics-hwe-16.04 installed...

Revision history for this message
spike speigel (frail-knight) wrote :

/usr/share/X11/xorg.conf.d/50-synaptics.conf has this:

# Example xorg.conf.d snippet that assigns the touchpad driver
# to all touchpads. See xorg.conf.d(5) for more information on
# InputClass.
# DO NOT EDIT THIS FILE, your distribution will likely overwrite
# it when updating. Copy (and rename) this file into
# /etc/X11/xorg.conf.d first.
# Additional options may be added in the form of
# Option "OptionName" "value"
#
Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
# This option is recommend on all Linux systems using evdev, but cannot be
# enabled by default. See the following link for details:
# http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
      MatchDevicePath "/dev/input/event*"
EndSection

I simply added:

        Option "Tapping" "on"
        Option "PalmDetection" "on"

I also enabled "Disable touchpad while typing" under "Mouse and Touchpad" in System Settings...Probably did the same thing as adding those lines in the file. The touchpad behaved much better after that.

Changed in oem-priority:
importance: Undecided → High
importance: High → Medium
status: Confirmed → Triaged
Changed in oem-priority:
importance: Medium → Critical
assignee: nobody → Leon Liao (lihow731)
Revision history for this message
Leon Liao (lihow731) wrote :

I built a xserver-xorg-input-synaptics package for improving the user experience of the touchpad.

On xenial, you can test this experimental package by flowing command:
$ sudo add-apt-repository ppa:lihow731/xenial
$ sudo apt-get update
$ sudo apt-get install xserver-xorg-input-synaptics=1.8.2-1ubuntu3somerville1

More detail:
My modification is "ignore the BTN_TOOL_FINGER event".
On synaptic touchpad, the BTN_TOOL_FINGER event will be sent out at end of serial touch events.
The xserver-xorg-input-synaptics will process the BTN_TOOL_FINGER event as "one finger touched" (in my experiment, it look like a "click" sent out).

The current windows will lost focus when other window be clicked by the BTN_TOOL_FINGER event.
We don't expect this click action.
This behavior will cause users have bad user experiment.

Again, this is a experimental package.
Because, I don't know what is the BTN_TOOL_FINGER event.
And, is it appropriate to ignore this event?
Or, is this BTN_TOOL_FINGER event used by some gestures?
Another thing, I don't find the BTN_TOOL_FINGER event be handled in libinput source code.

Revision history for this message
Leon Liao (lihow731) wrote :

The attached file is the patch to ignore the BTN_TOOL_FINGER.

Revision history for this message
Leon Liao (lihow731) wrote :

I tried the solution in the comment #4.
I feel it is not good enough.
I often lost my windows focus when my palm touched the touchpad.

Revision history for this message
Leon Liao (lihow731) wrote :

More information about the BTN_TOOL_FINGER event.
I found the BTN_TOOL_FINGER definition in https://www.kernel.org/doc/Documentation/input/event-codes.txt.

There are four events: BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, BTN_TOOL_QUADTAP.
One of these events will be sent when click down and click up.
Only one finger touched the touchpad, the BTN_TOOL_FINGER is sent.
Two fingers touched, the BTN_TOOL_DOUBLETAP is sent.
Three fingers touched, the BTN_TOOL_TRIPLETAP is sent.
Four fingers touched, the BTN_TOOL_QUADTAP is sent.

In the xserver-xorg-input-synaptics, the driver knows how many finger is touching via these events.

In the source code, the number of the touching finger is saved in hw->numFingers.
And, the "numFingers == 1" only be used in "Two finger emulation".

Revision history for this message
Leon Liao (lihow731) wrote :

Current investigation state:
The behavior of the BTN_TOOL_FINGER is correct. We should not ignore this event.

As Spike mention in comment #3, this issue is cause by the "tap as click".
The experience will be better when we uncheck the "tap as click" in the Mouse & Touchpad settings.

If you want the "tap as click" function and a good touchpad experience.
I am surveying how to solve this situation.

Revision history for this message
Leon Liao (lihow731) wrote :

I try to have good touchpad experience when enable "tap to click".
Here is my properties that I feel the touchpad would not annoy me when I typping.

In xinput:
Synaptics Tap Time: 60

In syndaemon:
PalmDetect = 0
PalmMinWidth = 7
ref: https://wiki.archlinux.org/index.php/Touchpad_Synaptics#Disable_touchpad_while_typing

More detail:
1. Synaptics Tap Time:
 The default value is 180.
 The "tap to click" is too sensitive.
 My tap time around 0.04 ~ 0.08 second.
 So, I set it to 60 (0.06 second).
 The side effect is the "tap to click" will lost function when the tap time longer than 0.06 second.

2. The syndaemon settings:
PalmDetect = 1
PalmMinWidth = 10
On XPS13, the touchpad won't sent out the z (pressure) value.
When I set the PalmMinWidth = 7. I feel the "tap to click" is seldom to be emit.
But, actually, I don't know if this is the effect of this value.
TODO: I need to print some debug log to debug.

Revision history for this message
Leon Liao (lihow731) wrote :

Below is my conclusion after surveying the palm detect function on XPS13 9360.
The palm detect function is a hardware limitation in xserver-xorg-input-synaptic in XPS13 9360.
 The touchpad does not support "pressure" and "finger width" information.
 These two values are important information in palm detect function.
 Palm detect function would not detect a palm precisely without these values.
 In Xorg.0.log:
[ 7.688] (--) synaptics: DLL075B:01 06CB:76AF Touchpad: invalid pressure range. defaulting to 0 - 255
[ 7.688] (--) synaptics: DLL075B:01 06CB:76AF Touchpad: invalid finger width range. defaulting to 0 - 15

About the "Disable touchpad while typing" option, I don't know why this option is removed in Xenial.

Revision history for this message
Leon Liao (lihow731) wrote :

Another solution: disable the "tap to click" while typing.
On Xenial, this function should be enabled automatically.
But, when the machine have two touchpad devices, this function will fail.

I built a debian package to disable the "SynPS/2 Synaptics TouchPad" and make the "disable the tap to click while typing" function work.

$ sudo add-apt-repository ppa:lihow731/xenial
$ sudo apt-get update
$ sudo apt-get install oem-workaround-touchpad-block-synps2
Then, re-login Xserver.

For more detail, please refer below link:
https://ubuntuforums.org/showthread.php?t=2316240

Revision history for this message
Leon Liao (lihow731) wrote :

More information:
The two touchpad input devices causes the "disable 'tap to click' while typing" function fail.
During booting, the psmouse will register a PS/2 touchpad input device and the hid-multitouch will register another i2c touchpad input device.

After booted, we remove and re-insert the psmouse. The PS/2 touchpad input device won't be registered.

Leon Liao (lihow731)
Changed in oem-priority:
assignee: Leon Liao (lihow731) → nobody
Revision history for this message
In , Mario Limonciello (mario-limonciello) wrote :
Download full text (4.4 KiB)

Created attachment 132004
# xinput list --long

On many Dell systems the Synaptics touchpad has the capability to run in both PS/2 and I2C modes. When running on a modern kernel, the touchpad will run in I2C mode.

When in I2C mode, the 'psmouse' driver is still loaded however, meaning that there are two input devices on the system. No input flows through the 'psmouse' driver, it's all handled via i2c-hid instead.

Unfortunately, when starting up syndaemon doesn't check which touchpad it's actually attached to. The login in syndaemon just looks for a touchpad that supports the Synaptics touchpad properties and both of them support these. This leads to syndaemon not working properly.

Device 'SynPS/2 Synaptics TouchPad':
 Device Enabled (142): 1
 Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (273): 1
 Device Accel Constant Deceleration (274): 2.500000
 Device Accel Adaptive Deceleration (275): 1.000000
 Device Accel Velocity Scaling (276): 12.500000
 Synaptics Edges (297): 1583, 5359, 1371, 4481
 Synaptics Finger (298): 25, 30, 0
 Synaptics Tap Time (299): 180
 Synaptics Tap Move (300): 250
 Synaptics Tap Durations (301): 180, 100, 100
 Synaptics ClickPad (302): 1
 Synaptics Middle Button Timeout (303): 0
 Synaptics Two-Finger Pressure (304): 282
 Synaptics Two-Finger Width (305): 7
 Synaptics Scrolling Distance (306): -113, -113
 Synaptics Edge Scrolling (307): 0, 0, 0
 Synaptics Two-Finger Scrolling (308): 1, 1
 Synaptics Move Speed (309): 1.000000, 1.750000, 0.035168, 0.000000
 Synaptics Off (310): 2
 Synaptics Locked Drags (311): 0
 Synaptics Locked Drags Timeout (312): 5000
 Synaptics Tap Action (313): 2, 3, 0, 0, 1, 3, 0
 Synaptics Click Action (314): 1, 3, 0
 Synaptics Circular Scrolling (315): 0
 Synaptics Circular Scrolling Distance (316): 0.100000
 Synaptics Circular Scrolling Trigger (317): 0
 Synaptics Circular Pad (318): 0
 Synaptics Palm Detection (319): 0
 Synaptics Palm Dimensions (320): 10, 200
 Synaptics Coasting Speed (321): 20.000000, 50.000000
 Synaptics Pressure Motion (322): 30, 160
 Synaptics Pressure Motion Factor (323): 1.000000, 1.000000
 Synaptics Resolution Detect (324): 1
 Synaptics Grab Event Device (325): 0
 Synaptics Gestures (326): 1
 Synaptics Capabilities (327): 1, 0, 0, 1, 1, 1, 1
 Synaptics Pad Resolution (328): 1, 1
 Synaptics Area (329): 0, 0, 0, 0
 Synaptics Soft Button Areas (330): 3471, 0, 4083, 0, 0, 0, 0, 0
 Synaptics Noise Cancellation (331): 28, 28
 Device Product ID (260): 2, 7
 Device Node (261): "/dev/input/event6"

Device 'DLL0704:01 06CB:76AE Touchpad':
 Device Enabled (142): 1
 Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (273): 1
 Device Accel Constant Deceleration (274): 2.500000
 Device Accel Adaptive Deceleration (275): 1.000000
 Device Accel Velocity Scaling (276): 12.500000
 Synaptics Edges (297): 48, 1168, 36, 644
 Synaptics Finger (298): 25, 30, 0
 Synaptics Tap Time (299): 180
 Synaptics Tap Move (300): 61
 Synaptics Tap Durations (301): 180, 100, 100
 Synaptics ClickPa...

Read more...

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

Quick workaround here would be to add an xorg.conf snippet to ignore the mute serial device. Unless you're rebuilding kernels a lot and expect the i2c driver to fail frequently, this won't be a problem otherwise.

For the RMI4 patches, the latest revisions won't make the serial kernel device show up. I'm not 100% sure if that will apply for the i2c patches too. Benjamin? If so, then I think the xorg.conf.d snippet is a good enough workaround until the kernel is in place.

Revision history for this message
In , Benjamin-tissoires (benjamin-tissoires) wrote :

I think most Dell laptops are using hid-rmi, not SMBus.
And there is currently no way from i2c-hid to remove the PS/2 node. I don't see any simple way to achieve that, so I think we will have to deal with it in user space.

Revision history for this message
In , Mario Limonciello (mario-limonciello) wrote :

@Peter:
Yeah an xorg.conf.d snippet can workaround and ignore the PS/2 device, but it's not a very general solution.

@Benjamin:
The machine here is an XPS 13. The touchpad is a precision touchpad. It uses i2c-hid and hid-multitouch not hid-rmi.

One idea that came to mind to me for syndaemon detecting this situation is if multiple devices match the synaptics characteristics pick the one with the higher "Max number of touches". The i2c mode has higher bandwidth and should generally support more touches I think.

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

Mario: the synaptics driver doesn't export the number of touches, so that's a no-go. It'll have to be heuristics or a user-supplied argument.

Revision history for this message
In , Mario Limonciello (mario-limonciello) wrote :

Oh where did that max touches information come from in the --long output (see attachment)?

I'm not sure what other heuristics could reliably be used for detecting this, maybe pad resolution?

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

synaptics 1.8 I suspect, it was dropped with 1.9 which has been out since november

summary: - touch pad on xps 13 need better palm detection mechanism
+ "disable touchpad while typing" doesn't work touch pad on xps 13 need
+ better palm detection mechanism
summary: - "disable touchpad while typing" doesn't work touch pad on xps 13 need
- better palm detection mechanism
+ "disable touchpad while typing" doesn't work on xps 13 and some other
+ laptop
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: New → Confirmed
affects: xserver-xorg-input-synaptics → xserver-xorg-input-synaptics (Ubuntu)
Revision history for this message
In , Mario Limonciello (mario-limonciello) wrote :

Yeah, I see on 1.9 that the max touches doesn't show up for this TP.

As another idea, what about if the order of devices checked is just reversed? Touchpads that support multiple modes will come in up PS2 mode first and get a lower event number as a result. When switching to I2C they should always have higher event numbers right?

So if you reverse the order of devices to check you should start with the higher events and more likely get a better default.

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

No, sorry. That's simply not good enough, if we have to change the code anyway we might as well try to make it work properly instead of hoping that it maybe works. There's no guarantee about the device node ordering and just because that's current kernel behaviour doesn't mean we should rely on it.

A better fix here would be to make syndaemon simply apply to all touchpads rather than just the first one it finds. Except for the case of an external touchpad, this should always work but for external touchpads you don't need syndaemon anyway.

Timo Aaltonen (tjaalton)
Changed in xserver-xorg-input-synaptics:
importance: Undecided → Unknown
status: New → Unknown
no longer affects: xserver
Changed in xserver-xorg-input-synaptics:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Anthony Wong (anthonywong) wrote :

YC, can you post the output from xinput?

Revision history for this message
Leon Liao (lihow731) wrote :

The attached file is the xinput output of XPS13.

Revision history for this message
In , Anthony Wong (anthonywong) wrote :

Peter, what is the best way to distinguish (in the code) whether a touchpad is external or not?

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

dp_get_device() already does that, it checks for the XI_TOUCHPAD type and the "Synaptics Off" property. Look for the "Yay, device is suitable" comment, clearly there was some enthusiasm to spare when I wrote that code :)
That 'break' there is the first hurdle - because of it we don't look at anything but the first touchpad. Start there, and off into the rabbithole it goes...

Changed in oem-priority:
importance: Critical → High
Changed in oem-priority:
importance: High → Medium
Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-synaptics/issues/5.

Changed in xserver-xorg-input-synaptics:
status: Confirmed → Unknown
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: New → Confirmed
Rex Tsai (chihchun)
tags: added: oem-priority
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.