http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #39 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-16 11:09:32 CDT --- (In reply to comment #37)
(In reply to comment #35) Hi Jonas, thanks for taking a look at it.
Well, it was a typical case of itch & scratch :)
I did the same set of tests and confirm what you've found -- I'll be eager to test out your patch, as I've 5 different kinds of HID to throw at it, so I can get a bit of device checking done...I somehow still expect to see curveballs =)...
I only have one and I've only tested it with one game, so it's indeed quite likely that it won't be 100%. But at least things are hooked up now.
...wrt pads, there is some mirky ground ...ie; the linux xpad.ko driver will see the xbox 360 & 'S' type controllers equally, but in OSX these two are chalk and cheese ; you have to use a different OS driver for each last time I looked.
It's possible, I don't know. But in the end they're all represented as plain HID devices, so I guess it doesn't really matter.
For Mac OS X, there's also the pretty useful HID Calibrator sample code at http://developer.apple.com/library/mac/#samplecode/HID_Calibrator/Introducti... (click the "Download Sample Code" button at the top of the page). The HID Calibrator app is quite useful to see all controls that are recognised, their types and valid ranges.
The HID Calibrator sample in that archive also contains an XML file that matches up all elements of the PS 3 controller to human readable names. See the "HID Utilities/English.lproj/HID_cookie_strings.plist" file in the archive. It doesn't seem to contain a description for the xbox controllers, but it shouldn't be too difficult to create similar information files for them. I don't know whether that information can be passed on to Windows apps in a useful way though (I have absolutely zero experience programming the Windows API -- and until yesterday also with Mac OS X HID for that matter, but I can at least experiment with the latter).
Also, there's this other thing I've noticed (seems app dependent) wherein the analog 'trigger' controls (which one might map to throttle/brake) are inverted, and this is common to both platforms. It makes one wonder why some win32 apps are currently seeing things 'as is' and others aren't ...
No idea about this.