<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Two finger scrolling isn't smooth" href="https://bugs.freedesktop.org/show_bug.cgi?id=89683#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Two finger scrolling isn't smooth" href="https://bugs.freedesktop.org/show_bug.cgi?id=89683">bug 89683</a> from <a class="email" href="mailto:jwrdegoede@fedoraproject.org" title="Hans de Goede <jwrdegoede@fedoraproject.org>"> Hans de Goede</a> <pre>Hi Velimir and Peter, I've been looking into this today, mostly looking at the alps kernel code / the alps ps2 protocol. This problem affects alps v3 - v5 devices. Including the Rushmore (v3) touchpad on my Dell Latitude. As well as the Dolphin (v5) touchpad on Velimir's inspiron. The interesting thing is that both touchpads give us the same raw data at the ps/2 level (in slightly different formats): 1 more or less accurate touch, and a bitmap with columns and rows in which 1 or more fingers are seen resuting in a crude (low res) bounding box, but the kernel uses 2 different strategies for translating this into touch data. The kernel code for v3 and v4 tablets simply takes 2 corners of the bounding box and reports those as touch1 and touch2, resulting in 2 touches with a crude resolution, but non of the "interesting" moving back / forth (saw tooth pattern) coordinates for the second touch. The kernel code for v5 tablets takes the single accurate touch info, and calculates the distance to the center of the bounding box, and then puts the 2nd touch mirrored to the center. Since when the fingers only move a bit the bounding box does not move at all (because it has a low resolution) this results in one touch's coordinates moving up and the other moving down, resulting in the saw tooth pattern we are seeing on Velimir's inspiron. Neither strategy is really good, the v3-v4 strategy throws away the accurate touch info we've for the first touch down, the v5 strategy has accurate touch info in touch1, but touch2 does the saw tooth pattern thing. One thing we can do is stop using the "pointer emulation" code for mt devices in the kernel for these devices and report the accurate touch data for the first touch through ABS_X and ABS_Y events, while reporting the crude coordinates from the v3 and v4 strategy in ABS_MT_POSITION events. This way userspace has all info and can act on it. Alternatively we can do a mix between the 2 strategies where we always use the accurate coordinates for touch1 and when a 2 touch sequence starts find which corner is closest to the accurate coordinate and use the crude coordinates of the opposite corner for touch2 for the duration of the 2 touch sequence (we cannot pick the corner each event because that will result in weird jumps when the fingers are close together). Either way will also need some libinput adjustments, and either way will make 2 fg scrolling on v3 / v4 devices much better with synaptics directly because synaptics uses the ABS_X and ABS_Y events which will now be accurate on v3 / v4 devices just like they already are on v5 devices. Peter, which solution do you think is best ? Regards, Hans</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>