[PATCH] HID: Invert HWHEEL mappings for some Logitech mice

[PATCH] HID: Invert HWHEEL mappings for some Logitech mice

[Dan Nicholson]

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.

Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
---
 drivers/hid/usbhid/hid-quirks.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1df832a..372799f 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -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

Re: [PATCH] HID: Invert HWHEEL mappings for some Logitech mice

[Jiri Kosina]

On Sat, 14 Jun 2008, Dan Nicholson wrote:

> 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.

Thanks Dan, applied.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: Invert HWHEEL mappings for some Logitech mice

[Dan Nicholson]

On Wed, Jun 18, 2008 at 9:03 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Sat, 14 Jun 2008, Dan Nicholson wrote:
>
>> 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.
>
> Thanks Dan, applied.

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

--
Dan

[PATCH] Revert "HID: Invert HWHEEL mappings for some Logitech mice"

[Dan Nicholson]

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

Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
---
 drivers/hid/usbhid/hid-quirks.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index b15f882..49144cb 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -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

Re: [PATCH] Revert "HID: Invert HWHEEL mappings for some Logitech mice"

[Jiri Kosina]

On Thu, 16 Oct 2008, Dan Nicholson wrote:

> 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.

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

Re: [PATCH] Revert "HID: Invert HWHEEL mappings for some Logitech mice"

[Dan Nicholson]

On Fri, Oct 17, 2008 at 2:26 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Thu, 16 Oct 2008, Dan Nicholson wrote:
>
>> 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.
>
> 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?

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

Re: [stable] [PATCH] Revert "HID: Invert HWHEEL mappings for some Logitech mice"

[Greg KH]

On Fri, Oct 17, 2008 at 11:26:37AM +0200, Jiri Kosina wrote:
> On Thu, 16 Oct 2008, Dan Nicholson wrote:
> 
> > 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.

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

Re: [stable] [PATCH] Revert "HID: Invert HWHEEL mappings for some Logitech mice"

[Jiri Kosina]

On Thu, 23 Oct 2008, Greg KH wrote:

> > > 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.
> 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.

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