Bug 76341 - Dell XPS 13 touchpad behaviour broken with synaptics 1.7.99.1
Summary: Dell XPS 13 touchpad behaviour broken with synaptics 1.7.99.1
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/synaptics (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Peter Hutterer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-19 00:09 UTC by Adam Williamson
Modified: 2014-03-21 15:02 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log from affected system (38.68 KB, text/plain)
2014-03-19 05:18 UTC, Adam Williamson
no flags Details
evemu recording - three failed clicks and a click+move (40.56 KB, text/plain)
2014-03-20 03:15 UTC, Peter Hutterer
no flags Details
evemu recording - cursor jump (66.81 KB, text/plain)
2014-03-20 03:17 UTC, Peter Hutterer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Williamson 2014-03-19 00:09:09 UTC
I run Fedora Rawhide on my Dell XPS 13 (previous generation developer edition). In the last week or so - I believe since xorg-x11-drv-synaptics-1.7.99-3.20140312git2e5c0cf43.fc21 landed - the touchpad behaviour has become very erratic. xorg-x11-drv-synaptics-1.7.99.1-1.20140318gitfd7099004.fc21 does not make things any better.

Previously I had a couple of issues with multi-finger behaviour, but at least the full area of the pad worked as expected and I could left and right click in the expected areas. Now, it's...weird.

A click almost anywhere in the top two thirds of the trackpad is usually interpreted as a left click. A two-finger (or three finger) click is interpreted as a right click. If I'm moving the cursor with a finger of my right hand and then I click with a finger of my left hand, this is usually interpreted as a right click as well (I'm pretty sure that didn't used to be the case). I can't right-click with a single finger at the right hand side of the pad, though, as I'd expect.

Single-finger clicks in the bottom third or so of the pad usually don't work at all - no response. *Sometimes* they do work, but I can't figure out precisely when they do and when they don't. It seems to have something to do with whether I've been moving the cursor using that area of the pad or not. That area behaves more or less normally for pointer movement, and two-finger clicks in it seem to always work.

Sometimes - I can't figure out exactly what action triggers it, but I'm sure it's happening more than before... - the pointer will just leap to another location on the screen. Rather irritating.

In Xorg.0.log I see this:
[    14.913] (II) LoadModule: "synaptics"
[    14.913] (II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so
[    14.914] (II) Module synaptics: vendor="X.Org Foundation"
[    14.914] (II) Using input driver 'synaptics' for 'CyPS/2 Cypress Trackpad'
[    14.948] (II) synaptics: CyPS/2 Cypress Trackpad: ignoring touch events for semi-multitouch device
[    14.948] (II) synaptics: CyPS/2 Cypress Trackpad: found clickpad property
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: x-axis range 0 - 1600 (res 16)
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: y-axis range 0 - 900 (res 15)
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: pressure range 0 - 255
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: finger width range 0 - 255
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: buttons: left right middle double triple
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: Vendor 0x2 Product 0x11
[    14.948] (--) synaptics: CyPS/2 Cypress Trackpad: touchpad found
[    14.963] (**) synaptics: CyPS/2 Cypress Trackpad: (accel) MinSpeed is now constant deceleration 2.5
[    14.963] (**) synaptics: CyPS/2 Cypress Trackpad: (accel) MaxSpeed is now 1.75
[    14.963] (**) synaptics: CyPS/2 Cypress Trackpad: (accel) AccelFactor is now 0.109
[    14.964] (--) synaptics: CyPS/2 Cypress Trackpad: touchpad found
[    14.964] (II) Using input driver 'synaptics' for 'CyPS/2 Cypress Trackpad'
[    14.978] (EE) synaptics: CyPS/2 Cypress Trackpad: Synaptics driver unable to detect protocol
[    14.978] (II) UnloadModule: "synaptics"
Comment 1 Peter Hutterer 2014-03-19 04:07:26 UTC
just in case: you have the latest libevdev installed? 1.1RC1 or later?
Comment 2 Adam Williamson 2014-03-19 04:50:25 UTC
libevdev-1.0.99.1-1.fc21.x86_64
Comment 3 Peter Hutterer 2014-03-19 05:15:42 UTC
pls attach your whole xorg log, the "unable to detect protocol" message is a bit odd. also, run evemu-record, try to reproduce one of these jumps and attach the event sequence here.
Comment 4 Adam Williamson 2014-03-19 05:18:21 UTC
the jumps are the hardest thing to pin down, unfortunately :/ i think probably to do with my habit of using both hands on different sides of the touchpad, which is probably unfair. if they were the only problem I could live with it, the lack of clickability at the bottom of the pad and the lack of a 'geographic' right click are much worse.
Comment 5 Adam Williamson 2014-03-19 05:18:54 UTC
Created attachment 96025 [details]
Xorg.0.log from affected system
Comment 6 Peter Hutterer 2014-03-20 03:06:00 UTC
Update from an IRC discussion with Adam:
The missing left click is caused by the touchpad not recognising a new touchpoint for the clicking finger. Usage appears to be one finger on the touchpad, a second finger hitting the button. But the second finger doesn't get a touch point, so we have a BTN_LEFT event on its own, with no coordinate data. The sequence is:

E: 0.000000 0001 0110 0001	# EV_KEY / BTN_LEFT             1
E: 0.000000 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
E: 0.243028 0001 0110 0000	# EV_KEY / BTN_LEFT             0
E: 0.243028 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
E: 1.365750 0001 0110 0001	# EV_KEY / BTN_LEFT             1
E: 1.365750 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
E: 1.586782 0001 0110 0000	# EV_KEY / BTN_LEFT             0
E: 1.586782 0000 0000 0000	# ------------ SYN_REPORT (0) ----------

This is most likely introduced by bbe4c56c4998a90b478581a4d93717251d8e05be, we probably need some better approach here.
Comment 7 Peter Hutterer 2014-03-20 03:15:51 UTC
Created attachment 96077 [details]
evemu recording - three failed clicks and a click+move
Comment 8 Peter Hutterer 2014-03-20 03:17:10 UTC
Created attachment 96079 [details]
evemu recording - cursor jump
Comment 9 Hans de Goede 2014-03-20 08:36:27 UTC
(In reply to comment #6)
> Update from an IRC discussion with Adam:
> The missing left click is caused by the touchpad not recognising a new
> touchpoint for the clicking finger. Usage appears to be one finger on the
> touchpad, a second finger hitting the button. But the second finger doesn't
> get a touch point, so we have a BTN_LEFT event on its own, with no
> coordinate data. The sequence is:
> 
> E: 0.000000 0001 0110 0001	# EV_KEY / BTN_LEFT             1
> E: 0.000000 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
> E: 0.243028 0001 0110 0000	# EV_KEY / BTN_LEFT             0
> E: 0.243028 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
> E: 1.365750 0001 0110 0001	# EV_KEY / BTN_LEFT             1
> E: 1.365750 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
> E: 1.586782 0001 0110 0000	# EV_KEY / BTN_LEFT             0
> E: 1.586782 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
> 
> This is most likely introduced by bbe4c56c4998a90b478581a4d93717251d8e05be,
> we probably need some better approach here.

http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=bbe4c56c4998a90b478581a4d93717251d8e05be

Will only cause this issue if the first finger is only very lightly on the touchpad, so that (hw->z < para->finger_low) is true. Also you very correctly notice that "we have a BTN_LEFT event on its own, with no coordinate data" . Since this is a clickpad that means the click could be any button (right middle or left) so ignoring it might actually be the best thing we can do.

IMHO the TL;DR: here is: "with the current synpatic driver and clickpads people cannot have another finger on the touchpad while clicking".

Let me illustrate why I say this, lets say the first finger down is in the middle of the pad and it is down hard enough to make (hw->z >= para->finger_low) and then a second finger clicks in the right button click area, since we always use the coordinates of the first finger down this click will now register as a left click, while it should be a right click. Until we get a completely new driver with reliable per finger tracking we can simply never make having more then one finger at the touchpad when starting a click work reliable.
Comment 10 Adam Williamson 2014-03-20 15:29:05 UTC
Um. I don't know where we've got wires crossed, but I can actually reproduce this bug without my right finger on the trackpad at all.

I can move the cursor into position with my right finger, remove it from the pad, do a left click with my left finger without the right finger on the pad at all, and trigger the bug.

As for 'geographic' right clicks - in some builds of 1.8 they don't work at all, but in some they do, and in the builds where they do work, they're completely reliable. They are not affected by this 'erraticness' issue.
Comment 11 Hans de Goede 2014-03-20 15:47:24 UTC
(In reply to comment #10)
> Um. I don't know where we've got wires crossed, but I can actually reproduce
> this bug without my right finger on the trackpad at all.
> 
> I can move the cursor into position with my right finger, remove it from the
> pad, do a left click with my left finger without the right finger on the pad
> at all, and trigger the bug.
> 
> As for 'geographic' right clicks - in some builds of 1.8 they don't work at
> all, but in some they do, and in the builds where they do work, they're
> completely reliable. They are not affected by this 'erraticness' issue.

Hmm, ok. So when you see this happen, were on the touchpad are you clicking ?  And can you try to click in another area ?  I've the feeling your touchpad may have a dead area where it does not report any fingers at all, only the click of the physical button below the touchpad.
Comment 12 Adam Williamson 2014-03-20 16:31:59 UTC
Hans: I think you've got the wrong end of a stick somewhere. Peter has a better handle on this issue.

This is a clickpad, it has no physical buttons. The issue occurs only in the soft button area, and only affects left clicks within that area - i.e. it's restricted to the bottom left corner of the pad. There is no 'dead area', I can move the cursor using that area of the pad just fine.

Let's hope the ASCII art comes out OK:

-----------------------------------------
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|                                        |
|LLLLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRRRRRRRR|
|LLLLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRRRRRRRR|
|LLLLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRRRRRRRR|
-----------------------------------------|

The main issue in question is restricted to the area marked 'L' there. Note the whole pad is a click pad: those are not physical buttons.

Clicking in the area marked 'R', with a build not affected by the separate bug, always gives a right click (it does not have the same 'unreliability' problem). 

Clicking in the area marked 'L' sometimes gives a left click, but sometimes does not. This does not depend on having another finger on the pad or not. When it does not, holding the button down and dragging converts the failure into a success. It is not the case that there are sub-areas of L which always work, and sub-areas which always fail; there are no 'dead spots'. Instead, as Peter has worked out, it seems like if I manage to click in that area without registering a finger location first, the click fails.

Clicking anywhere in the unmarked area reliably gives a left click.
Comment 13 Adam Williamson 2014-03-20 16:40:30 UTC
Interestingly, if you start a finger movement inside the soft button area, it won't be picked up until you've moved a short distance - the cursor won't move, and the left-click bug happens. I have to move my finger about, say, a half a centimetre before I see the cursor move (and to avoid triggering this bug). This also happens if you 'swipe into' the soft button area - swipe up from off the bottom of the pad, or right from outside the bottom-left corner of the pad, or left from the bottom-right corner. If you start a finger movement elsewhere on the pad, or 'swipe in' from the top or higher up the sides, the cursor starts tracking instantly.
Comment 14 Adam Williamson 2014-03-20 21:33:49 UTC
So we figured out what's causing a problem here: this particular trackpad is actually implementing soft buttons in firmware. When you watch it with evemu-record, the behaviour of the bottom area of the pad is very different from the rest.

In most of the pad, as soon as you touch the pad, it starts recording events - pressure, location, all that stuff.

In the 'firmware button area' (let's call it) - about the bottom 20% of the pad surface - just putting a finger on the pad generates no events. Even moving the finger a small amount generates no events. If you click in the bottom left of the pad, it generates a btn_left event, and *nothing else* - no location, no pressure, no movement even if your finger moves a little bit. If you click in the bottom right of the pad, it generates a btn_right event, and *nothing else*.

So the pad doesn't have any physical buttons, but the pad's firmware is emulating two buttons quite hard.

If I tell the driver the pad isn't a click pad - by setting the "Synaptics ClickPad" property to 0 - the left-click erraticness bug goes away, and I can still generate both left and right clicks, thanks to the pad's firmware. It may be a 'sufficient' fix just to have the driver not treat this particular bit of hardware as a clickpad. Let me know what information I should provide to help the driver precisely identify this hardware.
Comment 15 Adam Williamson 2014-03-20 21:40:29 UTC
Telling the driver not to consider it as a clickpad even makes middle button emulation work, which has been my #1 bugbear with this damn system ever since I bought it. So...I for one am pretty happy with the 'don't treat it as a clickpad' solution :)
Comment 16 Peter Hutterer 2014-03-20 22:14:10 UTC
I've think shipping the below as quirk is the best we can do here. We don't have a CANTFIX, so I'm just claiming this fixed.

Section "InputClass"
        Identifier "Disable clickpad for CyPS/2 Cypress Trackpad"
        MatchProduct "CyPS/2 Cypress Trackpad"
        MatchDriver "synaptics"
        Option "ClickPad" "off"
EndSection
Comment 17 Adam Williamson 2014-03-20 22:28:35 UTC
Given the behaviour of the hardware, I think it's reasonable to consider that a fix, but I assume you can actually add such a quirk to the driver? Or are you saying we need to ship it as part of the X distribution in downstream distros or something?
Comment 18 Peter Hutterer 2014-03-20 22:44:46 UTC
We provide a default xorg.conf.d snippet with the driver that contains just such quirks. Distributions may use it or have their own, but this way it's documented (even though a make install won't actually install it).

http://patchwork.freedesktop.org/patch/22562/
Comment 19 Hans de Goede 2014-03-21 09:24:25 UTC
(In reply to comment #14)
> So we figured out what's causing a problem here: this particular trackpad is
> actually implementing soft buttons in firmware. When you watch it with
> evemu-record, the behaviour of the bottom area of the pad is very different
> from the rest.

Right, I already suspected it was doing something funky like this, hence my remarks about there possibly being a dead area at the bottom of the touchpad.

> In most of the pad, as soon as you touch the pad, it starts recording events
> - pressure, location, all that stuff.
> 
> In the 'firmware button area' (let's call it) - about the bottom 20% of the
> pad surface - just putting a finger on the pad generates no events. Even
> moving the finger a small amount generates no events. If you click in the
> bottom left of the pad, it generates a btn_left event, and *nothing else* -
> no location, no pressure, no movement even if your finger moves a little
> bit. If you click in the bottom right of the pad, it generates a btn_right
> event, and *nothing else*.

And there is the dead area I was suspecting. Great that you and Peter have figured this out!

> If I tell the driver the pad isn't a click pad - by setting the "Synaptics
> ClickPad" property to 0 - the left-click erraticness bug goes away, and I
> can still generate both left and right clicks, thanks to the pad's firmware.
> It may be a 'sufficient' fix just to have the driver not treat this
> particular bit of hardware as a clickpad. Let me know what information I
> should provide to help the driver precisely identify this hardware.

I agree that not treating this as a clickpad is the best solution.

However I'm not so sure that using a xorg.conf snippet for this is the best way to go about this, I would prefer to see a fix to the kernel to not report the clickpad flag for non clickpads. Esp. as some newer or future Cypress touchpads may very well get rid of the firmware mode and do everything in the drivers as other vendors do.

I'm going to post the same remark to the patch Peter has send for review to the Xorg devel list, and I suggest we discuss this further there.
Comment 20 Adam Williamson 2014-03-21 15:02:47 UTC
"And there is the dead area I was suspecting. Great that you and Peter have figured this out!"

Well, 'dead area' was a bad choice of words, then, at least for me. When you say 'dead area' I think 'area where nothing works', not 'area that acts like a soft button area'.


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.