Re: Apple Wireless Mighty Mouse HWheel quirk

Re: Apple Wireless Mighty Mouse HWheel quirk

[Jiri Slaby]

On 04/14/2009 09:24 PM, J.R. Mauro wrote:
> I have an Apple bluetooth mouse (info below) and have noticed that the
> horizontal scrolling is inverted. I've noticed some bug reports from
> others getting the same behavior. I looked at drivers/hid/hid-apple.c
> , and around line 444 I see that APPLE_INVERT_HWHEEL gets ORed in. I
> tried to trace the origins of the code, but I lost track of it before
> 8c19a515, where you moved Apple quirks to their own file. Is this
> quirk definitely correct?
> 
> Mouse's entry in /proc/bus/input/devices
> I: Bus=0005 Vendor=05ac Product=030c Version=0200
> 
> I'm running Gentoo, vanilla 2.6.29 with no patches.

Hi,

I have no idea whether the inversion is correct or not. Or where the
information comes from :).

It was added in
cb3fecc2f29056e89658e7eb371e7f9be66cda6d
by Jiri Kosina, maybe he may shed some light on it?

Re: Apple Wireless Mighty Mouse HWheel quirk

[Jiri Kosina]

On Tue, 14 Apr 2009, Jiri Slaby wrote:

> > I have an Apple bluetooth mouse (info below) and have noticed that the 
> > horizontal scrolling is inverted. I've noticed some bug reports from 
> > others getting the same behavior. I looked at drivers/hid/hid-apple.c 
> > , and around line 444 I see that APPLE_INVERT_HWHEEL gets ORed in. I 
> > tried to trace the origins of the code, but I lost track of it before 
> > 8c19a515, where you moved Apple quirks to their own file. Is this 
> > quirk definitely correct?
> > Mouse's entry in /proc/bus/input/devices
> > I: Bus=0005 Vendor=05ac Product=030c Version=0200
> > I'm running Gentoo, vanilla 2.6.29 with no patches.
> I have no idea whether the inversion is correct or not. Or where the
> information comes from :).
> It was added in
> cb3fecc2f29056e89658e7eb371e7f9be66cda6d
> by Jiri Kosina, maybe he may shed some light on it?

I created this patch based solely on a bugreport, I didn't physically own 
the hardware at that time.

I think I have it somewhere. I will try to find it tomorrow or the day 
after tomorrow and verify whether the quirk is really needed. Maybe the 
original bug reporter messed up, or he had different hardware revision.

-- 
Jiri Kosina
SUSE Labs

Re: Apple Wireless Mighty Mouse HWheel quirk

[J.R. Mauro]

On Tue, Apr 14, 2009 at 5:09 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 14 Apr 2009, Jiri Slaby wrote:
>
>> > I have an Apple bluetooth mouse (info below) and have noticed that the
>> > horizontal scrolling is inverted. I've noticed some bug reports from
>> > others getting the same behavior. I looked at drivers/hid/hid-apple.c
>> > , and around line 444 I see that APPLE_INVERT_HWHEEL gets ORed in. I
>> > tried to trace the origins of the code, but I lost track of it before
>> > 8c19a515, where you moved Apple quirks to their own file. Is this
>> > quirk definitely correct?
>> > Mouse's entry in /proc/bus/input/devices
>> > I: Bus=0005 Vendor=05ac Product=030c Version=0200
>> > I'm running Gentoo, vanilla 2.6.29 with no patches.
>> I have no idea whether the inversion is correct or not. Or where the
>> information comes from :).
>> It was added in
>> cb3fecc2f29056e89658e7eb371e7f9be66cda6d
>> by Jiri Kosina, maybe he may shed some light on it?
>
> I created this patch based solely on a bugreport, I didn't physically own
> the hardware at that time.
>
> I think I have it somewhere. I will try to find it tomorrow or the day
> after tomorrow and verify whether the quirk is really needed. Maybe the
> original bug reporter messed up, or he had different hardware revision.
>
> --
> Jiri Kosina
> SUSE Labs
>

Just for reference, it seems that other people have been having the
same problems, and finger the same quirk:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291408

Thanks for looking into this.

Re: Apple Wireless Mighty Mouse HWheel quirk

[Jiri Slaby]

On 04/14/2009 11:09 PM, Jiri Kosina wrote:
> On Tue, 14 Apr 2009, Jiri Slaby wrote:
> 
>>> I have an Apple bluetooth mouse (info below) and have noticed that the 
>>> horizontal scrolling is inverted. I've noticed some bug reports from 
>>> others getting the same behavior. I looked at drivers/hid/hid-apple.c 
>>> , and around line 444 I see that APPLE_INVERT_HWHEEL gets ORed in. I 
>>> tried to trace the origins of the code, but I lost track of it before 
>>> 8c19a515, where you moved Apple quirks to their own file. Is this 
>>> quirk definitely correct?
>>> Mouse's entry in /proc/bus/input/devices
>>> I: Bus=0005 Vendor=05ac Product=030c Version=0200
>>> I'm running Gentoo, vanilla 2.6.29 with no patches.
>> I have no idea whether the inversion is correct or not. Or where the
>> information comes from :).
>> It was added in
>> cb3fecc2f29056e89658e7eb371e7f9be66cda6d
>> by Jiri Kosina, maybe he may shed some light on it?
> 
> I created this patch based solely on a bugreport, I didn't physically own 
> the hardware at that time.
> 
> I think I have it somewhere. I will try to find it tomorrow or the day 
> after tomorrow and verify whether the quirk is really needed. Maybe the 
> original bug reporter messed up, or he had different hardware revision.

Any news here?

I think this is what you hit too, Andres?


Interesting part from the Andres' email follows:

I have an Apple Mighty Mouse. This is how it looks with 'cat
/proc/bus/input/devices'

I: Bus=0005 Vendor=05ac Product=030c Version=0200
N: Name="Mighty Mouse"

And the trackball on it has it x axis inverted.

Ive searched about this problem and found a Linux kernel mailing list
conversation where this error maybe had raised. A guy but a similar
mouse (also a mightymouse), but different ID (0x1000 instead of 0x030c),
was told to invert the x axis in order to have his 0x1000 mighty mouse
working with the wrong ID: 0x030c instead of adding a while new device.
Probably, inverting the trackball for the rest of us with the right id.

I will quote the mailing list post to you:

> As a newbie, I just saw your email in the source-file when I was looking
> into the sources of hid-apple.c to find my mighty mouse somewhere:
>
> /* Apple wireless Mighty Mouse */
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c),
> .driver_data = APPLE_MIGHTYMOUSE | APPLE_INVERT_HWHEEL },
>
> According to hid-ids.h, the ID 0x030c is a TDK mighty mouse. On my
> Alu-iMac (last year edition), it's a Apple's owned mighty mouse (vendor
> 0x05ac, ID 0x1000), which is not currently listed in hid-ids.h. My
> mighty mouse anyway runs o.k. with the "wrong" ID, but since the start
> withouth the mouse-wheel.
> It did not help when I changed the ID's accordingly. So my question is:
> Is there anything to be done in bluetooth driver area too to get this
> mighty mouse fully supported (some quirks needed)?

Re: Apple Wireless Mighty Mouse HWheel quirk

[Bastien Nocera]

On Tue, 2009-06-09 at 23:26 +0200, Jiri Slaby wrote:
> On 04/14/2009 11:09 PM, Jiri Kosina wrote:
> > On Tue, 14 Apr 2009, Jiri Slaby wrote:
> > 
> >>> I have an Apple bluetooth mouse (info below) and have noticed that the 
> >>> horizontal scrolling is inverted. I've noticed some bug reports from 
> >>> others getting the same behavior. I looked at drivers/hid/hid-apple.c 
> >>> , and around line 444 I see that APPLE_INVERT_HWHEEL gets ORed in. I 
> >>> tried to trace the origins of the code, but I lost track of it before 
> >>> 8c19a515, where you moved Apple quirks to their own file. Is this 
> >>> quirk definitely correct?
> >>> Mouse's entry in /proc/bus/input/devices
> >>> I: Bus=0005 Vendor=05ac Product=030c Version=0200
> >>> I'm running Gentoo, vanilla 2.6.29 with no patches.
> >> I have no idea whether the inversion is correct or not. Or where the
> >> information comes from :).
> >> It was added in
> >> cb3fecc2f29056e89658e7eb371e7f9be66cda6d
> >> by Jiri Kosina, maybe he may shed some light on it?
> > 
> > I created this patch based solely on a bugreport, I didn't physically own 
> > the hardware at that time.
> > 
> > I think I have it somewhere. I will try to find it tomorrow or the day 
> > after tomorrow and verify whether the quirk is really needed. Maybe the 
> > original bug reporter messed up, or he had different hardware revision.
> 
> Any news here?
> 
> I think this is what you hit too, Andres?
> 
> 
> Interesting part from the Andres' email follows:
> 
> I have an Apple Mighty Mouse. This is how it looks with 'cat
> /proc/bus/input/devices'
> 
> I: Bus=0005 Vendor=05ac Product=030c Version=0200
> N: Name="Mighty Mouse"
> 
> And the trackball on it has it x axis inverted.

Same here, this is the info:
I: Bus=0005 Vendor=05ac Product=030c Version=0200
N: Name="Mighty Mouse"
P: Phys=00:13:EF:F1:42:B7
S:
Sysfs=/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/bluetooth/hci0/hci0:46/input11
U: Uniq=00:14:51:D1:69:ED
H: Handlers=mouse2 event7 
B: EV=100017
B: KEY=f0000 0 0 0 0
B: REL=143
B: MSC=10

Re: Apple Wireless Mighty Mouse HWheel quirk

[Jiri Kosina]

On Tue, 9 Jun 2009, Jiri Slaby wrote:

> I have an Apple Mighty Mouse. This is how it looks with 'cat
> /proc/bus/input/devices'
> 
> I: Bus=0005 Vendor=05ac Product=030c Version=0200
> N: Name="Mighty Mouse"
> 
> And the trackball on it has it x axis inverted.

OK, so the 0x030c quirk is apparently bogus, as we have multiple 
complaints about it, and the original reporter doesn't respond anymore. I 
will just remove the wrong quirk now. Thanks to everyone for letting me 
know.

> Ive searched about this problem and found a Linux kernel mailing list 
> conversation where this error maybe had raised. A guy but a similar 
> mouse (also a mightymouse), but different ID (0x1000 instead of 0x030c), 
> was told to invert the x axis in order to have his 0x1000 mighty mouse 
> working with the wrong ID: 0x030c instead of adding a while new device. 
> Probably, inverting the trackball for the rest of us with the right id.
> 
> I will quote the mailing list post to you:
> 
> > As a newbie, I just saw your email in the source-file when I was looking
> > into the sources of hid-apple.c to find my mighty mouse somewhere:
> >
> > /* Apple wireless Mighty Mouse */
> > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c),
> > .driver_data = APPLE_MIGHTYMOUSE | APPLE_INVERT_HWHEEL },
> >
> > According to hid-ids.h, the ID 0x030c is a TDK mighty mouse. On my
> > Alu-iMac (last year edition), it's a Apple's owned mighty mouse (vendor
> > 0x05ac, ID 0x1000), which is not currently listed in hid-ids.h. My
> > mighty mouse anyway runs o.k. with the "wrong" ID, but since the start
> > withouth the mouse-wheel.
> > It did not help when I changed the ID's accordingly. So my question is:
> > Is there anything to be done in bluetooth driver area too to get this
> > mighty mouse fully supported (some quirks needed)?

Yes, 0x1000 is a different problem, the scrollwheel doesn't work there at 
all (it isn't even described in the report descriptor).

I currently have 0x05ac/0x1000 on my desk, I will look into it.

-- 
Jiri Kosina
SUSE Labs

Re: Apple Wireless Mighty Mouse HWheel quirk

[Jiri Kosina]

On Wed, 10 Jun 2009, Jiri Kosina wrote:

> > > According to hid-ids.h, the ID 0x030c is a TDK mighty mouse. On my
> > > Alu-iMac (last year edition), it's a Apple's owned mighty mouse (vendor
> > > 0x05ac, ID 0x1000), which is not currently listed in hid-ids.h. My
> > > mighty mouse anyway runs o.k. with the "wrong" ID, but since the start
> > > withouth the mouse-wheel.
> > > It did not help when I changed the ID's accordingly. So my question is:
> > > Is there anything to be done in bluetooth driver area too to get this
> > > mighty mouse fully supported (some quirks needed)?
> Yes, 0x1000 is a different problem, the scrollwheel doesn't work there at 
> all (it isn't even described in the report descriptor).
> I currently have 0x05ac/0x1000 on my desk, I will look into it.

Unfortunately I don't have, it's a slightly different model, for which the 
scrollwheel works nicely.

So HID debugging output from 0x1000, both from the time the mouse is 
probed and when the non-working wheel is used would be welcome.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Apple Wireless Mighty Mouse HWheel quirk

[Jiri Kosina]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 704 bytes --]

On Wed, 10 Jun 2009, Andrés León Álvarez wrote:

> Off course, I think none of us really know about the other model of 
> mouse, so it might be unresponsible keeping the 0x1000 (I don't know if 
> a mouse can work "fine" with a different ID, for example). But so far, 
> it seems that removing the quirk for the 0x030c will solve the only 
> problem that the 0x1000 rise.

There are two separate issues

- quirk we have for 0x030c is apparently bogus, and will be removed, 
  bringing axes orientation to the expected state
- 0x1000 has a completely different problem -- scrollwheel doesn't work at 
  all, and will need some special handling that has still to be discovered

-- 
Jiri Kosina
SUSE Labs