<div dir="ltr">Hi, <br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 1:41 AM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span>On Mon, Nov 23, 2015 at 07:58:28PM +0100, Andreas Pokorny wrote:<br></span></div><span>
[...]</span><span><br></span><div><span>
> measured values on the e4.5 jumped a lot further. I need a more accurate<br>
> method for that. In the second round I will probably try to verify the<br>
> result with a finger-paint application.<br>
<br>
</span>that does not fill me with confidence. we can't expose an API where we say<br>
it's in mm when none of the devices have anything close to being usable.<br>
if this is what we see for most devices, we need to change the API into<br>
something less unreliable.<br> </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
First thought here is to normalize major/minor as well into a range where 1<br>
represents "normal touch". that makes scaling a lot easier when devices<br>
provide complete garbage and removes the pretense of accuracy.<br></div></blockquote><div><br></div><div>To some degree this is already happening inside the driver. It tries to rationalize the measured data by assuming a normal touch. Depending on the implementation extreme input attempts either get ignored or clamped or ... <br></div><div>On top of that it seems that power saving is part of the decision making, as small changes in covered area are not always reported.<br></div><div><br>After including smaller hands in the tests I am a bit more confident. There is a reproducible relation between finger size and reported size.<br></div>The specific problem with device the I complained about was that it only reports multiples of four, while the others dont.<br></div><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<span><br>
> On Mon, Nov 23, 2015 at 5:19 AM, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>><br>
> wrote:<br>
<br>
</span>well, we can use DMI information as well, that usually works well enough for<br>
touchpad devices. last option is a udev callout when we match specific<br>
system information, that callout can then dig into the device further. We do<br>
that for some touchpad firmware version already (see libinput-model-quirks).<br></div></blockquote><div><br></div><div>No dmi on those devices.. libhybris getprop would provide something close to that.<br></div><div>I could get the lacking resolution information from there. <br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<span><br>
> > - do you have client-side code that makes use of these properties yet? I'd<br>
> >   like to have a look at it.<br>
> ><br>
><br>
> We do use that information in the mirclient backend of qt. Not sure if qt<br>
> uses the information for anytihing internally - but it is available to<br>
> applications.<br>
> I mainly test with a plain-mir demo application called<br>
> mir_client_fingerpaint .<br>
<br>
</span>do you have the source available somewhere?<br></div></blockquote><div><br></div></div><a href="http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/fingerpaint.c">http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/fingerpaint.c</a><br><br></div><div class="gmail_extra">regards<br></div><div class="gmail_extra">Andreas<br></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div>