[PATCH libinput 0/24] Tablet support

[Jason Gerecke]

On Thu, May 29, 2014 at 11:45 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> On 29 May 2014 18:54, Jason Gerecke <killertofu at gmail.com> wrote:
>>
>> If that's the case though, I have to ask -- *why* on Earth is
>> 'li_fixed_t' even being considered as libinput's output type? I know
>> I'm missing something because the thought seems like such a blindingly
>> terrible choice. Its not an intrinsic type, is ill-suited to the task
>> of representing normalized data, and can't be directly used without
>> very real overflow concerns. By contrast 'float' is a standard type
>> which takes up the same space, offers sufficient precision of
>> normalized data, and can be freely operated on without concern. Is
>> there some crazy reason that floats aren't viable as the output type?
>> Are we communicating over the Wayland protocol despite being a
>> library? Targeting hardware with no FPU? libinput seems like it could
>> be useful to more than just Wayland compositors, so I _really_ hope
>> the reason isn't to maximize the degree of integration between the
>> two.
>
>
> Both Wayland and X11 use fixed-point types over the wire.  Obviously none of
> this is driven by no-FPU, because even on ARM that isn't a thing.

But why should libinput care about that fact? Does it communicate over
the wire itself? If not, then why wouldn't defining the API to return
a normalized 'float' or 'double' be more appropriate? If Qt, EFL, or
Android decided to replace the code they currently have for gathering
and filtering events from evdev with libinput, do you think they'd
honestly prefer to be handed full-range rather than normalized data?

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