Bug 43591

After a bit of investigation I have found that two finger scrolling and two finger tapping interfere with each other. ie, if you disable one, the other works as expected.

The kernel does not process scrolling and tapping gestures, it simply emits stream of coordinates and it is responsibility of X driver to parse and interpret them. You should report this issue to xf86-input-synaptics.

Thanks.

I will do so, however I do believe that the issue is with the driver, since this issue seems specific to my Sentelic touchpad and wasn't an issue with the Saaros patch.

https://bugs.freedesktop.org/show_bug.cgi?id=51403

As I had the same problem, I investigated and fixed the problem.
Other mouse drivers such as elentec always send both touch point together, while the sentelic send them one by one.

I created a patch: https://lkml.org/lkml/2012/6/27/521

Thanks Olivier. Dmitry, are you happy to accept this bug as "two finger tapping doesn't work" or should I create a new item?

Once again, the issue seems to be in the X driver: if the protocol is defined such that it is acceptable to send only new data in the event packet (MT-B protocol) then the driver should handle that. The fact that the other drivers might sent data differently does not matter; also, input core will attempt filter out duplicate events when dealing with MT-B devices.

Of course there still may be issue in the kernel driver, but then your (Olivier's) description of the issue is not correct/complete.

I have this issue on my Sentelic touchpad too. I'm sorry I created a duplicate of this bug. You can declare #51611 as a duplicate of this.

I also made a patch to fix it, you can get the patch at http://sentelic.pkbd.org. 

What happens is that the Sentelic kernel driver sends coordinates to the synaptics xorg driver without reworking the x and y absolute coordinates. This confuses the synaptics driver, horizontal two-finger scrolling is non-functional, vertical two-finger scrolling lacks smoothness.

The Synaptics kernel driver reworks x and y coordinates before sending them to the synaptics xorg driver. The first finger reported by the kernel is reported with x and y coordinates which are the min of the actual physical x and y coordinates of the user's two fingers. The reported second finger is the max of both physical fingers of the user. Apparently this is what the synaptics xorg driver needs to handle them properly.

On the other hand you don't need to report both fingers every time you report mt events. You can fix the bug simply by having the Sentelic kernel driver report min and max virtual fingers like the synaptics kernel driver does.

2 important considerations: 

1) I have not yet studied the code for the synaptics xorg driver. However, I suspect attempts to solve the issue in this driver for Sentelic touchpads will result in breaking the behavior of devices handled by the synaptics kernel driver.

2) Please note that, practically speaking, the MT-B protocol is totally irrelevant to the resolution of this bug using the approach I propose. The reason is that whatever events of the type ABS_MT_POSITION are reported by the Sentelic kernel driver are utterly ignored. What actually moves the cursor of multitouch Sentelic touchpads are plain and simple ABS_X and ABS_Y events, totally unrelated to the MT protocol. For consistency, my proposed patch alters both MT protocol events and regular absolute position events in the same way. However, should you change only the way ABS_X and ABS_Y events are reported, you'd get the same result.

Created attachment 89191 [details]
Patch working against 3.6 and 3.7

@Cristophe   I tried your patch. While it improves scrilling, it is still not working with double tap to simulate middle click.

I think the real issue is that we report the fingers one by one rather than together like other drivers do.

I submitted a patch long time ago already but it was not accepted upstream because they claim it is a userspace bug.  But I still think it deserve a workaround, because scrolling and middle-click just do not work currently.

I attached an updated version of my patch.

Created attachment 89261 [details]
patch: fix buggy aboslute position events in sentelic.c

Thanks for your feedback Olivier. Care to tell me what version is your touchpad?

I just tried your patch, and I confirm that it does bring the extra fix you claim it does, which makes it indeed better than mine. Alas, it has been refused, not on the basis that it does not respect the MT-B protocol, but on the basis that it does not respect the protocol more than existing code... which somehow makes any fixes and improved consistency in dealings with userspace irrelevant... if I follow well.

What I'm going to do, I'm going to submit a new version of my patch,which will be completely void of any impact on MT events, and therefore totally orthogonal to the MT protocol, and hope that we hear word from the maintainer.

As for describing the issue, the driver is buggy in that it reports non-MT absolute position events associated to the coordinates of each of 2 fingers alternatively, a situation which no sane userspace program can be expected to handle. My patch fixes that by having a unique and consistent virtual finger be reported by these events, and therefore constitutes an obvious bug fix.

Although we are probably wasting our time, since we should be fixing the "bug" of the xorg driver, and then we should be asking the guy who owns a touchpad from each and every vendor to check that we didn't break any non-Sentelic touchpad.

(In reply to comment #2)
> The kernel does not process scrolling and tapping gestures, it simply emits
> stream of coordinates and it is responsibility of X driver to parse and
> interpret them. You should report this issue to xf86-input-synaptics.
> 
> Thanks.

The Sentelic driver indeed reports tapping gestures. It reports one-finger AND two-finger tappings as left clicks.

You can find an updated and much simpler version of my patch, with the same effect, at this address:

https://lkml.org/lkml/2012/12/19/402