Re: hid-pidff bug: fails to find all required reports of saitek gamepad

[Anssi Hannula <anssi.hannula@gmail.com>]

Dmitriy Geels wrote:
>>>>> Notice the difference in length of report 22 on windows and linux. Try
>>>>> this in pidff_init():
>>>>> pidff->reports[PID_BLOCK_LOAD]->size += 8;
>>>> That's it!
>>>> I didn't pay attention to length value. Looks like a missing usage in
>>>> report descriptor!
>>>> So, quirk with report fix is needed for this device.
> I'm trying to understand better way to make this descriptor fix. Can
> you give me an advice on this?
> Or it's better to wait for patch discussed in "Allow drivers to
> replace report descriptors" topic?

I see there are two options:
a) Add a device-specific quirk in pidff_init(), or
b) Add hid-saitek.c that does the adjustment.

Jiri (CCd, HID maintainer), WDYT?

>>> Hmm, this says problems start with "fftest".
>>> [10054.751832] HID: implement() called with too large value 47113! (fftest)
>>>
>>> Could you print all the values set in pidff_set_effect_report() just
>>> before the usbhid_submit_report() call, and try to reproduce the WARNING
>>> with fftest.
> Problem in fftest is simple: using uninitialized structures. That also
> was causing slow path warning.
> But running ffmvforce after fftest brings device to unconsistent
> state, causing messages "usb 1-1: ctrl urb status -62 received".

Does this happen also with fixed fftest?

Of course hid-pidff should also check the values provided, I'll fix this 
as well.

I'll try to provide the discussed patch(es) next weekend.

-- 
Anssi Hannula