http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #79 from Mr Nobody limited_choice@hotmail.com 2013-08-25 22:49:49 CDT --- (In reply to comment #78)
I didn't go through all the comments here, so I apologize if this has been covered.
I've been playing with joysticks in OSX for about a month. I originally was trying to get my Saitek Cyborg pad (2 analog sticks + dpad) to work with another open source project.
That other project would not see the second joystick. In short, the solution was to update libSDL to handle HID Rudder and Throttle types. Once I added support to SDL for that, everything worked (those patches are in the SDL trunk).
My point with that is that there is a decent possibility that some sticks are not working in Wine on OSX due to this type of thing.
Next, I decided to try Battlefield Vietnam in Wine on OSX. Runs fantastic, even at 2560x1440 (edit Video.con to do this). BUT, my Saitek ST290 flight stick does not completely work. The twist rudder and throttle do not work (these are defined as HID Z and Rz axes, not Rudder/Throttle like on my gamepad).
If I run 'wine control' and test the ST290, it recognizes all inputs. However, when I try to customize controls in BFV, it immediately says 'Joystick 7' (joystick button 7) when I click on an item to customize. The thing is, it only has 6 buttons. So, I have to conclude, there must an issue with how WINE is enumerating things in DINPUT to BFV.
Not a DINPUT expert. I've done a lot of debugging of joystick_osx.c in dinput, but I can't get past this issue.
Does anyone know of a DInput utility I can use to dump the joystick data on Wine and also on a real XP box (where this stick works in BFV just fine). That might shed some light on the differences.
Regards, Patrick
...well, you've made the assumption that BFV is using dinput ; it may not (or not in the way you suspect)..ie; it might be using dinput for kbd/mouse, but use xinput for joystick. Last time I heard, the xinput stuffs had yet to be included in the OSX specific wine input code (I don't know if this is still the case, but, it'd be something so check)...
...regarding your 'phantom' 7th joystick input that you should not have (and that specific behavior of merely selecting a control to redefine, and in the same moment the field gets filled as though you're holding that button down at the time)...that, I have seen before in a corner case with linux. The culprit was/is actually the USB 'Microsoft Wired Keyboard 600' I have here, and how the linux input drivers enumerate that device -- for whatever inane reason, it gets recognized firstly as a keyboard (and gets connected to that input group), and it's also recognized as a joystick device (??..go figure), and this gets enumerated as /dev/js0 ...and then, in wine with a game running, I go to configure the controls, the moment I select a control to redefine, it gets instantly filled with a descriptor 'controller 2 axis up' or similar..(which is some sort of aberration, as no keys are depressed at the time, and pressing all keys one at a time fails to find that key, nor can any other depressed key be entered)..
..As I say, it's a real corner case (and likely to be something behaving badly at OS level) ... but the point is, if that explained cause can lead to the same observed behavior in wine/the app in question, then it'd be worthwhile checking that OSX isn't promoting some input data that things are getting horribly wrong. Likewise, it'd be worthwhile attaching the related debug channels to all this (dinput8, dinput, xinput ...one at a time) to the wine process running BFV, to try discern which API the game is using for joystick input ; if the xinput stuff is still incomplete in osx-joystick.c and the app tries to access that API..etc bla bla =)..