Bug 96225

Summary: Logitech M500 behavior
Product: Wayland Reporter: Paviluf <jeremy9856>
Component: libinputAssignee: 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
Hello,

I have a Logitech M500 mouse and I find it not really pleasant to use on Fedora 23 with libinput 1.2.4 in comparaison to Netrunner 14.2 (based on Kubuntu 14.04 with synaptics driver I guess and updated with latest KDE 4).

On Netrunner I use these (default I think) settings in the mouse settings and it's perfect :

Pointer Acceleration: 2x
Pointer Threshold: 4 pixels

On Fedora the cursor is too slow both for small or large mouvements by default. If I increase the pointer speed in the mouse settings I can't obtain the same behavior. Depending on how much I increase the speed the pointer can be too slow for small and large movements or too slow for small movements and too fast for large one or almost ok for small movements and far too fast for large one.

Is it something that can be improved in libinput or do I have to make some custom config ?

Thanks !

Here is the output of "udevadm info /sys/class/input/event2"

P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:046D:C069.0001/input/input3/event2
N: input/event2
S: input/by-id/usb-Logitech_USB_Laser_Mouse-event-mouse
S: input/by-path/pci-0000:00:1d.0-usb-0:1.5:1.0-event-mouse
E: DEVLINKS=/dev/input/by-id/usb-Logitech_USB_Laser_Mouse-event-mouse /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.5:1.0-event-mouse
E: DEVNAME=/dev/input/event2
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:046D:C069.0001/input/input3/event2
E: ID_BUS=usb
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_MODEL=USB_Laser_Mouse
E: ID_MODEL_ENC=USB\x20Laser\x20Mouse
E: ID_MODEL_ID=c069
E: ID_PATH=pci-0000:00:1d.0-usb-0:1.5:1.0
E: ID_PATH_TAG=pci-0000_00_1d_0-usb-0_1_5_1_0
E: ID_REVISION=5601
E: ID_SERIAL=Logitech_USB_Laser_Mouse
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:030102:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Logitech
E: ID_VENDOR_ENC=Logitech
E: ID_VENDOR_ID=046d
E: LIBINPUT_DEVICE_GROUP=3/46d/c069/110:usb-0000:00:1d.0-1
E: MAJOR=13
E: MINOR=66
E: MOUSE_DPI=1200@125
E: SUBSYSTEM=input
E: USEC_INITIALIZED=3963789
Comment 1 Paviluf 2016-05-26 18:33:37 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
Comment 2 Peter Hutterer 2016-05-27 07:41:32 UTC
can you run the mouse-dpi-tool please, just making sure we have the dpi setting correct.
Comment 3 Paviluf 2016-05-27 08:49:17 UTC
(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 )
Comment 4 Peter Hutterer 2016-05-30 05:47:15 UTC
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).
Comment 5 Paviluf 2016-05-31 11:15:03 UTC
(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 !
Comment 6 Peter Hutterer 2016-06-01 04:53:06 UTC
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
Comment 7 Paviluf 2016-06-02 11:18:14 UTC
(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.
Comment 8 Peter Hutterer 2016-06-02 23:25:25 UTC
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.
Comment 9 Paviluf 2016-06-03 08:58:01 UTC
(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.
Comment 10 Paviluf 2016-06-10 11:52:54 UTC
Peter will you change the Logitech M500 dpi ?
Comment 11 Peter Hutterer 2016-06-12 23:36:39 UTC
https://github.com/systemd/systemd/pull/3517
Comment 12 Peter Hutterer 2016-06-13 06:35:24 UTC
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.
Comment 13 Paviluf 2016-06-13 09:56:12 UTC
(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.
Comment 14 Peter Hutterer 2016-06-14 00:39:58 UTC
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.
Comment 15 Paviluf 2016-06-14 11:05:02 UTC
(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.
Comment 16 Peter Hutterer 2016-06-17 01:09:20 UTC
https://github.com/systemd/systemd/pull/3557
Comment 17 Paviluf 2016-06-17 11:18:25 UTC
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 ?
Comment 18 Paviluf 2016-06-17 16:40:28 UTC
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.
Comment 19 Peter Hutterer 2016-06-20 00:08:40 UTC
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.
Comment 20 Paviluf 2016-06-22 21:47:32 UTC
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.
Comment 21 Peter Hutterer 2016-06-23 05:38:00 UTC
(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.
Comment 22 Paviluf 2016-06-23 09:10:19 UTC
(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
Comment 23 Peter Hutterer 2016-06-23 23:01:11 UTC
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).
Comment 24 Paviluf 2016-06-24 16:58:33 UTC
(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.
Comment 25 Peter Hutterer 2016-06-26 23:01:48 UTC
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?
Comment 26 Paviluf 2016-06-26 23:09:36 UTC
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.