<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 May 2014 18:54, Jason Gerecke <span dir="ltr"><<a href="mailto:killertofu@gmail.com" target="_blank">killertofu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If that's the case though, I have to ask -- *why* on Earth is<br>
'li_fixed_t' even being considered as libinput's output type? I know<br>
I'm missing something because the thought seems like such a blindingly<br>
terrible choice. Its not an intrinsic type, is ill-suited to the task<br>
of representing normalized data, and can't be directly used without<br>
very real overflow concerns. By contrast 'float' is a standard type<br>
which takes up the same space, offers sufficient precision of<br>
normalized data, and can be freely operated on without concern. Is<br>
there some crazy reason that floats aren't viable as the output type?<br>
Are we communicating over the Wayland protocol despite being a<br>
library? Targeting hardware with no FPU? libinput seems like it could<br>
be useful to more than just Wayland compositors, so I _really_ hope<br>
the reason isn't to maximize the degree of integration between the<br>
two.</blockquote><div><br></div><div>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.</div></div></div></div>