I’d like to add some FFB features to my joystick device driver. I went over documet “USB - Device Class Definition for Physical Interface Devices” and oh boy, it is unreadable. So whet I thought was to dump the HID descriptors of my Logitech Steering Wheel and copy/paste as much as I can.
So now I look for a utility that does just that. Any better idea?
Shaul, what is your final goal? And how joystick’s driver stack looks like? If the feedback is initiated from user mode, isn’t it better to create a user mode component or patch existing one?
OK, here is what I do.
I have a (published, functional) virtual joystick driver. I use it to fool the system and consequently flight simulators. The simulator thinks that there?s a joystick attached, but actually there?s a model airplane R/C connected to the microphone socket.
Now, I?d like the simulator to detect my virtual joystick device as a FFB-capable device and to send FFB data to it. The driver will take the data and pass it over to whatever there is.
So, you see, I have no access to the client software (simulator) and I need to make my virtual joystick compatible to conventions used by game/simulator vendors.
Shaul, can’t say that I’ve got all you said. Never heard of airplane that are attached to mic. Also I don’t get which kind of FFB may come to the airplane (or to PC?..). Anyway if you post the driver’s binary I could briefly walk over it in disassembler and probably give you some directions.
I was trying to be brief. Well probably too brief.
The main point is that I have a functional joystick that is pure software: Driver+Device.
I now want to add FFB to it but I have no idea how to change the descriptors. I believe that I’ll manage with the handling of the data.
I want to get the descriptors from my Wheel hardware and intelligently copy the relevant pieces.
I’ll be really grateful if you help me!
For some reason I may not post attachments so here are the Logitech drivers:
http://db.tt/orJ75udh
http://db.tt/esfFnYCO
Thank You!
The drivers probably don’t have the descriptor built in to the image, they probably query it from the hardware. There was an app floating around, hidview?, that showed raw HID descriptors.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 21, 2012 12:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reverse engineering: Dump HID descriptor of a 3rd party device
I was trying to be brief. Well probably too brief.
The main point is that I have a functional joystick that is pure software: Driver+Device.
I now want to add FFB to it but I have no idea how to change the descriptors. I believe that I’ll manage with the handling of the data.
I want to get the descriptors from my Wheel hardware and intelligently copy the relevant pieces.
I’ll be really grateful if you help me!
For some reason I may not post attachments so here are the Logitech drivers:
http://db.tt/orJ75udh
http://db.tt/esfFnYCO
Thank You!
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Yes, come to think of it, the driver only passes the data from the HW.
The tool you mentioned is outdated and replaced, according to USB.org by USB20CV that I try to manipulate.
Wouldn’t it be nice to have a debug tool that inserts itself above the device driver and monitors the data transactions? I was sure there was one.
On Wed, Aug 22, 2012 at 2:27 PM, wrote:
> Yes, come to think of it, the driver only passes the data from the HW.
> The tool you mentioned is outdated and replaced, according to USB.org by
> USB20CV that I try to manipulate.
> Wouldn’t it be nice to have a debug tool that inserts itself above the device
> driver and monitors the data transactions? I was sure there was one.
Under Linux you can use usbutils (lsusb) to dump the HID report descriptor.
http://libusb.6.n5.nabble.com/How-to-dump-HID-report-descriptor-under-Linux-td5971.html
You can get a version of lsusb for Windows here (built by me under
Cygwin). It can be used within Cygwin.
http://code.google.com/p/picusb/downloads/detail?name=usbutils_005_cygwin.zip
Under Windows, last time I used HHD USB Monitor trial version.
http://www.hhdsoftware.com/usb-monitor
Other USB sniffers (eg: USBLyzer) may have similar features.
I do not know much about ForceFeedback, but the links here in
Microchip Forum may help you. Poster there have spent quite
some trying to get Force Feedback working.
http://www.microchip.com/forums/fb.ashx?m=369980
–
Xiaofan
Shaul, what stack the driver belongs to? !devstack in WinDbg could be very useful. I checked the drivers a bit, it looks like they don’t use HIDClass (none of them). The 1st idea is to put a filter over Logitech’s filter to fake IO reads (the filter handles the data in completion routine). But probably there are easier ways…
Thank you Xiaofan for excellent references.
I warmly recommend ‘USBlyzer’ - it is a sniffer that gives perfectly readable data as well as raw data. Note that the downloaded version is trialware.
As for the many links on Microchip’s site - more than they teach they revel the lack of modern documentation regarding Force Feedback (FFB). I will post a strong message on MSDN. I know Doron is reading both but just as well.
Back to my project:
I used ‘USBlyzer’ to analyse my reference product (Logitech steering wheel) and here’s the HID Report Descriptor I’ve got (I removed all but the FFB part):
Collection (Logical) A1 02
Logical Maximum (255) 26 FF 00
Physical Maximum (255) 46 FF 00
Report Count (7) 95 07
Report Size (8) 75 08
Usage (Vendor-Defined 3) 09 03
Output (Data,Var,Abs,NWrp,Lin,Pref,NNul,NVol,Bit) 91 02
End Collection C0
As you see, they just use the ‘Vendor-Defined 3’ back door to save hundreds of code lines.
Then, I sniffed the out-going data flow during FFB (Ramble):
Output Report:
Usage Range Lg/Ph Value
Vendor-Defined 3 [0…255] 81
Vendor-Defined 3 [0…255] 0
Vendor-Defined 3 [0…255] 42
Vendor-Defined 3 [0…255] 0
Vendor-Defined 3 [0…255] 0
Vendor-Defined 3 [0…255] 0
Vendor-Defined 3 [0…255] 0
How the sniffer learned that this was ‘Vendor-Defined 3’ is beyond me.
The interesting part is that while the first value was always 81 the third one was on the range 43-253 according to the strength of the ramble.
Now, what is the mechanism that converts this to actual FFB is not clear to me but it has something to do with the registry at explained here: http://msdn.microsoft.com/en-us/library/ff542434(VS.85).aspx
I will open a new thread to discuss this point.
I still would like help in constructing a PID descriptor. There are all kind of suggestions in the Microchip site ut none seem to work for me. More to follow…