[0/3] hid-pidff fixes and PID compliance improvement

Message

Tomasz Pakuła Feb. 24, 2025, 9:30 a.m. UTC

Based on top of current hid.git#for-6.15/pidff

Another batch of updated to the generic USB PID driver. Apart from
realigning two function names with the rest of the driver, clamping
LOOP_COUNT value to the logical max to fix some errors.

Infinite values were previously hardcoded to 0xffff but the standard
actually calls for the max possible value for the presented field size.
If the duration is not 16 bit, but 32 bit 0xffff won't work as infinite.

Setting infinite value works now by computing this value from report
size. We still need to look out for 0xffff as that's the max possible
value we can get from the ff API. 0 was never actually defined in the
Linux kernel as explicitly INFINITE but it seems like it has become a
de-facto standard.

After pidff, I'll (at least try) working on extending and updating
the ff API as it lacks some features and could be considered incomplete.
The biggest issue is that there's currently no way of obtaining effect
status or sending device control commands.

And a quick question. If Anssi is not active in the kernel development
maybe we should remove his email from the hid_info message:
"Force feedback for USB HID PID devices by Anssi Hannula <[e-mail]>"

Just the email as a user with potential issues might email him
directly instead of coming to mailing lists or bugzilla? I've seen
that it was a bit of a standard to include this info in old drivers
but IMO it would be good to alter all these messages to not include
any direct contact info as it might get/be outdated at some point.

Tomasz Pakuła (3):
  HID: pidff: Rename two functions to align them with naming convention
  HID: pidff: Clamp effect playback LOOP_COUNT value
  HID: pidff: Compute INFINITE value instead of using hardcoded 0xffff

 drivers/hid/usbhid/hid-pidff.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)


base-commit: b9c340b67b33cd37e543195b157c73a7bb0c8d4a