On Wed, May 28, 2014 at 11:07:52AM -0700, Bill Spitzak wrote: > I'm not clear on why there is an attempt to use FIXED for the data rather > than an integer. The binary result is identical, but I think it is a lot > easier and clearer to say that the numbers range from -2147483647 to > +2147483647 (or -0x7fffffff to 0x7fffffff).
all our coordinates are in li_fixed_t. Given that the compiler won't help if you treat them like an int, I really don't want to start mixing them to avoid bugs in the caller. Cheers, Peter > It seems like the following information must be sent: > > 1. The "normalized" value as described in most of this, though I would > prefer to describe it as a 32-bit integer rather than a fixed-point format. > The largest absolute value the device can produce is mapped to 2147483647 > (thus -2147483648 cannot be produced). The "zero" value is mapped to zero. > The reason for using the normalized value is that it is the only one a > client can actually use without referring to the other values. > > 2. The "range" in units. This is two numbers showing the bottom and top end, > probably in fixed format. This provides useful information to a client even > if it does not know what the units are: client can figure out the full range > in normalized space of the device: take the largest absolute value and scale > that to 214748647. Then multiply the range by the same scale and you will > have the range in normalized space. This is necessary for a client to know > if the device is at a stop. > > 3. The "resolution". I think this is best given as the number of steps that > cover the range, as an integer. With this information, and provided there > are less than 2^31 steps, the client can recover and distinguish exactly the > position of the device. If the resolution is less than 2^23 then the exact > position can be recovered using 32-bit floats. > > The units have to be chosen to be linear with the device steps, so they may > in fact be sqrt(elbows/inch) or even a more complex piece-wise function. > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
