RE: multi-input quirk and skip output reports quirk

RE: multi-input quirk and skip output reports quirk

[Sam Liddicott]

I'm afraid I don't recognize that quirk name.

I'm all for setting quirks dynamically from user space during the plug event, as the delay between posting a patch and having it appear in distro of choice can be well over a year which is too long to remember and too long to be useful.

I do remember that there were two quirks set for the same brand of dual controller and I copied them both to the quad controller. I was asked to check if both quirks were actually needed, I still haven't had the required couple of hours to rebuild my kernel to do this and it became simpler to use the quad controller as a single controller.

I still feel guilty this but not guilty enough. Sorry.

Sam

-----Original Message-----
From: Jiri Kosina <jkosina@suse.cz>
Sent: 04 April 2008 15:51
To: Anssi Hannula <anssi.hannula@gmail.com>
Cc: linux-input@vger.kernel.org; Sam Liddicott <sam@liddicott.com>
Subject: Re: multi-input quirk and skip output reports quirk

On Fri, 4 Apr 2008, Anssi Hannula wrote:

> >>>> 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.
> >>> 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.
> > 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,

-- 
Jiri Kosina
SUSE Labs

RE: multi-input quirk and skip output reports quirk

[Jiri Kosina]

On Sat, 5 Apr 2008, Sam Liddicott wrote:

> I'm all for setting quirks dynamically from user space during the plug 
> event, as the delay between posting a patch and having it appear in 
> distro of choice can be well over a year which is too long to remember 
> and too long to be useful.

This can be done by using a 'quirks' module parameter to usbhid.

> I do remember that there were two quirks set for the same brand of dual 
> controller and I copied them both to the quad controller. I was asked to 
> check if both quirks were actually needed, I still haven't had the 
> required couple of hours to rebuild my kernel to do this and it became 
> simpler to use the quad controller as a single controller.

You don't have to rebuild if you have a kernel that supports dynamic 
quirks for usbhid.

-- 
Jiri Kosina
SUSE Labs

RE: multi-input quirk and skip output reports quirk

[Sam Liddicott]

Sor for top  posting - stinkin' pocket outlook (roll-on a linux keyboard phone)

I suppose the module parameter is nearly the same thing.

If you could tell me how to use it to set quirks for a usb id then I will check it in the next hour. I have a force-feedback controler but I don't know anything that uses it which could make the test hard...

If you can show me how to ass quirks for multipe devices than I will come up with a mechanism for distros that re-generates modprobe.d contents or whatever to combine a portable list of quirks. It will be easy to have the quirks file maintained and updated.

I hope I don't appear a total slacker but my brain is suffering from stack-full syndrome - sorry, and thanks.

Sam


-----Original Message-----
From: Jiri Kosina <jkosina@suse.cz>
Sent: 05 April 2008 07:01
To: Sam Liddicott <sam@liddicott.com>
Cc: Anssi Hannula <anssi.hannula@gmail.com>; linux-input@vger.kernel.org
Subject: RE: multi-input quirk and skip output reports quirk

On Sat, 5 Apr 2008, Sam Liddicott wrote:

> I'm all for setting quirks dynamically from user space during the plug 
> event, as the delay between posting a patch and having it appear in 
> distro of choice can be well over a year which is too long to remember 
> and too long to be useful.

This can be done by using a 'quirks' module parameter to usbhid.

> I do remember that there were two quirks set for the same brand of dual 
> controller and I copied them both to the quad controller. I was asked to 
> check if both quirks were actually needed, I still haven't had the 
> required couple of hours to rebuild my kernel to do this and it became 
> simpler to use the quad controller as a single controller.

You don't have to rebuild if you have a kernel that supports dynamic 
quirks for usbhid.

-- 
Jiri Kosina
SUSE Labs

multi-input quirk and skip output reports quirk

[Anssi Hannula]

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()?

-- 
Anssi Hannula

Re: multi-input quirk and skip output reports quirk

[Jiri Kosina]

On Tue, 1 Apr 2008, Anssi Hannula wrote:

> 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,

-- 
Jiri Kosina

Re: multi-input quirk and skip output reports quirk

[Anssi Hannula]

Jiri Kosina wrote:
> On Tue, 1 Apr 2008, Anssi Hannula wrote:
> 
>> 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.

Okay.

> Are you going to make that patch?

Not right now, maybe in a few weeks.

-- 
Anssi Hannula

Re: multi-input quirk and skip output reports quirk

[Jiri Kosina]

On Tue, 1 Apr 2008, Anssi Hannula wrote:

> >> 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.
> > 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 <jkosina@suse.cz>
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 <anssi.hannula@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index a104d1e..ff6fadc 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -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 },

Re: multi-input quirk and skip output reports quirk

[Anssi Hannula]

Jiri Kosina wrote:
> On Tue, 1 Apr 2008, Anssi Hannula wrote:
> 
>>>> 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.
>>> 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.

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

No, but I guess it is quite probable.

> Thanks.
> 


-- 
Anssi Hannula

Re: multi-input quirk and skip output reports quirk

[Jiri Kosina]

On Fri, 4 Apr 2008, Anssi Hannula wrote:

> >>>> 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.
> >>> 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.
> > 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,

-- 
Jiri Kosina
SUSE Labs

Re: multi-input quirk and skip output reports quirk

[Jiri Kosina]

On Tue, 1 Apr 2008, Anssi Hannula wrote:

> 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,

-- 
Jiri Kosina
SUSE Labs

Re: multi-input quirk and skip output reports quirk

[Anssi Hannula]

Jiri Kosina wrote:
> On Tue, 1 Apr 2008, Anssi Hannula wrote:
> 
>> 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?

Yes.

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

-- 
Anssi Hannula