[PATCH libinput 0/24] Tablet support

[Peter Hutterer]

On Tue, May 27, 2014 at 03:40:07PM -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

didn't think of it until after I sent the previous email:

there's a side-effect that we need to be aware of: if we scale an axis to
LI_FIXED_MAX, we're effectively guaranteed to get 32-bit integer overflows
on operations with that value. So we're effectively forcing the caller to
work with int64_t to be on the safe side.

which isn't the worst of all things: on fixed 24.8 with current devices
overflows aren't _that_ hard to trigger so we pretty much get to pick
whether they happen sometimes for some devices or all the time, effectively
forcing all callers to handle this correctly from day 1.

> >> 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).

new question: what about a device that has an zero state that's not halfway
between min/max? currently it'd advertise a range of [-N, M]. normalising
those means we lose that information.
 
Cheers,
   Peter