[PATCH libinput v9 0/2] add orientation, size and pressure of touch

[Peter Hutterer]

On Wed, Nov 25, 2015 at 03:30:58PM +0100, Andreas Pokorny wrote:
> Hi,
> 
> On Tue, Nov 24, 2015 at 1:41 AM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> 
> > On Mon, Nov 23, 2015 at 07:58:28PM +0100, Andreas Pokorny wrote:
> > [...]
> > > measured values on the e4.5 jumped a lot further. I need a more accurate
> > > method for that. In the second round I will probably try to verify the
> > > result with a finger-paint application.
> >
> > that does not fill me with confidence. we can't expose an API where we say
> > it's in mm when none of the devices have anything close to being usable.
> > if this is what we see for most devices, we need to change the API into
> > something less unreliable.
> >
> >
> 
> > First thought here is to normalize major/minor as well into a range where 1
> > represents "normal touch". that makes scaling a lot easier when devices
> > provide complete garbage and removes the pretense of accuracy.
> >
> 
> 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 ...
> 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.
> 
> After including smaller hands in the tests I am a bit more confident. There
> is a reproducible relation between finger size and reported size.
> The specific problem with device the I complained about was that it only
> reports multiples of four, while the others dont.

all these are a problem. we need to figure out how to normalize the data in
a sensible manner, I won't have libinput pass broken information to the
caller to let them deal with it. That's what we do in X and it is terrible.

This means either we find a way to interpret the data in libinput correctly,
figure out a way to fix devices on the fly, or ignore devices that don't
give us useful data.

 
> > > On Mon, Nov 23, 2015 at 5:19 AM, Peter Hutterer <
> > peter.hutterer at who-t.net>
> > > wrote:
> >
> > well, we can use DMI information as well, that usually works well enough
> > for
> > touchpad devices. last option is a udev callout when we match specific
> > system information, that callout can then dig into the device further. We
> > do
> > that for some touchpad firmware version already (see
> > libinput-model-quirks).
> >
> 
> No dmi on those devices.. libhybris getprop would provide something close
> to that.
> I could get the lacking resolution information from there.
> 
> 
> 
> > > > - do you have client-side code that makes use of these properties yet?
> > I'd
> > > >   like to have a look at it.
> > > >
> > >
> > > We do use that information in the mirclient backend of qt. Not sure if qt
> > > uses the information for anytihing internally - but it is available to
> > > applications.
> > > I mainly test with a plain-mir demo application called
> > > mir_client_fingerpaint .
> >
> > do you have the source available somewhere?
> >
> 
> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/fingerpaint.c

this isn't the code that hooks onto the libinput backend though. similar
API, but still not an actual user of this new API.

the bigger issue is the use of the major/minor. you're taking the value and
if it's bigger than the magic value 5, you're using it. The magic number has
no meaning, afaict. So this will run into the problems above, if you run it
on a device with a weird range, it won't work as expected.

Cheers,
   Peter