Dmitriy Geels wrote:
Thanks Anssi!
Your patch helped, device is passing pidff_find_reports().
Now stuck in pidff_find_fields(), with "unknown set_effect report layout".
Looks like, device doesn't implement PID specs completely, as there is
no gain and direction usages in set_effect report:
The minimal Effect parameter block must contain (Effect) Parameter Block Index, Effect Type, Duration,
Sample Period, Gain, Trigger Button, Trigger Repeat Interval, Axis Direction, and Type Specific Block
Handle values.
There is also no Sample Period nor Effect Type values.
But, looking into pidff_set_effect_report(), I think, it's possible to
add two if's to check if these fields present. And need to make check
for these fields optional somehow.
These two usages are not fully utilized anyway, gain is always set to
it's logical_maximum (actually it's used only in pidff_autocenter())
and direction is always set to 1.
Direction enable is set to 1. However, the direction value itself is
required for the force direction.
I really can't see how the direction could be transmitted, as the Axis
Enable fields (alternative way of specifying direction) are missing as
well. Unless you can figure it out with some creative testing, I guess
we need a usb dump of constant force with a windows driver.
For Effect Type, that can also be made optional in set_effect_report()
(it has already been sent in the upload request, so it is redundant).
There is also some problem with pidff_find_special_fields() ("effect
lists not found"), i'll add more debug messages and tell about that
later.
See above, it is because of the missing Effect Type field.
--
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
