Dmitriy Geels wrote:
2009/2/11 Anssi Hannula <anssi.hannula@xxxxxxxxx>:
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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
