HID: Invert HWHEEL mappings for some Logitech mice

Some Logitech mice have a tilt wheel which register as HWHEEL buttons. The events are positive for a click to the right and negative for a click to the left. Applications expect the opposite, though.

I suspect this affects a lot more Logitech mice, but these are the only two I have. I tested this using evtest and a GTK application. A similar Microsoft Intellimouse I have works correctly.

---
 drivers/hid/usbhid/hid-quirks.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

index 1df832a..372799f 100644
@@ -241,6 +241,8 @@
 #define USB_DEVICE_ID_LD_MACHINETEST	0x2040
 
 #define USB_VENDOR_ID_LOGITECH		0x046d
+#define USB_DEVICE_ID_LOGITECH_LX3	0xc044
+#define USB_DEVICE_ID_LOGITECH_V150	0xc047
 #define USB_DEVICE_ID_LOGITECH_RECEIVER	0xc101
 #define USB_DEVICE_ID_LOGITECH_HARMONY  0xc110
 #define USB_DEVICE_ID_LOGITECH_HARMONY_2 0xc111

@@ -593,6 +595,8 @@ static const struct hid_blacklist {
 
 	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_ELITE_KBD, HID_QUIRK_LOGITECH_IGNORE_DOUBLED_WHEEL | HID_QUIRK_LOGITECH_EXPANDED_KEYMAP },
 	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_CORDLESS_DESKTOP_LX500, HID_QUIRK_LOGITECH_IGNORE_DOUBLED_WHEEL | HID_QUIRK_LOGITECH_EXPANDED_KEYMAP },
+	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_LX3, HID_QUIRK_INVERT_HWHEEL },
+	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_V150, HID_QUIRK_INVERT_HWHEEL },
 
 	{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_NE4K, HID_QUIRK_MICROSOFT_KEYS },
 	{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_LK6K, HID_QUIRK_MICROSOFT_KEYS },

1.5.3.2

Thanks Dan, applied.

Jiri Kosina
SUSE Labs

Great! I thought I would have a harder time convincing you. :)

--
Dan

This reverts commit 740f370dc61dc478d891d7d47660bb3ae39ddb4f.

It turned out to be correct in the first place: a positive value should be sent when the wheel is moved to the right, and a negative value when moved to the left. This is the behavior expected by the Xorg evdev driver. I must have had a remapping somewhere else in my system when originally testing this. Testing on another system shows that the unpatched kernel is correct.

Here is a bug report from Mandriva that brought the problem to my attention:

    https://qa.mandriva.com/show_bug.cgi?id=44309#c19

---
 drivers/hid/usbhid/hid-quirks.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

index b15f882..49144cb 100644
@@ -247,8 +247,6 @@
 #define USB_DEVICE_ID_LD_MACHINETEST	0x2040
 
 #define USB_VENDOR_ID_LOGITECH		0x046d
-#define USB_DEVICE_ID_LOGITECH_LX3	0xc044
-#define USB_DEVICE_ID_LOGITECH_V150	0xc047
 #define USB_DEVICE_ID_LOGITECH_RECEIVER	0xc101
 #define USB_DEVICE_ID_LOGITECH_HARMONY  0xc110
 #define USB_DEVICE_ID_LOGITECH_HARMONY_2 0xc111

@@ -603,8 +601,6 @@ static const struct hid_blacklist {
 
 	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_ELITE_KBD, HID_QUIRK_LOGITECH_IGNORE_DOUBLED_WHEEL | HID_QUIRK_LOGITECH_EXPANDED_KEYMAP },
 	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_CORDLESS_DESKTOP_LX500, HID_QUIRK_LOGITECH_IGNORE_DOUBLED_WHEEL | HID_QUIRK_LOGITECH_EXPANDED_KEYMAP },
-	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_LX3, HID_QUIRK_INVERT_HWHEEL },
-	{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_V150, HID_QUIRK_INVERT_HWHEEL },
 
 	{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_NE4K, HID_QUIRK_MICROSOFT_KEYS },
 	{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_LK6K, HID_QUIRK_MICROSOFT_KEYS },

1.5.6.2

Hi Dan,

thanks. Still I'd like to understand what caused the behavior you were seeing. Do you still have the system showing the inverted values available?

Jiri Kosina
SUSE Labs

Hi Jiri,

Sorry for the slow reply; I was travelling for a few days.

I've now gotten the old system back up with a patched 2.6.22 kernel. After comparing it to a freshly installed Fedora 9 system with an unpatched 2.6.26 kernel, I can say that the difference is the xf86-input-evdev driver. I was able to build a newer xf86-input-evdev driver and swap that in against my older kernel.

linux-2.6.22 (without patch) + xf86-input-evdev-1.1.5:
wheel left = HWheel -1 = X button 7
wheel right = HWheel +1 = X button 6

linux-2.6.22 (with patch) + xf86-input-evdev-1.1.5:
wheel left = HWheel +1 = X button 6
wheel right = HWheel -1 = X button 7

linux-2.6.22 (with patch) + xf86-input-evdev-2.0.7:
wheel left = HWheel +1 = X button 7
wheel right = HWheel -1 = X button 6

linux-2.6.22 (with patchout) + xf86-input-evdev-2.0.7:
wheel left = HWheel -1 = X button 6
wheel right = HWheel +1 = X button 7

linux-2.6.26 (without patch) + xf86-input-evdev-2.0.7:
wheel left = HWheel -1 = X button 6
wheel right = HWheel +1 = X button 7

X applications behave correctly when wheel left = button 6 and wheel right = button 7. When I started using the newer xf86-input-evdev with an unpatched kernel, things work fine.

So, it seems that X evdev-1.1.x interprets +1 events from the kernel as button 6, and X evdev 2.0.x interprets +1 events from the kernel as button 7. I don't know who's correct there, but here's quoting Ander on how xf86-input-evdev-2.x works:

'''
I have a user reporting his horizontal wheel is inverted using the evdev input driver. If I understand correctly, evdev handles positive values as "to the right" and negative as "to the left":

           case REL_HWHEEL:
               if (value > 0)
                   PostButtonClicks(pInfo, wheel_right_button, value);
               if (value < 0)
                   PostButtonClicks(pInfo, wheel_left_button, -value);
               break;

'''

I tried having a look at the older X evdev driver, but it was much more convoluted and I couldn't figure it out.

What do you think? I'm gonna lean towards the newer X evdev driver behaving correctly, but I have no authority here.

--
Dan

Jiri, should we apply this to the 2.6.27-stable tree now? I don't see this change in Linus's tree yet, but I figured as the quirk stuff was massivly changed, I might have missed it.

thanks,

greg k-h

Hi Greg,

is is sitting in my queue to be pushed to Linus, it didn't happen yet, I am still sorting a last few things out. I expect to push it today or during the weekend.

Thanks,

Jiri Kosina
SUSE Labs