[Bug 51873] Joy.cpl crashes on the FFB tab when the FFB device is selected in the drop down list

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51873

--- Comment #24 from Rémi Bernon <rbernon at codeweavers.com> ---
(In reply to Ivo Ivanov from comment #23)
> (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.
> 

Ah I see, I'll try that. Thanks!

> 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 :)

Oh yeah you're right indeed, there is some scaling for some of the values like
direction or magnitude, but I completely missed some others... Duh!

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.