Bug 76341

just in case: you have the latest libevdev installed? 1.1RC1 or later?

libevdev-1.0.99.1-1.fc21.x86_64

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.

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.

Created attachment 96025 [details]
Xorg.0.log from affected system

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.

Created attachment 96077 [details]
evemu recording - three failed clicks and a click+move

Created attachment 96079 [details]
evemu recording - cursor jump

(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.

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.

(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.

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.

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.

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.

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 :)

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

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?

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/

(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.

"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'.