multi-input quirk and skip output reports quirk

DISCUSSION Anssi Hannula 2 participants 8 messages Apr 1, 2008 – Apr 6, 2008

Subsystems (2)

HID USB HID/hidbp drivers (USB keyboards, mice, remote controls, ...)

lore

Share & tools

lore

Anssi Hannula

author

2008-04-01 11:25 UTC #0 lore raw

Hi!

I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866.

However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?

Signature · 1 line

Anssi Hannula

Jiri Kosina

2008-04-01 14:12 UTC #1 lore raw

Quoted 6 lines · Anssi Hannula

I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?

Hi Anssi,

as long as we still have the possibility to see the coming data in debug mode, I don't have objection to that.

Are you going to make that patch?

Thanks,

Signature · 1 line

Jiri Kosina

Anssi Hannula

author

2008-04-01 14:15 UTC #2 lore raw

Quoted 9 lines · Jiri Kosina

Quoted 6 lines · Anssi Hannula
I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?

Quoted 4 lines

Hi Anssi,
as long as we still have the possibility to see the coming data in debug mode, I don't have objection to that.

Okay.

Quoted 1 line

Are you going to make that patch?

Not right now, maybe in a few weeks.

Signature · 1 line

Anssi Hannula

Jiri Kosina

2008-04-04 14:37 UTC #3 lore raw

Quoted 11 lines · Anssi Hannula

Quoted 8 lines
Quoted 6 lines
I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?
as long as we still have the possibility to see the coming data in debug mode, I don't have objection to that.
Okay.
Quoted 1 line
Are you going to make that patch?
Not right now, maybe in a few weeks.

I will meanwhile queue the patch below, ok? After the hidinput_connect() is refactored to ignore devices for which the mappings haven't been established, we could then remove all the devices for which we have HID_QUIRK_SKIP_OUTPUT_REPORTS altogether.

BTW, do you happen to have any idea whether the Quad joypad needs this quirk too?

Thanks.

From: Jiri Kosina <[email protected]>
Subject: HID: WiseGroup 866 Dual Joypad needs output reports quirk

WiseGroup Ltd, MP-8866 Dual Joypad needs to skip output reports, as it contains force-feedback output reports.

Reported-by Anssi Hannula <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

drivers/hid/usbhid/hid-quirks.c +1 -1

index a104d1e..ff6fadc 100644
@@ -606,7 +606,7 @@ static const struct hid_blacklist {
 	{ USB_VENDOR_ID_PETALYNX, USB_DEVICE_ID_PETALYNX_MAXTER_REMOTE, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_SUN, USB_DEVICE_ID_RARITAN_KVM_DONGLE, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_TURBOX_KEYBOARD, HID_QUIRK_NOGET },
-	{ USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_DUAL_USB_JOYPAD, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
+	{ USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_DUAL_USB_JOYPAD, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT | HID_QUIRK_SKIP_OUTPUT_REPORTS },
 	{ USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_QUAD_USB_JOYPAD, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 
 	{ USB_VENDOR_ID_WISEGROUP_LTD, USB_DEVICE_ID_SMARTJOY_DUAL_PLUS, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },

Anssi Hannula

author

2008-04-04 14:40 UTC #4 lore raw

Quoted 10 lines · Jiri Kosina

Quoted 8 lines · Anssi Hannula
Quoted 8 lines
Quoted 6 lines
I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?
as long as we still have the possibility to see the coming data in debug mode, I don't have objection to that.

Quoted 8 lines

Quoted 3 lines
Okay.
Quoted 1 line
Are you going to make that patch?
Not right now, maybe in a few weeks.
I will meanwhile queue the patch below, ok? After the hidinput_connect() is refactored to ignore devices for which the mappings haven't been established, we could then remove all the devices for which we have HID_QUIRK_SKIP_OUTPUT_REPORTS altogether.

Ok.

Quoted 2 lines

BTW, do you happen to have any idea whether the Quad joypad needs this quirk too?

No, but I guess it is quite probable.

Quoted 2 lines

Thanks.

Signature · 1 line

Anssi Hannula

Jiri Kosina

2008-04-04 14:51 UTC #5 lore raw

Quoted 11 lines · Anssi Hannula

Quoted 11 lines
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines
I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?
as long as we still have the possibility to see the coming data in debug mode, I don't have objection to that.
Okay.
Quoted 1 line
Are you going to make that patch?
Not right now, maybe in a few weeks.

Quoted 8 lines

Quoted 4 lines
I will meanwhile queue the patch below, ok? After the hidinput_connect() is refactored to ignore devices for which the mappings haven't been established, we could then remove all the devices for which we have HID_QUIRK_SKIP_OUTPUT_REPORTS altogether.
Ok.
Quoted 2 lines
BTW, do you happen to have any idea whether the Quad joypad needs this quirk too?
No, but I guess it is quite probable.

I have added Sam (who reported the need of the quirk for Quad joypad) to CC.

Sam?

Thanks,

Signature · 2 lines

Jiri Kosina
SUSE Labs

Jiri Kosina

2008-04-06 08:06 UTC #6 lore raw

In reply to Anssi Hannula

Quoted 6 lines · Anssi Hannula

I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?

Oh, and I seem to have completely forgotten -- is this quirk needed at all? Since commit 82eb12198 we ignore the non-LED output reports in hidinput_configure_usages() altogether.

Do you still actually see issues of devices being misconfigured due to output reports confusion in hidinput_configure_usage() even in kernels having this commit included?

Thanks,

Signature · 2 lines

Jiri Kosina
SUSE Labs

Anssi Hannula

author

2008-04-06 14:12 UTC #7 lore raw

Quoted 9 lines · Jiri Kosina

Quoted 6 lines · Anssi Hannula
I've encountered another multi-input device that needs the skip output reports quirk (as it contains force feedback output reports), 0925:8866. However, maybe we should use another approach, dropping HID_QUIRK_SKIP_OUTPUT_REPORTS. Why not just *not* register the input device for that report in case the report didn't contain anything that was mapped by hidinput_configure_usage(), in hidinput_connect()?

Quoted 7 lines

Oh, and I seem to have completely forgotten -- is this quirk needed at all? Since commit 82eb12198 we ignore the non-LED output reports in hidinput_configure_usages() altogether.
Do you still actually see issues of devices being misconfigured due to output reports confusion in hidinput_configure_usage() even in kernels having this commit included?

Yes.

The point was that hidinput_connect() doesn't care whether all reports were ignored by hidinput_configure_usage() or not.

Signature · 1 line

Anssi Hannula