Description of problem: When moving the mouse slowly, such as when doing fine movements to select individual pixels, it often moves more than one pixel at a time, no matter how slowly you move the mouse. Version-Release number of selected component (if applicable): libinput-0.17.0-1.fc22.x86_64 How reproducible: Always. Steps to Reproduce: 1. Use a 400dpi mouse. In my case, a Logitech M-BJ69 model. You should see MOUSE_DPI=400@125 in the "udevadm info /dev/input/event3" output (substitute your appropriate eventN device). 2. Have mouse-dpi-tool running in one window, and GIMP in another with a photo at 100% zoom and the rectangle selection tool active. 3. Move mouse sideways slowly while selecting a rectangle. 4. Notice how at every mouse position change registered by mouse-dpi-tool, the cursor moves at the same time, but sometimes by 2 pixels (visual and the GIMP status bar shows the selection rectangle size numbers changing by 2 rather than 1). Actual results: Periodically skips a pixel. Expected results: Want to be able to move the mouse through every pixel when moving slowly. Additional info: See also bug #1227039 for a discussion. A higher DPI mouse can get to all pixels, but I expect there will be some unevenness in the movement due to aliasing between the mouse DPI and the virtual 1000DPI used by the system. I suggest throwing out the scaling factors at slow speeds and moving the mouse one pixel at every input change. Though for noisy inputs on super high resolution mice (if that's a problem), maybe have a minimum distance, say 1/500 inch (so 400 DPI mice work) before movement is registered.
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.