[PATCH libinput 0/24] Tablet support

[Peter Hutterer]

On Fri, May 30, 2014 at 11:18:08AM -0700, Jason Gerecke wrote:
> 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?

libinput doesn't communicate over the wire, li_fixed_t is a leftover from
libinput being part of weston. Switching that to double would indeed make
things a lot easier and decouple libinput from wl-protocol-specific things.

I'd be all up for it, though it'd be a bit of an API change that we'd have
to fix in the callers.

Cheers,
   Peter