| Summary: | Logitech M500 behavior | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Paviluf <jeremy9856> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, dudlx, elreydetodo, peter.hutterer, wayland-bugs |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Paviluf
2016-05-26 14:46:53 UTC
(In reply to Paviluf from comment #0) Netrunner 14.2 based on Kubuntu 14.04 with synaptics driver I guess I meant the default X driver. Synaptics is for the touchpads I think. I don't know if it help but here is the output of xinput list-props 8 Fedora: Device 'Logitech USB Laser Mouse': Device Enabled (149): 1 Coordinate Transformation Matrix (151): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Accel Speed (285): 0.000000 libinput Accel Speed Default (286): 0.000000 libinput Accel Profiles Available (287): 1, 1 libinput Accel Profile Enabled (288): 1, 0 libinput Accel Profile Enabled Default (289): 1, 0 libinput Natural Scrolling Enabled (290): 0 libinput Natural Scrolling Enabled Default (291): 0 libinput Send Events Modes Available (269): 1, 0 libinput Send Events Mode Enabled (270): 0, 0 libinput Send Events Mode Enabled Default (271): 0, 0 libinput Left Handed Enabled (292): 0 libinput Left Handed Enabled Default (293): 0 libinput Scroll Methods Available (294): 0, 0, 1 libinput Scroll Method Enabled (295): 0, 0, 0 libinput Scroll Method Enabled Default (296): 0, 0, 0 libinput Button Scrolling Button (297): 2 libinput Button Scrolling Button Default (298): 274 libinput Middle Emulation Enabled (299): 0 libinput Middle Emulation Enabled Default (300): 0 Device Node (272): "/dev/input/event2" Device Product ID (273): 1133, 49257 libinput Drag Lock Buttons (301): <no items> libinput Horizonal Scroll Enabled (274): 1 Netrunner: Device 'Logitech USB Laser Mouse': Device Enabled (152): 1 Coordinate Transformation Matrix (154): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (282): 0 Device Accel Constant Deceleration (283): 1.000000 Device Accel Adaptive Deceleration (284): 1.000000 Device Accel Velocity Scaling (285): 10.000000 Device Product ID (271): 1133, 49257 Device Node (272): "/dev/input/event2" Evdev Axis Inversion (286): 0, 0 Evdev Axes Swap (288): 0 Axis Labels (289): "Rel X" (162), "Rel Y" (163), "Rel Horiz Wheel" (280), "Rel Vert Wheel" (281) Button Labels (290): "Button Left" (155), "Button Middle" (156), "Button Right" (157), "Button Wheel Up" (158), "Button Wheel Down" (159), "Button Horiz Wheel Left" (160), "Button Horiz Wheel Right" (161), "Button Side" (275), "Button Extra" (276), "Button Forward" (277), "Button Back" (278), "Button Task" (279), "Button Unknown" (274), "Button Unknown" (274), "Button Unknown" (274), "Button Unknown" (274) Evdev Scrolling Distance (291): 1, 1, 1 Evdev Middle Button Emulation (292): 0 Evdev Middle Button Timeout (293): 50 Evdev Third Button Emulation (294): 0 Evdev Third Button Emulation Timeout (295): 1000 Evdev Third Button Emulation Button (296): 3 Evdev Third Button Emulation Threshold (297): 20 Evdev Wheel Emulation (298): 0 Evdev Wheel Emulation Axes (299): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (300): 10 Evdev Wheel Emulation Timeout (301): 200 Evdev Wheel Emulation Button (302): 4 Evdev Drag Lock Buttons (303): 0 can you run the mouse-dpi-tool please, just making sure we have the dpi setting correct. (In reply to Peter Hutterer from comment #2) > can you run the mouse-dpi-tool please, just making sure we have the dpi > setting correct. Hello Peter, Here is the output of mouse-dpi-tool. Mouse Logitech USB Laser Mouse on /dev/input/event2 Move the device 250mm/10in or more along the x-axis. Pause 3 seconds before movement to reset, Ctrl+C to exit. Covered distance in device units: 17796 at frequency 126.0Hz /^C Estimated sampling frequency: 126Hz To calculate resolution, measure physical distance covered and look up the matching resolution in the table below 1130mm 44.49in 400dpi 753mm 29.66in 600dpi 565mm 22.25in 800dpi 452mm 17.80in 1000dpi 376mm 14.83in 1200dpi 322mm 12.71in 1400dpi 282mm 11.12in 1600dpi 251mm 9.89in 1800dpi 226mm 8.90in 2000dpi 205mm 8.09in 2200dpi 188mm 7.42in 2400dpi If your resolution is not in the list, calculate it with: resolution=17796/inches, or resolution=17796 * 25.4/mm Entry for hwdb match (replace XXX with the resolution in DPI): mouse:usb:v046dpc069:name:Logitech USB Laser Mouse: MOUSE_DPI=XXX@126 I did several 300/400mm mouvements and I found that the dpi is about 1100 / 1130. According to the specifications the mouse dpi is 1000 ( https://secure.logitech.com/en-us/product/corded-mouse-m500 ) the hwdb already says 1200 dpi, so given your measurements that seems to be the next-closest value. You can try to change the hwdb entry to say 1100 or even 1000 and see if that fixes it but I guess it won't make that much of a difference. I'll have to queue you in the list of ppl unhappy with the libinput accel methods. Unfortunately this is not something easy to fix, in part because it's very subjective and in part because the xserver code is so convoluted and device-dependent that it's effectively impossible to apply the same acceleration as the server does (definitely the case for touchpads, it's a bit easier for mice I think). (In reply to Peter Hutterer from comment #4) > the hwdb already says 1200 dpi, so given your measurements that seems to be > the next-closest value. You can try to change the hwdb entry to say 1100 or > even 1000 and see if that fixes it but I guess it won't make that much of a > difference. > > I'll have to queue you in the list of ppl unhappy with the libinput accel > methods. Unfortunately this is not something easy to fix, in part because > it's very subjective and in part because the xserver code is so convoluted > and device-dependent that it's effectively impossible to apply the same > acceleration as the server does (definitely the case for touchpads, it's a > bit easier for mice I think). I set MOUSE_DPI=1000@125 and it's much, much better now ! It's not perfect but it's close. Can this be included by default ? Thank you ! try to measure the dpi again with the tool, to it a few times on different surfaces if possible and make sure you're precise enough. if you find that the current dpi is wrong we can fix it (In reply to Peter Hutterer from comment #6) > try to measure the dpi again with the tool, to it a few times on different > surfaces if possible and make sure you're precise enough. if you find that > the current dpi is wrong we can fix it I find again about 1100 dpi with the tool. A value of MOUSE_DPI=1000@125 is good. If we're measuring 1100 we need to put that into the hwdb. That tag is supposed to describe the physical properties of the mouse, not adjust acceleration. (In reply to Peter Hutterer from comment #8) > If we're measuring 1100 we need to put that into the hwdb. That tag is > supposed to describe the physical properties of the mouse, not adjust > acceleration. It seems that you are right. I searched a little more with the serial number of my mouse and I found that the dpi are 1100 http://support.logitech.com/en_us/product/corded-mouse-m500 That said 1000 dpi give a better feeling, not only for the acceleration, but also for small movements. Peter will you change the Logitech M500 dpi ? ok, the systemd patch got merged so the DPI information should be correct now. The next problem is that it's still not good enough according to comment 9, so that's another bug about pointer acceleration not being good enough. unfortunately I still have (at least) one big feature on my slate before I can look at pointer acceleration, so this won't be looked at until after libinput 1.4, sorry. (In reply to Peter Hutterer from comment #12) > ok, the systemd patch got merged so the DPI information should be correct > now. Thank you very much but I think we maybe have made a mistake. The 1200dpi value I got was due to an "old" hwdb. I just saw that the mouse dpi was recently set to 1000dpi@125 https://github.com/whot/systemd/commit/62f6eed416e3f4a473e3f2b39dc5457284e34f58 and after some more research I always found that the M500 is a 1000dpi mouse and advertised as such : https://secure.logitech.com/en-us/product/corded-mouse-m500 http://www.logitech.fr/fr-fr/product/corded-mouse-m500 ... There is only one and only one link that say it's a 1100dpi mouse and furthermore it says max: 1100dpi : http://support.logitech.com/en_us/product/corded-mouse-m500 I also find it more pleasant to use at 1000dpi even if the pointer acceleration is not optimal for now as you said. I don't know how precise is mouse-dpi-tool but maybe we should revert back the patch ? What do you think ? By the way the title of the patch is wrong it's the M500 mouse not the MX500 ;-) > The next problem is that it's still not good enough according to comment 9, > so that's another bug about pointer acceleration not being good enough. > unfortunately I still have (at least) one big feature on my slate before I > can look at pointer acceleration, so this won't be looked at until after > libinput 1.4, sorry. At 1000dpi@125 the pointer acceleration is good enough for now, so it's not really a problem. fwiw, the hwdb has no effect on the mouse-dpi-tool, it only affects libinput. the mouse-dpi-tool listens to the kernel events directly and gives you the results as measured. Given that you measured 1100 as well I'm more tempted to leave the measured value than the official spec. Try it a few more times anyway, at different speeds, etc. Also note when measuring the distance that you're measuring sensor movements, not left edge to right edge of the mouse. (In reply to Peter Hutterer from comment #14) > Try it a few more times anyway, at different speeds, etc. Also note when > measuring the distance that you're measuring sensor movements, not left edge > to right edge of the mouse. After many more measures at different speed and with different distances I find a dpi value that vary between 1005 to 1144. I had all the value in this range every about 20 dpi (1005, 1024, 1052...). My measures, or the tool, are not really reliable I think :D Since it's sold as a 1000dpi mouse and it work better at this value we should treat it as such I think. Thank you very much Peter. The behavior at 1000dpi is good but I have to use it more to see if it can be better, especially the pointer acceleration. So should we close this or let this open until the pointer acceleration rework after libinput 1.4 ? I don't know if it will help with pointer acceleration but if I remove "xorg-x11-drv-libinput" and use the command "xset m default" the behavior of the logitech m500 is great. If we can achieve to have the same behavior with libinput it will be perfect I think. the problem is that the X server acceleration is... opaque. I really don't know what's happening, there are too many different factors at play, including device-specifics that it's almost impossible to predict what the pointer accel code does. That's one reason why libinput does things like the MOUSE_DPI database. I made more tests and the libinput behavior at 1000dpi is not bad at all. Not as good as X11 (on Netrunner 14) but pretty close and much much better than on Windows 10 that is very very bad. I don't know what the behavior of this mouse should be in reality. I prefer the X11 feeling but maybe it should not work like that and behave more like on windows... On my chromebook I have a Kensington mouse and its behavior is much better with libinput than with X11. Its cyapa touchpad behavior is perfect with libinput. I installed Fedora 23, a couple of days ago, on 2 other laptops and their touchpad behavior was good with libinput. The 2 mouses I used on theses laptops had also a good behavior. Finally the libinput pointer acceleration seem good, especially as it seems to be a very tricky subject. I don't know if you can improve it. (In reply to Paviluf from comment #20) > On my chromebook I have a Kensington mouse and its behavior is much better > with libinput than with X11. this is a bit weird, because the whole point of libinput and the dpi database etc. is that they should behave the same. so if the dpi ratio is set for both mice the two mice should behave the same. (In reply to Peter Hutterer from comment #21) > this is a bit weird, because the whole point of libinput and the dpi > database etc. is that they should behave the same. so if the dpi ratio is > set for both mice the two mice should behave the same. I don't understand why you talk about 2 mice. Do you mean that my Kensington mouse should behave the same with libinput and X11 ? The mouse is much more faster (too fast) with X11 than with libinput. I found that it's a 1000dpi mouse : http://www.kensington.com/ce/ca/4487/8589672339/pro-fit-retractable-mobile-mouse And it seem to be handled by the hwdb : mouse:usb:v093ap2510:name:PixArt USB Optical Mouse: https://github.com/systemd/systemd/commit/e8043cd5fe283ff3023f98c15a2f09328805efab you have the kensington mouse and the m500 - they should both behave the same once the DPI ratio is entered (except the m500 oscillates up to 1100dpi, so that'd be a slight change). (In reply to Peter Hutterer from comment #23) > you have the kensington mouse and the m500 - they should both behave the > same once the DPI ratio is entered (except the m500 oscillates up to > 1100dpi, so that'd be a slight change). Oh ok, I didn't thought of this because I use the m500 on my desktop with a 23" display and the kensington on my 13" chromebook. The feeling is different because their size and weight are very different but I tried them both on the chromebook and you are right they seem to behave more or less the same. fwiw, mouse acceleration isn't display dependent (it is in synaptics due to a bug, but not in libinput). I think this bug can be closed as WORKSFORME too now? You can close the bug Peter. The behavior is good enough now at 1000dpi. Thank you very much ! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.