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

[David Herrmann]

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.

Thanks
David