> Hmm, it seems the new input code in 0.18 might be causing a lot of the new
> test failures, not to mention is annoying to use in practice (mouse
> acceleration too high). Maybe we should consider fixing that up before
> releasing...
I suggest we analyse the test failures. Those are btw not related to libinput or pointer acceleration. Since those test cases use the input-stub to simulate input events. This is the case for a few of releases. Acceleration or rather device configuration on input-stub can be tested, but the acceleration is disabled by default. The code used there just scales relative movement with a single factor which is 1.0 by default. So the cause for the failure might be somewhere else.
> Hmm, it seems the new input code in 0.18 might be causing a lot of the new
> test failures, not to mention is annoying to use in practice (mouse
> acceleration too high). Maybe we should consider fixing that up before
> releasing...
I suggest we analyse the test failures. Those are btw not related to libinput or pointer acceleration. Since those test cases use the input-stub to simulate input events. This is the case for a few of releases. Acceleration or rather device configuration on input-stub can be tested, but the acceleration is disabled by default. The code used there just scales relative movement with a single factor which is 1.0 by default. So the cause for the failure might be somewhere else.
> /bugs.launchpad .net/mir/ +bugs?field. tag=pointer- events
> https:/
>
> It's possible that simply killing the acceleration that's been introduced will
> solve all of them at once.
And that would reopen: /bugs.launchpad .net/mir/ +bug/1517133
https:/