<div dir="ltr">On Thu, Jul 30, 2015 at 7:45 AM, Hans de Goede <span dir="ltr"><<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+    /* This device has a terrible 2fg resolution, but only for the<br>
+     * second finger, causing scroll jumps when we use the touch points<br>
+     * properly. The first finger resolution is accurate though, so<br>
+     * we simply pretend it's a single touch touchpad with the BTN_TOOL<br>
+     * bits.<br>
+     */<br>
</blockquote></blockquote>
<br></span>
This comment is wrong, the old-style st coordinates report accurate<br>
data where as the mt data reports inaccurate data for both fingers<br>
when 2 fingers are down. What is happening is that when a single finger<br>
is down the st data is copied over to the mt data slot 0, so as to<br>
have something to report to user-space which only listens to mt events,<br>
and as soon as a second finger comes down the driver starts reporting<br>
the bounding box limits in the mt data, making *both* slots inaccurate.<br>
<br>
So it is not "only for the second finger" nor is "The first finger<br>
resolution is accurate" really accurate to say :) The first finger as<br>
reported in the st events is accurate, the first finger reported in the<br>
mt events is still no good, otherwise we would not need this commit at<br>
all.<br></blockquote><div><br></div><div>So you are saying this device simultaneously sends accurate st events and "bad" mt events?<br><br></div><div>Do all devices simultaneously send st events and mt events? It would seem an easier fix is to just make what this patch does happen for *all* devices, rather than special-case. I would suspect the reason for this behaviour is that is the way the Windows driver works, and that copying the way that works will make more devices that are tested only on Windows work.<br></div></div></div></div>