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

Dmitriy Geels wrote:

quoted

quoted

quoted

quoted

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?

quoted

quoted

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