[PATCH libinput 0/24] Tablet support

[Jason Gerecke]

On Tue, May 27, 2014 at 3:52 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Tue, May 27, 2014 at 01:11:31PM -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 :)
>>
>>
>> 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.
>
> good point, keeping the zero point is important.
>
>> 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).
>
> looking at linux/input.h, the axes where we should attach resolution in a
> defined unit (units/mm or radians) are:
> x/y/z, rx/ry/rz, distance, tilt x/y and their equivalents in the ABS_MT
> range. The kernel already does that anyway if the device supports it, we're
> just passing this on here. I'm not suggesting attaching a unit to e.g.
> ABS_RUDDER, who knows what that is :)
>
> so just in case this isn't clear what I'm suggesting is to export the range
> normalised in [LI_FIXED_MIN, LI_FIXED_MAX] or [0, LI_FIXED_MAX], with extra
> information to map min/max into a physical dimension if possible. which is
> what you're suggesting too afaict.
>
> Cheers,
>    Peter

Yeah, sounds like we're on the same page :)

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