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 >> <[email protected]> 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@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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
