"Add basic mouse pointer acceleration" libinput patch breaks make check

[Jonas Ådahl]

On Mon, May 26, 2014 at 03:34:46PM +1000, Peter Hutterer wrote:
> On Fri, May 23, 2014 at 05:27:25PM +0200, Jonas Ådahl wrote:
> > On Fri, May 23, 2014 at 04:03:56PM +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 05/23/2014 02:57 PM, Jonas Ådahl wrote:
> > > > On Fri, May 23, 2014 at 07:22:38AM -0500, Jason Ekstrand wrote:
> > > >> It might be better to reply to the patch.  This e-mail is liable to be
> > > >> forgotten if the patches sit for very long.
> > > >> --Jason Ekstrand
> > > >>
> > > > 
> > > > I did see it though and made a mental note about it, so I will look
> > > > into why it makes some test fail.
> > > 
> > > The tests in question seem to check for not only a certain type of event being
> > > reported, but also a certain value being reported, likely the changed accel makes
> > > the reported value different. Now the question is if we want to just fix the
> > > tests to work with the new accel, or maybe make the tests less prone to
> > > breaking ?
> > 
> > If the tests doesn't care about the actual acceleration, I'd say tests
> > should not assume input delta (x, y) means a known output delta (x', y').
> 
> indeed, though some range checking is usually quite useful to e.g. ensure
> at least input/output is within an expected range. that range may change
> over time, but having tests trigger early helps, annoying as it is.
> 
> looks like the event that triggers here has dx/dy both set to 0. which
> coincidentally is a bug we should fix :)

Indeed, but after fixing those, the issue is still that with
acceleration, the first input motion delta does not generate an output
delta. Sending two input motion deltas would however fix that and we
could then check that those have the same direction as the input. Sounds
good enough?

Jonas

> 
> Cheers,
>    Peter