https://bugs.winehq.org/show_bug.cgi?id=51873
--- Comment #23 from Ivo Ivanov logos128@gmail.com --- (In reply to Rémi Bernon from comment #22)
Thanks, is the MS PID driver actually using these reports with your device? I haven't yet found a way to have them used with the virtual HID driver we have for conformance testing. It would be really nice if we could test them too.
Yes, it needs the Create New Effect Report and PID Block Load Report to function properly, as it is Device Managed. I think most of the modern PID devices manage their block index on the device side. Those reports are visible in the usb traffic captures (Simucube_2_logs.tar.gz) attached to this bug report.
IMO the virtual HID driver need to implement the PID Pool Feature Report (look the attached SC2_descr.txt - Usage (7Fh)), and set the Device Managed Pool usage there. With other words it needs to advertise itself as Device Managed. The Linux driver does just this to check if the device is Device Managed.
Here (in Wine) we check for the existence of the Create New Effect Report, and assume that the device manages its blocks internally, since this and the other reports are used only by such devices as per specification.
I just used the same kind of value range as some sample descriptors from the PID spec, or as the SideWinder HID descriptors that can be found on internet. This can definitely be modified to better match backend ranges and avoid unnecessary rounding (although SDL and evdev may have slightly different ranges).
The ranges in the frontend dinput/joystick_hid.c are OK, IMO. They are similar to my device's report descriptor.
I meant the "virtual" HID report descriptors in the UDEV lnxev and the SDL backends. Their logical ranges are too small, and are being passed without any rescaling to the ff_effect / SDL_HapticEffect structures. Unless I am overlooking something :)