[PATCH libinput 0/24] Tablet support

[Jason Gerecke]

I've been away from my computer for most of the (long) weekend up
here, so apologies for being a bit quiet :)


On Sun, May 25, 2014 at 7:13 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Fri, May 23, 2014 at 10:34:10PM -0400, Chandler Paul wrote:
>> On Fri, 2014-05-23 at 17:00 +1000, Peter Hutterer wrote:
>> > I'm almost sold on normalization since it does reduce the likelihood of
>> > things going wrong. We need to provide the axis resolution to convert back
>> > to the real data though where needed.
>> >
>> > once you provide the axis resolution, it doesn't matter if you provide raw
>> > data unless you also want to provide "raw" resolution, which is excessive..
>> >
>> > so, given that this would be sent down the protocol (and for the limited
>> > resolution) the range should be normalised to uint16_t or uint32_t max, with
>> > the resolution in units/mm or canonicalized where more appropriate. This
>> > would be what goes on the wayland protocol as well then.
>> >
>> > helper functions to convert that back to doubles, or elbows per square ounce
>> > would be part of the wl-client package that parses that protcol, not
>> > libinput.
>> >
>> > that doesn't seem like the worst architecture for both libinput and the
>> > protocol, any comments?
>>

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.

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

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....