[PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice

[Peter Hutterer]

On Tue, Nov 04, 2014 at 09:00:06AM -0600, Derek Foreman wrote:
> On 03/11/14 09:51 PM, Peter Hutterer wrote:
> > On Mon, Nov 03, 2014 at 11:56:59AM +0100, David Herrmann wrote:
> >> Hi
> >>
> >> On Fri, Oct 31, 2014 at 5:33 AM, Peter Hutterer
> >> <peter.hutterer at who-t.net> wrote:
> >>> On Thu, Oct 30, 2014 at 04:34:12PM -0500, Derek Foreman wrote:
> >>>> The acceleration filter currently isn't particularly pleased with gaming mice.
> >>>>
> >>>> They generally have high DPI (can be over 8000 DPI) and can have high update
> >>>> rates (1000+ per second).  This can result in the accel curve being biased
> >>>> heavily towards the high points on the accel curve.
> >>>>
> >>>> This patch set allows a way to normalize the deltas to 400DPI so when the
> >>>> DPI setting of the mouse is correct, it should feel much the same as a
> >>>> normal mouse.
> >>>>
> >>>> This is, of course, only a partial solution.  Setting a reasonable default
> >>>> is a massive problem that needs to be addressed in the future - for now
> >>>> we just set it to 400 (which may actually not be that prevalent any more
> >>>> but there doesn't seem to be such thing as a "standard" DPI mouse).
> >>>
> >>> Thanks, I've pushed 1 to 3 (with added comments), not quite happy with
> >>> 4 yet. As a configuration interface, it's mismatched with the usual quartett
> >>> of hooks that we provide for all other config options.
> >>>
> >>> But I think providing a visible API may not be the right approach here
> >>> anyway. One idea I had here was to have this provided through udev, set
> >>> as something like:
> >>>     LIBINPUT_MOUSE_DPI="400 at 80" # dpi @ poll rate
> >>>
> >>> over time, the udev hwdb could add those settings, or we ship them as
> >>> extra rules, or users configure them themselves. this is unfortunately a
> >>> rather nasty task given the amount of HW out there, but I really can't think
> >>> of any other way (short of heuristics which will fail in too many ways).
> >>>
> >>> Any ideas on feasability or better approaches welcome.
> >>
> >> hwdb can be used easily here, but it's indeed a huge amount to gather
> >> all that data. HID doesn't have a way to query this information,
> >> sadly, and I haven't found any generic vendor extensions (maybe
> >> Benjamin knows more).
> >>
> >> We could use the REL_X/REL_Y MAX values to guess the DPI setting and
> >> ignore it if it's out of the expected range (sth. like 100-10k).
> >>
> >> I haven't spent much time thinking it through, but so far I'd prefer a
> >> solid, but basic, heuristic to guess the DPI and then use hwdb for
> >> anything that doesn't fit. This allows us to change the heuristic at
> >> any time and we don't have to introduce any APIs. We can even ship the
> >> hwdb files with libinput.
> > 
> > tbh, I don't think heuristics will work. there is no reference point and
> > when you're looking at relative motion you can't tell if a delta of
> > 10 means the pointer has moved a large distance at low-res or a small
> > distance at high-res.
> >  
> > Anyway, for some data:
> > I recorded my Logitech G500s here with three different dpi settings (400,
> > 800, 2000) and a MS Comfort Optical Mouse 3000 (1000 dpi). A couple of
> > interesting things: regardless of dpi, virtually all events are within [-3,
> > +3] dx/dy and there's nothing over 10. Exception here is the MS mouse which
> > goes up to 78 for a delta, for reasons I can't explain yet.
> 
> Poll rate?  Your Logitech G500s is a Ridiculous Gaming Mouse(TM) with a
> 1000Hz report rate - I suspect the Microsoft mouse is 125Hz - have you
> looked at the time deltas?

Yeah, I suspected as much yesterday but hadn't checked yet. This time with
actual data:
Average delta in µs between two events is 2776.79, 3347.15, 3511.00 for the
G500 recordings (dpi 2000, 400, 800). The MS mouse has 9975.60 µs on
average.

Deltas taken between SYN_REPORT, with all deltas > 50ms dropped for noise
reduction (it was normal desktop usage after all, with many pauses).
Given the remaining noise, that looks close enough to 125Hz on the MS mouse,
and 500Hz on the G500 (which is what the OS X software claims it is set to)

I still think that deltas of 78 seem a bit high, but it's hard to remember
what triggered this (accidental bump of the mouse maybe)

> Unsurprisingly it looks like my results with a mouse set to 1800DPI,
> 1000Hz polling are very similar to your 2000DPI log with no events with
> a delta higher than 11.  I haven't created a nice histogram though.
> 
> This mouse can also be set to 125Hz, where it generates proportionally
> larger deltas.
> 
> We could probably figure out the poll rate heuristically, but I think
> that's useless information since timestamps are already taken into
> account in the acceleration filter.

I agree. It'd be nice to know but not sure what to do with it.

Cheers,
   Peter