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. Also, what exactly is a "zero-point" in this context? > > >> 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? > > 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....
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel