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

[Derek Foreman]

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?

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.