http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #31 from Mr Nobody limited_choice@hotmail.com 2011-02-18 19:40:58 CST --- David (and others present ;) --
I did manage to have that chat with the dev, here's the story -- when the joystick support was added for OSX, at that time the xinput layer was for the most part stubbed, and pretty much all of this OSX joystick support is in dinput. Basically there was nothing else to work with at that time =)
In Windows, an app can access HID data in many different ways, but to view it chronologically, first came the 'direct serial connection' (with the device driver itself), next came dinput (what we currently have working in Wine wrt OSX), and then of course came xinput (which works in Wine with linux, not OSX).
Apparently, trying to add the 'direct serial' support into Wine for OSX ropes in driver issues that no-one wants to deal with in Wine itself, so that's probably not going to go anywhere in a hurry (and likely only going to hit the older games).
The dinput support in Wine for OSX *does* work, so if your win32 app is using that (many do), things will appear to be working well and 'as expected' for the most part - parity wrt linux and Wine as such. Be aware however, there may be cases where a win32 app is using more than one method to obtain HID data, and that can 'trip you up' sometimes if you're not aware of such possibility...
What actually needs to happen here, is for someone to revisit the OSX specific portions of the Wine dinput code, and 'have another look' at what xinput functionality *now* works in Wine (previous stubs have been replaced with great code), and meld that xinput code/methodology into the OSX support here wrt Wine. Then, Mac users would have 2 slices of the same pie instead of the current 1, and things like IL-2 *should* start to work with xinput in the OSX build of Wine.
IL-2 is actually a good example, wherein (on linux at least) it appears to be utilizing both direct serial and xinput methods, but ?apparently? -not- dinput stuffs (else it *should* be working in OSX ;) - this is what piqued my initial curiosity to be sure. The dev I was talking to here said, time permitting, that he'd have a look at the code again to see what has changed - he also at the same time indicated it would require someone more familiar with the xinput framework to implement any real fix in this case (he's a Mac guy, not really into xinput B^)
So there you go -- that's the canvass we're all looking at here, and big kudos to Aric Stewart for sparing the time to expound this all to me, so that I might pass it on to those present. It never occurred to dum-dums here that xinput was largely stubbed out at the time - as soon as I was told this, the penny dropped like a 16ton anvil, and I felt deservedly stoopid (8-
Hopefully now that the situation is better drawn in the wider context, someone with the needed skills might take up the challenge to 'give it some love' as Aric so nicely puts it.
Huzzah!