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

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

Dmitriy Geels wrote:
> 2009/2/11 Anssi Hannula <anssi.hannula@gmail.com>:
>> Dmitriy Geels wrote:
>>> I did that already, you can also see described constant effect report
>>> using links, I posted earlier. There is no direction at all. Constant
>>> report has only effect block index and magnitude (3 bytes total: id,
>>> bi, mag). Device doesn't support direction at all.
>> (for clarification, I meant here an actual usb traffic dump when you play an
>> effect in windows)
> Ok, here is usb sniffer report:
> http://dmitriy.geels.googlepages.com/HIDtrafficdump.html
> Only reports data is raw, everything else decoded.
> What is there: I opened control panel applet for game devices, there
> is a test page, each effect played after button was pressed. All
> effects are periodic. There is pretty much information there.
> Here is just constant effect dump:
> http://dmitriy.geels.googlepages.com/constanteffectdump.html
> I changed magnitude and direction in test program. Changing direction
> doesn't send anything to device.
> 
>> Constant force makes no sense without a direction. What kind of force effect
>> does it actually produce?
> Just rumble. There is only one motor inside. For constant effect motor
> spins with constant speed, as I understood, this speed is controlled
> by magnitude. Also it is a place for report fixup: magnitude logical
> values are -127/127, but actually 1/255 -- 255 is strongest.

Hmm, so it is just rumble ( = periodic), not constant force. But what do 
the periodic effects do then, if constant is rumble? Normally periodic 
effects represent various types of rumble.

>>> After that, driver almost initializes: http://paste.org.ru/index.pl?008sgm
>>> It fails in pidff_check_autocenter(). According to descriptor, effect
>>> 1 is constant force. The problem is that block load report receive
>>> fails.
>>> I have no idea yet, why it fails, need to do some debug.
> ...
>> However, pidff_request_effect_upload should still not fail, as it is needed
>> for uploading effects. Try changing the effect type, make it e.g.
>> error = pidff_request_effect_upload(pidff, 2);
> Actually I tried to comment out check_autocenter() - then driver
> initializes successfully. But fftest fails to upload effect with io
> error.
> 
>> You could also try adding some delays after usbhid_wait_io() calls in
>> pidff_request_effect_upload(), with e.g. msleep(200) (you should also lower
>> the iterations limit 60 when adding such delays).
> I tried this, no result.
> I think, this problem is connected somehow to log message about
> maxusage and report_count do not match.

It is not related to those. I see two likely reasons:
1) Device needs more initialization; in the dump we see a "Actuators 
Enable" command sent first, and then the vendor report 64 three times 
with various data.
2) Reports 21+22 are transmitted as control transfers in the dump. I'll 
have to check whether we are doing the same.

>> If nothing else helps, I guess we need a dump from windows for this as well.
>>
>>> Can you tell,
>>> is there some way to monitor reports in kernel?
>> You can set debug=2 for hid module, but it will produce very much output.
> I found where to get outgoing data, added 2 dbg_hid() loggers, now
> have to find right place for incoming reports.
> 


-- 
Anssi Hannula