<div dir="ltr">On Tue, Jun 30, 2015 at 11:08 PM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Not all touchpads provide x/y axis resolution. some of them (apple<br>
touchpads) we fix up in the systemd hwdb but others are harder to detect or<br>
fix in a generic manner. so we set a fake resolution (1 unit/mm), but that's<br>
just to avoid divide-by-zero.<br>
<br>
the touchpad code handles physical distances where possible but always has<br>
an escape path to handle the resolution-less touchpads, most of that by some<br>
magic numbers or percentages but those may or may not be correct. especially<br>
on the touchpads we don't have available for testing we have no idea how<br>
close the behaviour is to the intended one.<br>
<br>
this patchset does away with the fake resolution handling. a udev callout<br>
checks for the firmware version and assigns a tag based on that, the hwdb we<br>
ship then assigns size hints for the device. anything that doesn't get a<br>
size hint is simply set to a default size.<br>
this may make some touchpads worse in the short term, but long term we<br>
should be able to narrow down the various sizes and provide hwdb entries for<br>
them - and get the same behaviour across devices.<br>
<br>
Note that the hwdb entries are just approximates so far, the ALPS fw version<br>
8 is a measurement of such a device, everything else is just assumption or<br>
blind guesses. I'll try to collect some real-world sizes before pushing<br>
this if we're happy with this approach.<br>
<br>
1/9 and 2/9 are independent and can go in regardless.<br></blockquote><div><br></div><div>Looks correct to me.<br><br></div><div>I hope my attempt to do this was helpful, but this approach where it can get the size from the database is much better.<br></div></div></div></div>