Bug 4229
Summary: | A4Tech RP649Z mouse's second wheel does not work | ||
---|---|---|---|
Product: | Drivers | Reporter: | Patola (patolinux) |
Component: | Input Devices | Assignee: | Dmitry Torokhov (dmitry.torokhov) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | nacc, protasnb, vojtech |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.10 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
Output from usbmon when plugging in the mouse
Preliminary patch to show what I'm talking about |
Description
Patola
2005-02-19 06:47:44 UTC
My god, 3 months open and not yet a single commentary, not even a status change. I certainly don't expect too much, but isn't this unbearably few? I mean, c'mon!!! If you don't make this stuff work, go home and say you won't fix it, that would be more honest. I just realized I had wasted my time pasting all these comments. I've bought such a mouse now. From the usbmon output it appears that the mouse sends five-byte packets. The first four bytes are buttons, X, Y, and Z. The fifth is set to 8 if Z refers to the second (horizontal) wheel, otherwise 0. That would explain why horizontal wheel motion is interpreted as a REL_WHEEL event of +/- 1 together with a REL_MISC event of 8. Created attachment 8602 [details]
Output from usbmon when plugging in the mouse
Can someone help interpret this data?
Comment on attachment 8602 [details]
Output from usbmon when plugging in the mouse
Ah, whatever. The truth is this: the mouse reports a relative input with usage
0x000100b8. It should be analogous to HID_QUIRK_2WHEEL_MOUSE_HACK_5 and _7,
which use button 5 and 7, respectively, to signal that the horizontal wheel is
the one that turned, and not the vertical one. There is just one big
difference: The buttons field comes *before* the relatives field, but the b8
input comes *after* the wheel input. Since all inputs are reported in order as
separate events from hid-core.c, it looks like hid_input_field() has to be
modified to implement this quirk.
Created attachment 8603 [details]
Preliminary patch to show what I'm talking about
Some remaining questions:
Do all mice with the same device id (09da:001a) have this GenericDesktop.00b8
input? (I.e. do models with just one wheel have a different device id, and if
they don't, do they still send GenericDesktop.00b8 always set to 0?
What should the device id constant be called? Where does "WCP32PU" come from?
How is the new kernel working for you? It's been a lot of fixes/updates to the subsystem since. Thanks. I don't think the patch ever been submitted/reviewed. Would someone like to submit it to lkml? |