[PATCH libinput 0/24] Tablet support

[Chandler Paul]

On Wed, 2014-05-28 at 08:20 +1000, Peter Hutterer wrote:
> On Tue, May 27, 2014 at 04:32:14PM -0400, Chandler Paul wrote:
> > On Tue, 2014-05-27 at 13:11 -0700, Jason Gerecke wrote:
> > > I've been away from my computer for most of the (long) weekend up
> > > here, so apologies for being a bit quiet :)
> > 
> > > There's a subtlety on the protocol side of things that can't be
> > > ignored. When normalizing data, you want to be careful to preserve
> > > information about the zero point. Without that, you can't meaningfully
> > > pass the data along. Lets imagine that we have some sensor that will
> > > report values between 10 and 100, with a resolution of 1 unit = 1
> > > elbow per square ounce. If we normalize that to the range [0,
> > > UINT32_MAX] we've lost information about where "zero" is. A normalized
> > > value of zero does not correspond to zero elbows per square ounce as
> > > you might expect, and the resolution info is insufficient to correct
> > > the offset.
> > > 
> > > Now, if we've done our jobs properly in libinput, that shouldn't be a
> > > problem. We would have normalized that sensor's values to [0.1, 1] and
> > > announced the axis to have a resolution of 1 unit = 100 elbows per
> > > square ounce. Because the zero point is offset like it originally was,
> > > it's preserved through the scaling done for the protocol and so the
> > > original 10-100 range can be recovered. The only amendment I'd make is
> > > to use a signed integer type rather than an unsigned one, since we may
> > > have negative normalized values that need to be sent through the
> > > protocol.
> > I just wrote code to normalize it to INT_MAX, but since everything's in
> > fixed point integers the actual values it's being scaled to are
> > 0-8388607.99609375 when the fixed point axis value is converted back
> > into a double, which as I'm sure you probably realize is kind of a
> > strange value, and I'm starting to think something like 0.1-1.0 would be
> > a lot better, trying to normalize to INT_MAX results in something that
> > sounds really weird to work with.
> 
> we need a LI_FIXED_MAX then. Normalising to 0-1 in a 24.8 fixed point only
> leaves us with 256 value per axis.
> 
> > Also, what exactly is a "zero-point" in this context?
> 
> whatever the neutral state of an axis is. e.g. tilt goes in both
> directions so the effective range is -value ... 0 ... +value.
> 
Yeah, I already mentioned this via query on IRC but I'll put it here for
the record.
The actual max integer that can be expressed in a li_fixed_t is
8388607.99609375, I've got a define for that in my local branch.
I've got the normalization working for this already, my only issue is
that I'm worried it's just kind of a weird value to work with. You
mentioned in query however that we could provide scaling functions. That
actually sounds like a pretty good solution I'll implement for the time
being.

> > > >> Seems fine to me. As for normalizing values to units/mm or the like, is
> > > >> there any known conversion for the units the tablet returns for distance
> > > >> to metric?
> > > >
> > > > Benjamin answered that on IRC, but for the archives: the distance is in mm,
> > > > though in reality the data is inprecise.
> > > >
> > > > Cheers,
> > > >    Peter
> > > >
> > > 
> > > I would avoid attaching units or resolution to axes which do not
> > > already declare them. The distance values on our pens do roughly
> > > correspond to millimeters from the sensor (which itself is usually a
> > > few mm below the surface) but we should be reporting a non-zero
> > > resolution through evdev if the data were reasonably accurate :D
> > > 
> > > Also, libinput shouldn't generally be "normalizing values to units/mm
> > > or the like." Data should be normalized to some range within [-1, 1]
> > > so that the zero point is preserved. Resolution data should be
> > > provided through another means which relates normalized values to
> > > real-world units (and should probably be documented to be zero if the
> > > resolution is unknown). The only exception to this /might/ be
> > > something like tilt or rotation (though the more I think about it, the
> > > less I believe it to be worthy of exception given how apps actually
> > > use the data).
> > Just to get an idea, how many applications do you think would actually
> > need to get the resolution information for the tablet?
> 
> well, we only need a one to make it a necessity to support this :)
I'll make sure to implement some calls for this too.
> 
> Cheers,
>    Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140527/ac4b8e53/attachment.sig>