[PATCH libinput 0/24] Tablet support

[Peter Hutterer]

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