[PATCH libinput 0/24] Tablet support

[Jason Gerecke]

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

>> > >> 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 :)
>
> Cheers,
>    Peter