On Tue, 2014-05-27 at 23:32 -0400, Chandler Paul wrote: > On Wed, 2014-05-28 at 12:48 +1000, Peter Hutterer wrote: > > On Tue, May 27, 2014 at 03:40:07PM -0700, Jason Gerecke wrote: > > > On Tue, May 27, 2014 at 3:20 PM, Peter Hutterer > > > <[email protected]> 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. > I've already implemented scaling to LI_FIXED_MAX in my tree, but I agree > this is something we should probably try to avoid. My thought here is > that we could scale it to a smaller value that's extremely unlikely to > ever overflow. My idea is to scale it to a 16.8 bit value. I don't think > it's likely that we'll ever be encountering anything larger then a 16 > bit value with a wacom tablet. This does kind of seem like a bit of a > hack though. > > > > > >> 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. > I don't think there's any devices like that right now, but if there are > it might be better just to pass the value to the client as-is without > normalizing it like we do with the pressure axis. Correction, I meant to say "like we do with the distance axis" > > > > Cheers, > > Peter >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
