evden and horizontal wheel

[Dan Nicholson]

On Mon, Oct 6, 2008 at 10:06 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Mon, Oct 6, 2008 at 9:50 AM, Ander Conselvan de Oliveira
> <ander at c3sl.ufpr.br> wrote:
>> Em Monday 06 October 2008 13:23:48 Dan Nicholson escreveu:
>>> On Mon, Oct 6, 2008 at 7:41 AM, Ander Conselvan de Oliveira
>>>
>>> <ander at c3sl.ufpr.br> wrote:
>>> > Hello,
>>> >
>>> > 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;
>>> >
>>> > But the, somewhat recent, kernel commit
>>> > 740f370dc61dc478d891d7d47660bb3ae39ddb4f, by Dan Nicholson states:
>>> >
>>> > "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."
>>> >
>>> > Since I have no mice with horizontal scroll wheels, I have no idea what
>>> > is the correct way to handle this.
>>>
>>> This should definitely be fixed at the kernel level instead of hacking
>>> around it in userspace. What kind of mouse does he have?
>>
>> His mouse is a Logitech V150.
>
> Huh, OK. Let me take another look when I get home and make sure that
> the behavior is as I described it.
>
>>> The above commit message a wrote was simply the behavior I noticed,
>>> and I don't know authoritatively what value applications expect. I do
>>> know my mice work correctly with recent kernel (with above commit) and
>>> recent xf86-input-evdev. A good way to test what the kernel is
>>> outputting without X getting in the way is evtest, which google will
>>> point you to, but I used the one from the linux-input CVS:
>>
>> The kernel seems to output the correct values (he's using a kernel with the
>> above commit) [0]. The way I see it, this should not work with the current
>> evdev driver, since wheel_right_button clicks are posted when the value
>> reported by the kernel is positive.
>>
>>        [0] https://qa.mandriva.com/show_bug.cgi?id=44309#c19
>
> I hadn't looked at the code in xf86-input-evdev before, but it does
> make sense as you've described it. I don't know why the behavior I was
> seeing was different. AFAIK, there hadn't been any remapping on my
> system except for the kernel patch I produced.

I think you're right and the patch should probably be reverted. Using
the similar Logitech LX3 on a 2.6.26.5 kernel without the patch, I get
the behavior your user described in evtest:

Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc044 version 0x110
Input device name: "Logitech USB-PS/2 Optical Mouse"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
    Event code 273 (RightBtn)
    Event code 274 (MiddleBtn)
    Event code 275 (SideBtn)
    Event code 276 (ExtraBtn)
    Event code 277 (ForwardBtn)
    Event code 278 (BackBtn)
    Event code 279 (TaskBtn)
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
    Event code 6 (HWheel)
    Event code 8 (Wheel)
  Event type 4 (Misc)
    Event code 4 (ScanCode)
Testing ... (interrupt to exit)
[snip]
# Wheel pressed right
Event: time 1223386653.964641, type 2 (Relative), code 6 (HWheel), value 1
[snip]
# Wheel pressed left
Event: time 1223386654.572649, type 2 (Relative), code 6 (HWheel), value -1

xev reports:

# Pressed right
ButtonPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x7d, subw 0x0, time 30955454, (39,91), root:(42,140),
    state 0x10, button 7, same_screen YES

# Pressed left
ButtonPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x7d, subw 0x0, time 30957902, (39,91), root:(42,140),
    state 0x10, button 6, same_screen YES

And gtk-demo scrolls correctly.

I was on a different system when I did that testing and produced that
patch. I must have something backwards in my setup. Later I'll dig out
my V150, but I recently moved and am not sure where it is right now.
When I originally tested this, the LX3 and V150 behaved identically.

Here's the patch I sent to the input list:

http://thread.gmane.org/gmane.linux.kernel.input/5111

I'll send a revert commit after I check the other mouse. Sorry about that.

--
Dan