Hi
I doubt that any physical input device uses the full 32 bit range. The idea
behind this check is more that if someone implements a uinput device and
decides to use the maximum range, passing their values straight through to
ui/input.c would cause weird behavior of the cursor. Exiting with a warning
here is supposed to make this easier to debug - in these cases, the person
implementing the input device can simply use a smaller range.
Aside from that, trying to change ui/input.c is probably a bad idea. The
code
there expects absolute input values to start at 0. To use the full 32 bits
of
an int would require absolute axes to have a different starting position.
This
would require large changes to ui/input.c and possibly also other code using
it. Also there's not much to gain, since we would probably still convert
values
into a range much smaller than 32 bits, as we do now.
Regards
-
Philippe
On Fri, May 5, 2017 at 10:39 AM Gerd Hoffmann <kra...@redhat.com> wrote:
> Hi,
>
> > This patch allows, for example, uinput to be used to create virtual
> > absolute input devices. This lets you build external systems which share
> > physical input devices between guests.
>
> Ah, interesting.
>
> > +static bool input_linux_abs_range_is_valid(int min, int max)
> > +{
> > + int64_t difference = ((int64_t) max) - ((int64_t) min);
> > + return difference > 0 && difference <= INT_MAX;
> > +}
>
> Does this happen in practice?
> If so we might consider improving ui/input.c instead.
>
> cheers,
> Gerd
>
>
