Bug 1035668 - Problematic support for Logitech M560 mouse
Summary: Problematic support for Logitech M560 mouse
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-28 09:41 UTC by Alexander Ploumistos
Modified: 2015-03-30 09:33 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-12-19 17:05:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alexander Ploumistos 2013-11-28 09:41:02 UTC
Originally, I reported the bug on the linux-input mailing list, but perhaps I should have reported it here first.

It is one of those mice that connect through a "Unifying receiver", model M560:
http://www.logitech.com/en-us/product/wireless-mouse-m560

There are the following buttons:
Left and right click, a scroll wheel with tilt, back and forward buttons on the side and a small square button behind the wheel - a total of nine buttons. The wheel does not double as middle click, there is no switch under it. Instead, pressing the wheel engages and disengages a lock, allowing it to revolve either in steps or freely.

Default button mapping, as reported by xev and xinput:
Button 1 -> left click
Button 3 -> right click
Button 4 -> wheel up
Button 5 -> wheel down
Button 8 -> tilt left
Button 9 -> tilt right

And the problematic ones:
Pressing the forward button sends Super_R (keycode 134).
Pressing the back button sends simultaneously Super_L and d (keycodes 133 & 40).
Pressing the square button once, gives simultaneously Alt_L, Super_L and XF86TouchpadOff (keycodes 64, 133, 201).
Pressing it a second time is like pressing button 1.
This button alternates between those two states.


I have tested the mouse on kernels 3.11.4-201 to 3.11.9-200 on both x86_64 and i686 systems with xorg-x11-drv-evdev-2.8.1-2.fc19 and libevdev-0.4-1.fc19.

I got the exact same results with Ubuntu kernels 3.11.x and Gentoo kernel 3.10.17.

I think it would make more sense, if the small button was mapped to Button 2, tilt left/right to 6/7 and back/forward to 8/9. However, swapping the button mapping to one's preference is easier than having to deal with keyboard keycodes being sent from the mouse.


Original messages on linux-input mailing list:
http://www.spinics.net/lists/linux-input/msg28242.html
http://www.spinics.net/lists/linux-input/msg28243.html

Comment 2 Jerone Young 2013-12-17 14:56:44 UTC
Also to add. Might want to follow this Launchpad thread for middle mouse click as it faces the same problem:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1247584

Comment 3 Jerone Young 2013-12-17 15:06:54 UTC
The mouse is actually designed to have the behavior you are seeing. It actually acts as a keyboard and sends keyboard commands. In Windows 8 this makes since. Everywhere else it does not.

To remediate the problem you use udev. I have a fix for Fedora Core 20. The only problem is no way to map a middle mouse click button.

This should not go upstream as there is no way to distinguish the mouse currently. So (I believe) if you have another logitech device, like a keyboard, hooked up to the unified interface it will screw it up.

This is what you do

1) Create Directory /etc/udev/hwdb.d/
   mkdir /etc/udev/hwdb.d/

2) Create file /etc/udev/hwdb.d/90-logitech-m-560.hwdb with content:
# Logitech M-560
keyboard:usb:v046DpC52B*
 KEYBOARD_KEY_90001=middle              # Middle Button map to Middle
 KEYBOARD_KEY_700E2=reserved           # Will Send leftalt when move left with middle button click
 KEYBOARD_KEY_70072=reserved            # Will send f23 when move left with middle button click
 KEYBOARD_KEY_700E3=reserved            # Will Send leftmeta when move right with middle button click. Also is sent when use Back button.
 KEYBOARD_KEY_7002B=reserved            # Will Send tab when move right with middle button click
 KEYBOARD_KEY_90004=left                # Left Scroll Click map to Left
 KEYBOARD_KEY_90005=right               # Right Scroll Click map to Right
 KEYBOARD_KEY_70007=back                # Back button sends second keycode. 700E3 is the first and already mapped.
 KEYBOARD_KEY_700E7=forward             # Forward button map to Forward


3) Update udev hardware database by running command (as root):
      udevadm hwdb --update

4) Reboot

Comment 4 Jerone Young 2013-12-17 18:48:41 UTC
So played around a bit more. It turns out setting the Middle Button to "middle" actually does nothing. But you really want it that way.

The reason is the middle button, when touched and not moved, will send out 0x9001 for it's key code. It's the same key code that the left mouse click sends also. So if you change it, it will break the left mouse click.

The middle button will though work if you move the mouse right or left during actions and map key 0x70072. But this isn't very optimal.

I got middle mouse click working, though you have to be moving the mouse left or right while pressing the middle button. With the help of this link:

http://linuxaleph.blogspot.com/2012/03/mapping-middle-click-to-keyboard-key.html

Here are updated instructions:
1) Create Directory /etc/udev/hwdb.d/
   mkdir /etc/udev/hwdb.d/

2) Create file /etc/udev/hwdb.d/90-logitech-m-560.hwdb with content:
# Logitech M-560
keyboard:usb:v046DpC52B*
 KEYBOARD_KEY_70007=back                # Back button sends second keycode. 700E3 is the first and already mapped.
 KEYBOARD_KEY_700E7=forward             # Forward button map to Forward
 KEYBOARD_KEY_7002B=prog1               # Will Send tab when move right with middle button click
 KEYBOARD_KEY_70072=prog1               # Will send f23 when move left with middle button click
 KEYBOARD_KEY_700E2=reserved            # Will Send leftalt when move left with middle button click
 KEYBOARD_KEY_700E3=reserved            # Will Send leftmeta when move right with middle button click. Also is sent when use Back button.
 KEYBOARD_KEY_90004=left                # Left Scroll Click map to Left
 KEYBOARD_KEY_90005=right               # Right Scroll Click map to Right

3) Update udev hardware database by running command (as root):
      udevadm hwdb --update

4) Reboot

5) Setup middle click with help of these instructions. The click is mapped to "prog1". You will have to be moving the mouse left or right while pressing the middle button.
http://linuxaleph.blogspot.com/2012/03/mapping-middle-click-to-keyboard-key.html
http://linuxaleph.blogspot.com/2008/11/mapping-middle-click-to-keyboard-key.html

Comment 5 Alexander Ploumistos 2013-12-19 09:16:54 UTC
I am very grateful for your detailed instructions. I wasn't aware that it was possible to remap keys via hwdb files.

The middle click is a real pain. I set a custom keyboard shortcut so that XF86Launch1 runs "xdotool click 2". It took me a lot of practice to manage moving and clicking and I still can't get it right all the time. Inserting text to a specific point is nearly impossible.

Anyway, I'm glad this mouse is not mine, at least I learned something new. Thank you!

P.S.: Should this be marked as closed?

Comment 6 Jerone Young 2013-12-19 16:41:14 UTC
Yeah best to close it. 

The mouse is designed to act this way. It basically send Windows 8 Hot Key combinations. It really is specifically designed for Windows 8. 

Though now you can make it usable in the traditional way of using a mouse.

Also if you try the mouse out, without the workaround, with UI interfaces GNOME 3 & Cinnammon these interface actually can handle many of the Windows Hot Key combinations and might work great with it as it's meant to be used.

Comment 7 Josh Boyer 2013-12-19 17:05:34 UTC
Ok.  Thank you very much for the detailed instructions Jerone.

Comment 8 Tetsumaki 2014-02-16 01:23:06 UTC
Hello.

Your solution is not good if there is more than two devices Logitech Unifying.

Exemple :
Keyboard Logitech K270
Mouse Logitech M560

The rules apply to keyboard ans mouse and this is a big problem.

dmesg | grep logitech-dj
   [    3.070809] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1a.1-2/input2
    [    3.074236] logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Keyboard [Logitech Unifying Device. Wireless PID:402d] on usb-0000:00:1a.1-2:1
    [    3.076213] logitech-djdevice 0003:046D:C52B.0005: input,hidraw2: USB HID v1.11 Keyboard [Logitech Unifying Device. Wireless PID:4003] on usb-0000:00:1a.1-2:2

With your solution (90-logitech-m-560.hwdb), some keys do not work on the keyboard (Super+D, D, and more) because it's a same vId and pId.

Comment 9 malatesta.mike 2014-02-21 00:05:22 UTC
Where did you get the keyboard key codes you are using?  I'd like to further customize my mouse to my liking.  Thanks.

Comment 10 Jerone Young 2014-02-21 00:50:14 UTC
@malatesta.mike

       Under Fedora Core 20 the tool is called "evtest". See file /lib/udev/hwdb.d/60-keyboard.hwdb for more information and examples.

Comment 11 arielmazatlan 2014-02-28 19:15:31 UTC
I used the following information as a work around:

https://help.ubuntu.com/community/MouseCustomizations

This is the .xbindkeys that I've been using:

#side up
"/usr/bin/xte 'keyup Super_R' ; sleep .01; /usr/bin/xte 'key Home' &"
   Super_R

#side down
"/usr/bin/xte 'keyup Super_R' ; sleep .01; /usr/bin/xte 'key End' &"
   Mod4 + d

#middle left
""
   Control + Tab + Super_L

#middle
"/usr/bin/xte 'mouseclick 1'&"
   Super_L + Alt

Also, I used the following command to assign mouse button 2 (middle button) to number 9.

xmodmap -e "pointer = 1 9 3 4 5 6 7 8 2 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"

I've been unable to do something with the little button behind the mouse's scroll, because of it tow stages. One is Super_L + Alt, and the other is mouse button 1.

Comment 12 Ahmad Samir 2014-09-02 05:38:46 UTC
The patch from the launchpad bug in comment#2 has gone upstream; so now one can actually use a hwdb rule to make one of the side buttons a middle button. I've filed a bug against systemd asking to include that patch in the Fedora package, bug 1136169.

Comment 13 stephane 2014-09-18 17:34:19 UTC
I have found a work around with this mouse, as I use the middle button often in CAD softwares...

I use the side button to toggle the "Active middle 2", and click again on it to "Remove middle 2 activations"...

So it's pressed, or not. 

here my .xbindkeysrc
#forward
"/usr/bin/lxterminal &"
Mod4 + d

#back
"/usr/local/bin/mouseclick &"
Super_R


And here the script mouseclick to put in the /usr/local/bin/ folder.
It use a file to know if the middle click is on or off. It can be optimised with a global Variable instead of a I/O on the filesystem...

#!/bin/bash
MIDDLE=/tmp/middle
if [ ! -f $MIDDLE ]; 
then 
	touch $MIDDLE && /usr/bin/xte 'mousedown 2'; 
else 
	rm $MIDDLE && /usr/bin/xte 'mouseup 2'; 
fi




Hope that help someone.

Comment 14 Ahmad Samir 2015-03-11 14:44:09 UTC
With recent versions of systemd (in F21) where the upstream commit I mentioned in c#12, here is a .hwdb file to use the bottom side button as a middle button:
$ cat /etc/udev/hwdb.d/80-logitech-m560.hwdb
keyboard:usb:v046DpC52B*
 KEYBOARD_KEY_70007=274         # side bottom button becomes middle

use that instead of the .hwdb file in c#4, then follow the rest of the instructions Jerone posted to update the hwdb. That button is big enough that using it as a middle click is quite easy IMHO.

Comment 15 Ahmad Samir 2015-03-11 16:24:14 UTC
FWIW, you don't need to reboot, just unplugging/replugging the usb receiver is enough to trigger the changes.

Comment 16 Jadzia 2015-03-28 09:57:29 UTC
I'm using still the old init system and not systemd. Do you know how I can also in this case get the side button working as the middle mouse button?

Comment 17 Ahmad Samir 2015-03-30 09:33:32 UTC
Unfortunately, no I don't :/


Note You need to log in before you can comment on or make changes to this bug.