[PATCH libinput 0/24] Tablet support

[Chandler Paul]

On Tue, 2014-05-27 at 15:40 -0700, Jason Gerecke wrote:
> On Tue, May 27, 2014 at 3:20 PM, Peter Hutterer
> <peter.hutterer at who-t.net> 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.
> >
> Yeah, we don't want to pass a value like that through the fixed type.
> It either needs to be re-scaled to use the full range (be that
> [INT_MIN, INT_MAX] or [FIXED_MIN, FIXED_MAX]) or sent with a type that
> won't loose quite as many bits :D
> 
> >> 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.
> >
> Or as I like to think about it, the point where an axis would report a
> value of "0". Most axes will report that value, and you'll just want
> to be sure that an input of 0 turns into an output of 0. There's a
> corner case where 0 could be outside the range of the axis, but if you
> treat it as though it could you'll end up mapping the range
> appropriately (e.g. treating an axis that only reports [10, 100] as
> though it really reported [0, 100] will result in proper
> normalization).
> 

Alright, I'll normalize the pressure axis to use the full range from 0
to LI_FIXED_MAX, and the tilt axis to -(LI_FIXED_max), and leave the
distance axis as-is.

Cheers,
	Lyude
-------------- 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/aad1d1f0/attachment.sig>