[v2] HID: input: fix a4tech horizontal wheel custom usage
diff mbox series

Message ID 20190611121320.30267-1-nsaenzjulienne@suse.de
State Mainlined
Commit 1c703b53e5bfb5c2205c30f0fb157ce271fd42fb
Delegated to: Jiri Kosina
Headers show
Series
  • [v2] HID: input: fix a4tech horizontal wheel custom usage
Related show

Commit Message

Nicolas Saenz Julienne June 11, 2019, 12:13 p.m. UTC
Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
the previous wheel report was horizontal or vertical. Before
c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
usage was being mapped to 'Relative.Misc'. After the patch it's simply
ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
usage->type.

We shouldn't rely on a mapping for that usage as it's nonstandard and
doesn't really map to an input event. So we bypass the mapping and make
sure the custom event handling properly handles both reports.

Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---

NOTE: I CC'd Wolfgang as he's the one who can test this.

Changes since v1:
  - new approach, moved fix into hid-a4tech

 drivers/hid/hid-a4tech.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

Comments

Benjamin Tissoires June 11, 2019, 2:42 p.m. UTC | #1
On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage was being mapped to 'Relative.Misc'. After the patch it's simply
> ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
> hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
> usage->type.
>
> We shouldn't rely on a mapping for that usage as it's nonstandard and
> doesn't really map to an input event. So we bypass the mapping and make
> sure the custom event handling properly handles both reports.
>
> Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---

Yep, I like this one much better.

>
> NOTE: I CC'd Wolfgang as he's the one who can test this.

I'll wait for Wolfram to confirm that the patch works before pushing then.

>
> Changes since v1:
>   - new approach, moved fix into hid-a4tech
>
>  drivers/hid/hid-a4tech.c | 30 +++++++++++++++++++++++++++---
>  1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
> index 98bf694626f7..3a8c4a5971f7 100644
> --- a/drivers/hid/hid-a4tech.c
> +++ b/drivers/hid/hid-a4tech.c
> @@ -23,12 +23,36 @@
>  #define A4_2WHEEL_MOUSE_HACK_7 0x01
>  #define A4_2WHEEL_MOUSE_HACK_B8        0x02
>
> +#define A4_WHEEL_ORIENTATION   (HID_UP_GENDESK | 0x000000b8)
> +
>  struct a4tech_sc {
>         unsigned long quirks;
>         unsigned int hw_wheel;
>         __s32 delayed_value;
>  };
>
> +static int a4_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> +                           struct hid_field *field, struct hid_usage *usage,
> +                           unsigned long **bit, int *max)
> +{
> +       struct a4tech_sc *a4 = hid_get_drvdata(hdev);
> +
> +       if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8 &&
> +           usage->hid == A4_WHEEL_ORIENTATION) {
> +               /*
> +                * We do not want to have this usage mapped to anything as it's
> +                * nonstandard and doesn't really behave like an HID report.
> +                * It's only selecting the orientation (vertical/horizontal) of
> +                * the previous mouse wheel report. The input_events will be
> +                * generated once both reports are recorded in a4_event().
> +                */
> +               return -1;

You seem to be extra precocious here. This is basically what the
current hid-input.c mapping does. But I think it is for the best,
given that this time you are locking the behavior of this reserved
usage.

Cheers,
Benjamin

> +       }
> +
> +       return 0;
> +
> +}
> +
>  static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
>                 struct hid_field *field, struct hid_usage *usage,
>                 unsigned long **bit, int *max)
> @@ -52,8 +76,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
>         struct a4tech_sc *a4 = hid_get_drvdata(hdev);
>         struct input_dev *input;
>
> -       if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
> -                       !usage->type)
> +       if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput)
>                 return 0;
>
>         input = field->hidinput->input;
> @@ -64,7 +87,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
>                         return 1;
>                 }
>
> -               if (usage->hid == 0x000100b8) {
> +               if (usage->hid == A4_WHEEL_ORIENTATION) {
>                         input_event(input, EV_REL, value ? REL_HWHEEL :
>                                         REL_WHEEL, a4->delayed_value);
>                         input_event(input, EV_REL, value ? REL_HWHEEL_HI_RES :
> @@ -131,6 +154,7 @@ MODULE_DEVICE_TABLE(hid, a4_devices);
>  static struct hid_driver a4_driver = {
>         .name = "a4tech",
>         .id_table = a4_devices,
> +       .input_mapping = a4_input_mapping,
>         .input_mapped = a4_input_mapped,
>         .event = a4_event,
>         .probe = a4_probe,
> --
> 2.21.0
>
Wolfgang Bauer June 13, 2019, 11:48 a.m. UTC | #2
On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> 
> <nsaenzjulienne@suse.de> wrote:
> > NOTE: I CC'd Wolfgang as he's the one who can test this.
> 
> I'll wait for Wolfram to confirm that the patch works before pushing then.

My name is Wolfgang, not Wolfram... ;-)
But never mind.

I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse wheel 
actually worked.
As the patch didn't apply cleanly (it's obviously based upon 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abf82e8f7e9af40a49e3d905187c662a43c96c8f , called "HID-
a4tech-fix-horizontal-scrolling.patch" below), I added that patch as well.

My results:
kernel 5.2.rc4 works
kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch is broken
kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch +
HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch (i.e. this patch) 
works again

kernel 5.2.rc4 + HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch 
works as well.

So AFAICT this patch seems to be fine.

For completeness, this is my mouse as listed by lsusb:
Bus 003 Device 002: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D / 
OP-620D

Kind Regards,
Wolfgang
Wolfgang Bauer June 14, 2019, noon UTC | #3
I tested linux-next (20190612) meanwhile as well.
My mouse wheel doesn't work with that kernel, this patch fixes it.

Kind Regards,
Wolfgang
Benjamin Tissoires June 14, 2019, 1:36 p.m. UTC | #4
Hi Wolfgang,

On Thu, Jun 13, 2019 at 1:49 PM Wolfgang Bauer <wbauer@tmo.at> wrote:
>
> On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> > On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> >
> > <nsaenzjulienne@suse.de> wrote:
> > > NOTE: I CC'd Wolfgang as he's the one who can test this.
> >
> > I'll wait for Wolfram to confirm that the patch works before pushing then.
>
> My name is Wolfgang, not Wolfram... ;-)

ouch, sorry for that (I am more used to talk to the I2C maintainer apparently)

> But never mind.
>
> I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse wheel
> actually worked.

Actually, I am a little bit lost here.

The patch mentions a fix of c01908a14bf73, which is in 5.1 final.
So if your mouse works in 5.2.rc4, I am not sure how
HID-a4tech-fix-horizontal-scrolling.patch could break it.

Could you be slightly more specific in what "works" and what doesn't?

Do we have the report descriptors available somewhere?
And if not, could you run hid-recorder from
https://gitlab.freedesktop.org/libevdev/hid-tools and attach the logs
when you move the horizontal wheel?

Cheers,
Benjamin

> As the patch didn't apply cleanly (it's obviously based upon
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abf82e8f7e9af40a49e3d905187c662a43c96c8f , called "HID-
> a4tech-fix-horizontal-scrolling.patch" below), I added that patch as well.
>
> My results:
> kernel 5.2.rc4 works
> kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch is broken
> kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch +
> HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch (i.e. this patch)
> works again
>
> kernel 5.2.rc4 + HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch
> works as well.
>
> So AFAICT this patch seems to be fine.
>
> For completeness, this is my mouse as listed by lsusb:
> Bus 003 Device 002: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D /
> OP-620D
>
> Kind Regards,
> Wolfgang
>
Nicolas Saenz Julienne June 14, 2019, 2:25 p.m. UTC | #5
On Fri, 2019-06-14 at 15:36 +0200, Benjamin Tissoires wrote:
> Hi Wolfgang,
> 
> On Thu, Jun 13, 2019 at 1:49 PM Wolfgang Bauer <wbauer@tmo.at> wrote:
> > On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> > > On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> > > 
> > > <nsaenzjulienne@suse.de> wrote:
> > > > NOTE: I CC'd Wolfgang as he's the one who can test this.
> > > 
> > > I'll wait for Wolfram to confirm that the patch works before pushing then.
> > 
> > My name is Wolfgang, not Wolfram... ;-)
> 
> ouch, sorry for that (I am more used to talk to the I2C maintainer apparently)
> 
> > But never mind.
> > 
> > I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse wheel
> > actually worked.
> 
> Actually, I am a little bit lost here.
>
> The patch mentions a fix of c01908a14bf73, which is in 5.1 final.
> So if your mouse works in 5.2.rc4, I am not sure how
> HID-a4tech-fix-horizontal-scrolling.patch could break it.
> 
> Could you be slightly more specific in what "works" and what doesn't?

Hi Benjamin,

First of all here's the descriptor:
0x05, 0x01, /*  Usage Page (Desktop),               */
0x09, 0x02, /*  Usage (Mouse),                      */
0xA1, 0x01, /*  Collection (Application),           */
0x09, 0x01, /*      Usage (Pointer),                */
0xA1, 0x00, /*      Collection (Physical),          */
0x05, 0x09, /*          Usage Page (Button),        */
0x19, 0x01, /*          Usage Minimum (01h),        */
0x29, 0x08, /*          Usage Maximum (08h),        */
0x15, 0x00, /*          Logical Minimum (0),        */
0x25, 0x01, /*          Logical Maximum (1),        */
0x75, 0x01, /*          Report Size (1),            */
0x95, 0x08, /*          Report Count (8),           */
0x81, 0x02, /*          Input (Variable),           */
0x05, 0x01, /*          Usage Page (Desktop),       */
0x09, 0x30, /*          Usage (X),                  */
0x09, 0x31, /*          Usage (Y),                  */
0x09, 0x38, /*          Usage (Wheel),              */
0x09, 0xB8, /*          Usage (B8h),                */
0x15, 0x81, /*          Logical Minimum (-127),     */
0x25, 0x7F, /*          Logical Maximum (127),      */
0x75, 0x08, /*          Report Size (8),            */
0x95, 0x04, /*          Report Count (4),           */
0x81, 0x06, /*          Input (Variable, Relative), */
0xC0,       /*      End Collection,                 */
0xC0        /*  End Collection


Sorry for the confusion, I'll try to explain the situation:

In v5.2-rc4 without "HID-a4tech-fix-horizontal-scrolling.patch" the vertical
wheel works out of luck as it's mapped to REL_WHEEL_HIGH_RES, which hid-a4tech
ignores and lets hid-input process, the horizontal wheel is broken. On top of
that Usage(0xB8) is also ignored by both hid-a4tech and hid-input as it isn't
mapped to anything.

There are two distinct bugs here:
  - High resolution wheel processing in hid-a4tech not being implemented,
    breaking horizontal wheels.
  - hid-a4tech not taking care of Usage(0xB8) correctly as it depended on it
    being mapped to "Rel.Misc". That behaviour changed in v5.1 with "HID:
    input: add mapping for "Toggle Display" key".

Once high resolution wheel reports are fixed and handled in hid-a4tech's custom
event, the mouse breaks as it's the processing of Usage(0xB8) that triggers the
input_events, which is being ignored.

You'll probably ask how come we didn't see this when
"HID-a4tech-fix-horizontal-scrolling.patch" was merged. It's due to the fact it
was tested on an older kernel, v5.0.15, that didn't contain "HID: input: add
mapping for "Toggle Display" key"[1].

So that's why I added that specific fix tag. For LTS kernels, it is possible
that "Toggle Display" support was back-ported but not the high resolution
wheels support.

Hope it made things more clear.
Regards,
Nicolas

[1] 
https://lkml.kernel.org/lkml/nycvar.YFH.7.76.1906010028440.1962@cbobk.fhfr.pm/T/

> 
> Do we have the report descriptors available somewhere?
> And if not, could you run hid-recorder from
> https://gitlab.freedesktop.org/libevdev/hid-tools and attach the logs
> when you move the horizontal wheel?
> 
> Cheers,
> Benjamin
> 
> > As the patch didn't apply cleanly (it's obviously based upon
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abf82e8f7e9af40a49e3d905187c662a43c96c8f
, called
> > "HID-
> > a4tech-fix-horizontal-scrolling.patch" below), I added that patch as well.
> > 
> > My results:
> > kernel 5.2.rc4 works
> > kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch is broken
> > kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch +
> > HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch (i.e. this patch)
> > works again
> > 
> > kernel 5.2.rc4 + HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch
> > works as well.
> > 
> > So AFAICT this patch seems to be fine.
> > 
> > For completeness, this is my mouse as listed by lsusb:
> > Bus 003 Device 002: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D /
> > OP-620D
> > 
> > Kind Regards,
> > Wolfgang
> >
Nicolas Saenz Julienne July 5, 2019, 10:28 a.m. UTC | #6
On Fri, 2019-06-14 at 16:25 +0200, Nicolas Saenz Julienne wrote:
> On Fri, 2019-06-14 at 15:36 +0200, Benjamin Tissoires wrote:
> > Hi Wolfgang,
> > 
> > On Thu, Jun 13, 2019 at 1:49 PM Wolfgang Bauer <wbauer@tmo.at> wrote:
> > > On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> > > > On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> > > > 
> > > > <nsaenzjulienne@suse.de> wrote:
> > > > > NOTE: I CC'd Wolfgang as he's the one who can test this.
> > > > 
> > > > I'll wait for Wolfram to confirm that the patch works before pushing
> > > > then.
> > > 
> > > My name is Wolfgang, not Wolfram... ;-)
> > 
> > ouch, sorry for that (I am more used to talk to the I2C maintainer
> > apparently)
> > 
> > > But never mind.
> > > 
> > > I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse
> > > wheel
> > > actually worked.
> > 
> > Actually, I am a little bit lost here.
> > 
> > The patch mentions a fix of c01908a14bf73, which is in 5.1 final.
> > So if your mouse works in 5.2.rc4, I am not sure how
> > HID-a4tech-fix-horizontal-scrolling.patch could break it.
> > 
> > Could you be slightly more specific in what "works" and what doesn't?
> 
> Hi Benjamin,
> 
> First of all here's the descriptor:
> 0x05, 0x01, /*  Usage Page (Desktop),               */
> 0x09, 0x02, /*  Usage (Mouse),                      */
> 0xA1, 0x01, /*  Collection (Application),           */
> 0x09, 0x01, /*      Usage (Pointer),                */
> 0xA1, 0x00, /*      Collection (Physical),          */
> 0x05, 0x09, /*          Usage Page (Button),        */
> 0x19, 0x01, /*          Usage Minimum (01h),        */
> 0x29, 0x08, /*          Usage Maximum (08h),        */
> 0x15, 0x00, /*          Logical Minimum (0),        */
> 0x25, 0x01, /*          Logical Maximum (1),        */
> 0x75, 0x01, /*          Report Size (1),            */
> 0x95, 0x08, /*          Report Count (8),           */
> 0x81, 0x02, /*          Input (Variable),           */
> 0x05, 0x01, /*          Usage Page (Desktop),       */
> 0x09, 0x30, /*          Usage (X),                  */
> 0x09, 0x31, /*          Usage (Y),                  */
> 0x09, 0x38, /*          Usage (Wheel),              */
> 0x09, 0xB8, /*          Usage (B8h),                */
> 0x15, 0x81, /*          Logical Minimum (-127),     */
> 0x25, 0x7F, /*          Logical Maximum (127),      */
> 0x75, 0x08, /*          Report Size (8),            */
> 0x95, 0x04, /*          Report Count (4),           */
> 0x81, 0x06, /*          Input (Variable, Relative), */
> 0xC0,       /*      End Collection,                 */
> 0xC0        /*  End Collection
> 
> 
> Sorry for the confusion, I'll try to explain the situation:
> 
> In v5.2-rc4 without "HID-a4tech-fix-horizontal-scrolling.patch" the vertical
> wheel works out of luck as it's mapped to REL_WHEEL_HIGH_RES, which hid-a4tech
> ignores and lets hid-input process, the horizontal wheel is broken. On top of
> that Usage(0xB8) is also ignored by both hid-a4tech and hid-input as it isn't
> mapped to anything.
> 
> There are two distinct bugs here:
>   - High resolution wheel processing in hid-a4tech not being implemented,
>     breaking horizontal wheels.
>   - hid-a4tech not taking care of Usage(0xB8) correctly as it depended on it
>     being mapped to "Rel.Misc". That behaviour changed in v5.1 with "HID:
>     input: add mapping for "Toggle Display" key".
> 
> Once high resolution wheel reports are fixed and handled in hid-a4tech's
> custom
> event, the mouse breaks as it's the processing of Usage(0xB8) that triggers
> the
> input_events, which is being ignored.
> 
> You'll probably ask how come we didn't see this when
> "HID-a4tech-fix-horizontal-scrolling.patch" was merged. It's due to the fact
> it
> was tested on an older kernel, v5.0.15, that didn't contain "HID: input: add
> mapping for "Toggle Display" key"[1].
> 
> So that's why I added that specific fix tag. For LTS kernels, it is possible
> that "Toggle Display" support was back-ported but not the high resolution
> wheels support.

Hi,
Any thoughts on this?

Regards,
Nicolas
Jeremy Cline July 18, 2019, 3:46 p.m. UTC | #7
On Fri, Jun 14, 2019 at 03:36:03PM +0200, Benjamin Tissoires wrote:
> Hi Wolfgang,
> 
> On Thu, Jun 13, 2019 at 1:49 PM Wolfgang Bauer <wbauer@tmo.at> wrote:
> >
> > On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> > > On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> > >
> > > <nsaenzjulienne@suse.de> wrote:
> > > > NOTE: I CC'd Wolfgang as he's the one who can test this.
> > >
> > > I'll wait for Wolfram to confirm that the patch works before pushing then.
> >
> > My name is Wolfgang, not Wolfram... ;-)
> 
> ouch, sorry for that (I am more used to talk to the I2C maintainer apparently)
> 
> > But never mind.
> >
> > I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse wheel
> > actually worked.
> 
> Actually, I am a little bit lost here.
> 
> The patch mentions a fix of c01908a14bf73, which is in 5.1 final.
> So if your mouse works in 5.2.rc4, I am not sure how
> HID-a4tech-fix-horizontal-scrolling.patch could break it.
> 
> Could you be slightly more specific in what "works" and what doesn't?
> 

For what it's worth, at least one user has hit this issue in Fedora
starting on stable kernel v5.1.17[0] which has commit abf82e8f7e9a
("HID: a4tech: fix horizontal scrolling"). Applying this patch on top of
v5.1.18 fixed the issue for them.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1730762


Regards,
Jeremy
Nicolas Saenz Julienne Aug. 1, 2019, 10:56 a.m. UTC | #8
On Tue, 2019-06-11 at 14:13 +0200, Nicolas Saenz Julienne wrote:
> Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage was being mapped to 'Relative.Misc'. After the patch it's simply
> ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
> hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
> usage->type.
> 
> We shouldn't rely on a mapping for that usage as it's nonstandard and
> doesn't really map to an input event. So we bypass the mapping and make
> sure the custom event handling properly handles both reports.
> 
> Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---

It would be nice for this patch not to get lost. It fixes issues both repoted
on opensuse and fedora.

I can resubmit it if needed.

Regards,
Nicolas
Jiri Kosina Aug. 5, 2019, 12:38 p.m. UTC | #9
On Thu, 1 Aug 2019, Nicolas Saenz Julienne wrote:

> > Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> > the previous wheel report was horizontal or vertical. Before
> > c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> > usage was being mapped to 'Relative.Misc'. After the patch it's simply
> > ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
> > hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
> > usage->type.
> > 
> > We shouldn't rely on a mapping for that usage as it's nonstandard and
> > doesn't really map to an input event. So we bypass the mapping and make
> > sure the custom event handling properly handles both reports.
> > 
> > Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> 
> It would be nice for this patch not to get lost. It fixes issues both repoted
> on opensuse and fedora.

Sorry for the delay. I've now queued the patch. Thanks for fixing this,

Patch
diff mbox series

diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
index 98bf694626f7..3a8c4a5971f7 100644
--- a/drivers/hid/hid-a4tech.c
+++ b/drivers/hid/hid-a4tech.c
@@ -23,12 +23,36 @@ 
 #define A4_2WHEEL_MOUSE_HACK_7	0x01
 #define A4_2WHEEL_MOUSE_HACK_B8	0x02
 
+#define A4_WHEEL_ORIENTATION	(HID_UP_GENDESK | 0x000000b8)
+
 struct a4tech_sc {
 	unsigned long quirks;
 	unsigned int hw_wheel;
 	__s32 delayed_value;
 };
 
+static int a4_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+			    struct hid_field *field, struct hid_usage *usage,
+			    unsigned long **bit, int *max)
+{
+	struct a4tech_sc *a4 = hid_get_drvdata(hdev);
+
+	if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8 &&
+	    usage->hid == A4_WHEEL_ORIENTATION) {
+		/*
+		 * We do not want to have this usage mapped to anything as it's
+		 * nonstandard and doesn't really behave like an HID report.
+		 * It's only selecting the orientation (vertical/horizontal) of
+		 * the previous mouse wheel report. The input_events will be
+		 * generated once both reports are recorded in a4_event().
+		 */
+		return -1;
+	}
+
+	return 0;
+
+}
+
 static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
 		struct hid_field *field, struct hid_usage *usage,
 		unsigned long **bit, int *max)
@@ -52,8 +76,7 @@  static int a4_event(struct hid_device *hdev, struct hid_field *field,
 	struct a4tech_sc *a4 = hid_get_drvdata(hdev);
 	struct input_dev *input;
 
-	if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
-			!usage->type)
+	if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput)
 		return 0;
 
 	input = field->hidinput->input;
@@ -64,7 +87,7 @@  static int a4_event(struct hid_device *hdev, struct hid_field *field,
 			return 1;
 		}
 
-		if (usage->hid == 0x000100b8) {
+		if (usage->hid == A4_WHEEL_ORIENTATION) {
 			input_event(input, EV_REL, value ? REL_HWHEEL :
 					REL_WHEEL, a4->delayed_value);
 			input_event(input, EV_REL, value ? REL_HWHEEL_HI_RES :
@@ -131,6 +154,7 @@  MODULE_DEVICE_TABLE(hid, a4_devices);
 static struct hid_driver a4_driver = {
 	.name = "a4tech",
 	.id_table = a4_devices,
+	.input_mapping = a4_input_mapping,
 	.input_mapped = a4_input_mapped,
 	.event = a4_event,
 	.probe = a4_probe,