Bug 1231304
| Summary: | Mouse skips pixels at slow speeds | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander G. M. Smith <agmsmith> |
| Component: | libinput | Assignee: | Peter Hutterer <peter.hutterer> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | agmsmith, jadahl, kadir, peter.hutterer |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libinput-0.18.0-4.fc22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-07-02 17:08:58 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1227039 | ||
|
Description
Alexander G. M. Smith
2015-06-12 15:41:19 UTC
Oops, wrong versions, libinput-0.17.0-1.fc22.x86_64 works fine, it's the test ones like libinput-0.17.0-2.3.fc22.x86_64 which have the problem of skipped pixels. Right, reproduced it here and the cause is relatively simple. We assume a 1000dpi mouse as default, so the minimum delta the device sends is 1. With the acceleration test builds we have a constant acceleration of 1 for slow motion. Your mouse is a 400dpi mouse but we normalize to 1000dpi. http://wayland.freedesktop.org/libinput/doc/latest/motion_normalization.html so when your mouse sends a delta 1 it is normalized to 2.5 units (1000/400) and comes out as a 2.5 pixel movement. That is technically correct, your mouse moved the same as a 1000dpi mouse would've moved in 2.5 units but wrong in all other ways :) This problem was masked before by the adaptive deceleration, those slow movements would cause deceleration and thus mask the pixel skipping. Need to figure out a fix how to fix this properly. here's a first attempt, but it's going to generate some hatemail if we push it out http://koji.fedoraproject.org/koji/taskinfo?taskID=10163767 rather than normalizing to 1000dpi the accel code uses a 200dpi baseline (ignore touchpads in this build). That guarantees that 1 device unit from such a mouse generates a 1 pixel movement by default. Compared to the current code this slows the pointer down quite a fair bit. I've changed the accel curve to kick in sooner and longer to avoid that a bit. It's a bit of a shock though at first, test it a for a while before you pass judgement on that :) It also doesn't have adaptive deceleration anymore, so slow movements represent physical movement. Comments appreciated. Silky smooth. Pixel precise moves are easy. Had to crank up the acceleration in the GNOME control panel to max, otherwise crossing the screen takes a while. Usable without problems after a few minutes of getting used to it. Though would the extra hand movement distance benefit the users with exercise or harm them with carpal tunnel damage? :-) Peter, I also tested this build. I have used this build for a while (on my 1000 dpi mouse). And to be honest, this build is completely unusable for me. It is very sluggish, even at the highest speed setting. I physically need to move the mouse alot. I fear that this build will also cause unnecessary strain of the hand. Is there a way that users maybe can switch between accel curves based on a hwdb entry? So a 1000dpi or more mouse can use for example the build that you made in bug #1227039 (libinput-0.17.0-2.3.fc22.x86_64.rpm) and a user with a 200/400 dpi mouse can use another accel curve. I don't know if this is possible. Like I said, I really got used to libinput-0.17.0-2.3.fc22.x86_64.rpm, mouse movements are (for me at least) absolutely perfect with that build. (In reply to Kadir from comment #5) > I have used this build for a while (on my 1000 dpi mouse). > And to be honest, this build is completely unusable for me. It is very > sluggish, even at the highest speed setting. I physically need to move the > mouse alot. I fear that this build will also cause unnecessary strain of the > hand. fair enough, thanks heaps for testing. > Is there a way that users maybe can switch between accel curves based on a > hwdb entry? So a 1000dpi or more mouse can use for example the build that > you made in bug #1227039 (libinput-0.17.0-2.3.fc22.x86_64.rpm) and a user > with a 200/400 dpi mouse can use another accel curve. I don't know if this > is possible. libinput has that facility anyway, but it's not something I'd want to expose to the users. We can have different acceleration profiles depending on the hardware (we already have that anyway). So if I can't find a better match that works for both we'll have to go that way. Not the final version, but tell me whether I'm on the right track here: http://koji.fedoraproject.org/koji/taskinfo?taskID=10186410 For the archives, positive feedback on that build reported in Bug 1227039#c45 libinput-0.18.0-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.18.0-4.fc22 Package libinput-0.18.0-4.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libinput-0.18.0-4.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10863/libinput-0.18.0-4.fc22 then log in and leave karma (feedback). libinput-0.18.0-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |