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

2009/2/14 Anssi Hannula [off-list ref]:

quoted

quoted

quoted

For periodic effects it controls every period, as I understood.

That is not supposed to be the case and seems very strange. Can you
confirm this (maybe after we get it working on linux)?

I just admitted that.

How did you test it?

I didn't. I just supposed, that it should be so.

quoted

quoted

quoted

quoted

2) Reports 21+22 are transmitted as control transfers in the dump. I'll have
to check whether we are doing the same.

We do: http://paste.org.ru/index.pl?iyvkmg
Got this log with patch: http://paste.org.ru/index.pl?m4wauv

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.

Also i found one strange thing: ffmvforce utility brings driver to
inconsistent state. http://paste.org.ru/index.pl?1ajtxt

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.

Got it: http://paste.org.ru/index.pl?fv7wss
Then after launching ffmvforce: http://paste.org.ru/index.pl?3pdotg