http://bugs.winehq.org/show_bug.cgi?id=18424
Summary: Mac OS X Joystick support doesn't work Product: Wine Version: 1.1.20 Platform: Macintosh OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput AssignedTo: wine-bugs@winehq.org ReportedBy: n8gray@n8gray.org
I was really pleased to see that Wine added support for joysticks on the Mac but I haven't had any success getting my MS Sidewinder Precision Pro (USB) to work in the games I've tried. I've tried with two demos: Descent Freespace demo and IL-2 Sturmovik demo. I've tried connecting the stick before and after Wine starts. In each case no joystick is detected. The stick is detected in USB Prober and works properly in other OS X software, so I know it's generally compatible.
I'm using Kronenberg's build of 1.1.20 available here: http://www.kronenberg.org/darwine/
Thanks! -Nathan
http://bugs.winehq.org/show_bug.cgi?id=18424
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
http://bugs.winehq.org/show_bug.cgi?id=18424
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|Macintosh |PC
http://bugs.winehq.org/show_bug.cgi?id=18424
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adam.bartley@gmail.com
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-31 04:24:49 CDT --- *** Bug 24218 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #2 from adam.bartley@gmail.com 2010-08-31 04:38:34 CDT --- Rather than close my bug report as a duplicate, how about providing some useful comment on why it has not been addressed for *many* months? The problem is definitely with dinput, as shown here "dinput:get_osx_device_elements Unhandled type 513". Please, also, do not report these things as supported by wine when they clearly are not.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-31 05:18:43 CDT --- (In reply to comment #2)
Rather than close my bug report as a duplicate, how about providing some useful comment on why it has not been addressed for *many* months? The problem is definitely with dinput, as shown here "dinput:get_osx_device_elements Unhandled type 513". Please, also, do not report these things as supported by wine when they clearly are not.
Wine is an open source project worked on by volunteers. Feel free to send patches to improve things.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #4 from Austin English austinenglish@gmail.com 2010-08-31 10:31:12 CDT --- (In reply to comment #2)
Please, also, do not report these things as supported by wine when they clearly are not.
Where is Wine reporting it as supported?
http://bugs.winehq.org/show_bug.cgi?id=18424
doh123@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |doh123@gmail.com
--- Comment #5 from doh123@gmail.com 2010-12-14 19:59:23 CST --- (In reply to comment #4)
(In reply to comment #2)
Please, also, do not report these things as supported by wine when they clearly are not.
Where is Wine reporting it as supported?
1.1.17 ... one of the main things listed was joystick support. ---------------------- http://www.winehq.org/announce/1.1.17 The Wine development release 1.1.17 is now available.
What's new in this release (see below for details): - Joystick support on Mac OS X. - Implementation of iphlpapi on Solaris. - A number of 64-bit improvements. - Obsolete LinuxThreads support has been removed. - Many fixes to the regression tests on Windows. - Various bug fixes. ------------------- I have a couple of joysticks that work fine in OSX, and I've never been able to get them to work with anything in Wine either... and I've never found anyone who said it does work, just people griping about it never working.
http://bugs.winehq.org/show_bug.cgi?id=18424
doh123@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from doh123@gmail.com 2010-12-14 20:04:23 CST --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=18424
dave david.dljunk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.dljunk@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #7 from dave david.dljunk@gmail.com 2010-12-15 03:30:44 CST --- (In reply to comment #3)
I've had the same trouble with joysticks and wine. If indeed this problem is OSX-wide and game-wide as it seems to be, then solving this would help a large class of gamers play a large class of games through Wine. While I would love to fix this, I am afraid I lack the necessary competency and as such I must rely on the kindness of wine-devs. :)
I recognize that with such a complex entity evolving through disparate donations of talent that features and bug-fixes must be prioritized. Hopefully given the potential scope of effect this bug fix could have, someone with talent and knowledge will read this and make fixing the joystick bug their priority.
To this person, Thanks in Advance!
http://bugs.winehq.org/show_bug.cgi?id=18424
Mr Nobody limited_choice@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |limited_choice@hotmail.com
--- Comment #8 from Mr Nobody limited_choice@hotmail.com 2010-12-29 06:14:24 CST --- I'm a little confused by this entry, but prepared to do some legwork on it. I think primarily I'm concerned about IL-2 Sturmovik being the example app of (USB) joystick input not working in OSX -- I will recheck, but afaik this app doesn't see USB joysticks in linux wine either -- it *does* however see a dsub-15 gameport connected joystick, and works reliably with it.
Could someone please mention another app, (*not* one of the IL-2 titles), which isn't seeing USB joystick input in OSX? I have a Saitek ST90 to test against but no idea which apps people are 'whining' about (grand play on words that :)
The *reason* I ask for a target app here, is that I've had varying results in OSX and wine with other apps using a Xbox 360 controller and the '360Controller' driver..ie; take 10 driving sim games I have - in linux with the xpad.ko kernel driver, all 10 will see the controller and work fine -- in OSX, the turn out is 4 will work with the xpad, and the other 6 don't see it at all. That makes me think something is a tad awry -anyhow-, and to compound things here, the 'XHD' Xbox 360 controller driver (from sourceforge) isn't seen by wine at all (but OSX *does* recognize and work with the XHD driver).
However, it's not a good test case -- the USB HID isn't using the system native OSX driver, which is what I believe we should be looking at for the case of a simple joystick HID, correct? So...feed me something to test...
@doh123 - you must have a small list of apps so affected? (8
@David - I'm not a wine_dev but you deserve kudos for the well worded appeal B)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #9 from doh123@gmail.com 2010-12-29 10:59:25 CST --- (In reply to comment #8)
@doh123 - you must have a small list of apps so affected? (8
I've tried several games, though I never kept a list... and have of course only tried USB joysticks. One I remember was the Vegastrike engine along with many mods. While I know these also have native versions, there was some severe graphical issues at one time and the Windows version under Wine was running much better, but the joystick could not function, even though the native build it worked fine.
Another I do have that other people have complained to me that it doesn't work... is Red Baron 3D...
I did see someone claim their Sidewinder 3D worked without force feedback in Microsoft Flight Sim X though.
I really don't play any joystick games, but I have had people complain about Wineskin not using their joysticks (with 100% unaltered Wine source), but I never asked for specific games to make a list since I had never seen anyone (until FlightSim recently) ever claim to get one to work in anything.
If you can find even a few games where it does work ok, thats at least a starting point to see if there are still any issues.
http://bugs.winehq.org/show_bug.cgi?id=18424
qazwsx@bobmail.info changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qazwsx@bobmail.info
--- Comment #10 from qazwsx@bobmail.info 2010-12-29 11:14:06 CST ---
[list of games]
"Re-Volt"
http://en.wikipedia.org/wiki/Re-Volt http://revolt.wikia.com/wiki/Re-Volt_Wiki
I just spent the past 16.5 hours (straight) trying to get wine installed and configured on OSX so I could play this. after much swearing and hair pulling it's finally running, except it won't recognize my sony controller, which works just fine in HID-aware OSX apps. I found this page after some googling and thought I'd comment.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #11 from Nathan Gray n8gray@n8gray.org 2010-12-29 13:24:13 CST --- As I said in the initial bug report, the descent freespace demo also doesn't work.
There are a few things to understand when considering this problem:
* The joystick support in Wine only works when built for Leopard and above.
* Last I checked, the popular build of Wine by Mike Kronenberg was built for Tiger and thus didn't include the joystick code. This could have changed by now -- it's been quite a while since I looked into this.
* When I poked through the Wine joystick code it looked like it might only support somewhat newer versions of directx (v5 and up maybe?). IL-2 for one example uses an older version of directx. Not being an expert on this codebase, I could be mistaken.
I wouldn't disqualify IL-2 as a test case. It works fine with USB sticks in Windows and thus it should be supported in Wine. It might not be the best case to *start* with, but it's an extremely popular flight sim and worthy of support.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #12 from doh123@gmail.com 2010-12-30 12:06:38 CST --- I make Wineskin, where I have people complaining often about Joysticks not working, and it is 10.5+
Now I have had some people claim their gamepads and joysticks have worked in a few titles, but its usually complaints of not working. So I wouldn't say its impossible for joysticks to work in the current code, but there is something not 100% right about it.
(In reply to comment #11)
- Last I checked, the popular build of Wine by Mike Kronenberg was built for
Tiger and thus didn't include the joystick code. This could have changed by now -- it's been quite a while since I looked into this.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #13 from Mr Nobody limited_choice@hotmail.com 2010-12-30 14:33:42 CST --- (In reply to comment #9)
If you can find even a few games where it does work ok, thats at least a starting point to see if there are still any issues.
You've no idea how accurate that turned out to be ;) First up though, confirming my memory didn't fail me when referring to past experience in linux - using a wine-1.3.10 build and the gog.com version of IL-2 Sturmovik 1946, this app simply does not see the USB stick at all. On the same machine, with a PCI emu10k1 soundcard with the older gameport style interface, I have connected a SkyMaster RapidShot analog joystick (4 button, 2 axis + throttle wheel. HAT). This device *must* appear @ /dev/js0 to be seen by IL-2, so you've got to unplug any other joystick HIDs you have (and perhaps rmmod joystick) to claim /dev/js0 -- IL-2 sees this gameport connected joystick no problem at all. Why this is so, I cannot say, but I'd always presumed it was due to snd_emu10k1gp driver being present in the device tree. If they're getting USB joysticks to work with IL-2 in Windows, you'd need question whether or not any 3rd party drivers are being used..ie; in my mind, I doubt it'd be hard to create a software gameport to emulate that device hardware .. 'who knows what goes on in Windows'.
I finally gave up on looking for an open source program or other free flight(sim) genre titles, after the 11,2 spat the dummy about that notion 3 times (couldn't get the apps to run)...so instead, scrub flight, lets go driving instead (Flatout on Steam) - hey presto, there's the Saitek ST-90 as default choice, the Logitech Dpad, 'Controller' (xbox pad) and keyboard, all as they should be. Going to configure it reveals a little trap - Usboverdrive has claimed it, and it sent the app keyboard events...(just as it should really) ..turn off Usboverdrive, and now Flatout sees the 'real' joystick device, all it including the digital-analog throttle (although useless in a driving sim, it would be at home in a flight/other sim)...in fact, it works as good on the Mac as it does in linux ... the support is definitely there, and ostensibly found to be working 'just as it does in Windows' in this test case, again using a build of wine-1.3.10 via macports.
Little doubt I could find other apps equally disposed if I kept on looking and checking...but having established this much, how best to proceed in isolating any anomalies? I believe I may have a test case scenario, based on this little excursion....ie; those apps mentioned previously where in OSX they couldn't see the xbox pad but the same apps -could- see an xpad in linux ; maybe I'll get lucky and we can get a trace wrt simple USB joystick on both working and non working situations and find the gremlins.
Should I be looking at anything more other than dinput in the way of debug channels at this stage?
Kudos to all for the interest and feedback.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #14 from Mr Nobody limited_choice@hotmail.com 2010-12-31 05:46:08 CST --- (In reply to comment #11)
As I said in the initial bug report, the descent freespace demo also doesn't work.
There are a few things to understand when considering this problem:
The joystick support in Wine only works when built for Leopard and above.
Last I checked, the popular build of Wine by Mike Kronenberg was built for
Tiger and thus didn't include the joystick code. This could have changed by now -- it's been quite a while since I looked into this.
- When I poked through the Wine joystick code it looked like it might only
support somewhat newer versions of directx (v5 and up maybe?). IL-2 for one example uses an older version of directx. Not being an expert on this codebase, I could be mistaken.
I wouldn't disqualify IL-2 as a test case. It works fine with USB sticks in Windows and thus it should be supported in Wine. It might not be the best case to *start* with, but it's an extremely popular flight sim and worthy of support.
It's not that I'm being dismissive (nor derisive) of IL-2 ; it is indeed a great flightsim that redefined the genre -- all I'm saying is if the USB HID isn't being seen in linux, I don't really expect to see it in OSX either with the same wine tree. Likewise, there can often be disparity between game vendor releases, the Flatout titles being a good example ; I don't know of anyone that's managed to get the gog.com release(s) running in OSX ; Steam versions work fine (and have a different setup GUI with more screenmode support) - it just throws another variable into the fray...differnt versions may use different methods...(unlikely, but possible)..
Some apps actually seem to have defined presets built into them, and use the HID if it happens to be connected -- Rockstar's GTA-3 series tend to do this. YMMV here depending on controller device VID/PID...
I do concur that most complaints tend to be coming from that sector of older apps, many of which were coded/existed before USB became mainstream. You mention Descent/Freespace, I *think* I recall them working with gameport connected HID but not USB (same caveat applies, must be /dev/js0), and the MegaRace series and a few other racing sims of that circa fit in here too.
This would be a little OT here and somewhat missing the point, but the observation must be made that my experience regarding these older app titles, that were indeed coded for the gameport device, is that they do still seem to work just fine in wine (linux) with a gameport connected HID appearing at /dev/js0. Be it a puristic view or whatever, but that would be Wine doing an outstanding job of accurately running the win32 app/game, 'just as it worked in Windows back in 199something'...it's just not particularly useful as legacy gameport support falls to deprecated hardware status (if not already there), with USB in it's stead. Either way, what we're effectively asking for is that some win32 app recognize and work with something it was never designed/coded for. More so the case in OSX obviously...I doubt it'd even have the old gameport device driver...or am I wrong?
Best I can figure it, the current situation is one of USB HID input actually working in OSX more or less 'as expected' (Flatout2, Volvo the Game, KartRacer all seem to work with USB HIDs), but when it comes to older apps/games it could be the simple case of lacking necessary hardware support. Like I say, if Windows users can do it, I'd have to suspect 3rd party drivers at work, as likely there's no gameport present in that case, either. The win32 drivers might possibly create a virtual gameport device in the normally assigned I/O range for gameport, and feed/eat the USB data to that virtual device concurrent with dx-input ; perhaps the Windows driver layer itself facilitates this..{shrug}...
This....is what I meant by 'confusion' concerning this bug ; it's not really the case of OSX lacking USB input support ; it is an equally shared situation with both linux and OSX, in that we can't communicate with older apps/games coded for the 'traditional' gameport device, with modern USB based HIDs.
It would seem more app specific than it is OS-centric imho ; if there's any apps/games out there that were coded in 'USB aware' times and USB HID doesn't work when it should, that would be a bug but only against that app.
Apps/games coded -before- USB awareness and that were never designed (or been updated/patched) for USB HID support, are a different matter altogether, as they work fine with the hardware they were coded for (in linux). If one could recreate the testbed...Mac+emu10k1+gameport_driver+12 year old HID....I'd probably guess these older apps would work in OSX just like they do in the linux case (if only it were that easy)...point is, the fact these apps don't work with USB input is not really a failing/bug on wine's part for mine, nor is it OSX specific - most of these older games don't see USB HID in linux either.
...I wonder if we should close this bug as being a 'misnomer', and have folks submit bugs on a per app basis, to better vet the situation...
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #15 from qazwsx@bobmail.info 2010-12-31 18:31:25 CST ---
[older apps]
that would cover re-volt, it was a win98 game.
...I wonder if we should close this bug as being a 'misnomer', and have folks
submit bugs on a per app basis, to better vet the situation...
I know I don't have any weight in this conversation at all, but I don't agree with this. fundamentally, if the point of wine is to "run windows apps without installing windows", then it should be able to do the same things windows can. if xp/win7/etc can auto-translate usb devices in such a way that older games can use them seamlessly, then wine should be able to do that too. otherwise you just end up given credence to the "wine never works, just dual boot" people.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #16 from david.dljunk@gmail.com 2010-12-31 18:50:50 CST --- (In reply to comment #14)
It's not that I'm being dismissive (nor derisive) of IL-2 ; it is indeed a great flightsim that redefined the genre -- all I'm saying is if the USB HID isn't being seen in linux, I don't really expect to see it in OSX either with the same wine tree. Likewise, there can often be disparity between game vendor releases, the Flatout titles being a good example ; I don't know of anyone that's managed to get the gog.com release(s) running in OSX ; Steam versions work fine (and have a different setup GUI with more screenmode support) - it just throws another variable into the fray...differnt versions may use different methods...(unlikely, but possible)..
Some apps actually seem to have defined presets built into them, and use the HID if it happens to be connected -- Rockstar's GTA-3 series tend to do this. YMMV here depending on controller device VID/PID...
I do concur that most complaints tend to be coming from that sector of older apps, many of which were coded/existed before USB became mainstream. You mention Descent/Freespace, I *think* I recall them working with gameport connected HID but not USB (same caveat applies, must be /dev/js0), and the MegaRace series and a few other racing sims of that circa fit in here too.
This would be a little OT here and somewhat missing the point, but the observation must be made that my experience regarding these older app titles, that were indeed coded for the gameport device, is that they do still seem to work just fine in wine (linux) with a gameport connected HID appearing at /dev/js0. Be it a puristic view or whatever, but that would be Wine doing an outstanding job of accurately running the win32 app/game, 'just as it worked in Windows back in 199something'...it's just not particularly useful as legacy gameport support falls to deprecated hardware status (if not already there), with USB in it's stead. Either way, what we're effectively asking for is that some win32 app recognize and work with something it was never designed/coded for. More so the case in OSX obviously...I doubt it'd even have the old gameport device driver...or am I wrong?
Best I can figure it, the current situation is one of USB HID input actually working in OSX more or less 'as expected' (Flatout2, Volvo the Game, KartRacer all seem to work with USB HIDs), but when it comes to older apps/games it could be the simple case of lacking necessary hardware support. Like I say, if Windows users can do it, I'd have to suspect 3rd party drivers at work, as likely there's no gameport present in that case, either. The win32 drivers might possibly create a virtual gameport device in the normally assigned I/O range for gameport, and feed/eat the USB data to that virtual device concurrent with dx-input ; perhaps the Windows driver layer itself facilitates this..{shrug}...
This....is what I meant by 'confusion' concerning this bug ; it's not really the case of OSX lacking USB input support ; it is an equally shared situation with both linux and OSX, in that we can't communicate with older apps/games coded for the 'traditional' gameport device, with modern USB based HIDs.
If you try the GOG version of Red Baron 3D, the joystick also does not work in Wine-OS X. However, I believe Rens got Red Baron 3D working for Linux and seemed to suggest that everything worked in his Linux Wine tests (its in AppDB and he has a website about it). Red Baron 3D is an older game, however this seems to be an instance of a game working in Linux, but not in OS X. Perhaps you can try it out yourself if the joystick works in Linux if you're not adverse to getting Red Baron 3D (which is a great game btw - even Red Baron 1 is worth the price of GOG's admission).
For completeness sake I'm using a Logitech Extreme 3D pro. I can also verify that the Logitech joystick works in Windows 7 with Red Baron 3D even before adding the Logitech specific drivers and that the joystick works well in other Mac OS X application. I even use it to play Red Baron 1 under DosBox (Boxer frontend) and the joystick works there. So I would say there are some compatibility issues with Wine-OS X when it comes to USB HID devices.
Anyway, thanks for taking an interest in this!
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #17 from Mr Nobody limited_choice@hotmail.com 2010-12-31 23:06:21 CST --- (In reply to comment #16)
If you try the GOG version of Red Baron 3D, the joystick also does not work in Wine-OS X. However, I believe Rens got Red Baron 3D working for Linux and seemed to suggest that everything worked in his Linux Wine tests (its in AppDB and he has a website about it). Red Baron 3D is an older game, however this seems to be an instance of a game working in Linux, but not in OS X. Perhaps you can try it out yourself if the joystick works in Linux if you're not adverse to getting Red Baron 3D (which is a great game btw - even Red Baron 1 is worth the price of GOG's admission).
For completeness sake I'm using a Logitech Extreme 3D pro. I can also verify that the Logitech joystick works in Windows 7 with Red Baron 3D even before adding the Logitech specific drivers and that the joystick works well in other Mac OS X application. I even use it to play Red Baron 1 under DosBox (Boxer frontend) and the joystick works there. So I would say there are some compatibility issues with Wine-OS X when it comes to USB HID devices.
Anyway, thanks for taking an interest in this!
Great, this was something along the lines of what we're looking for. It is a tiny bit extruded (as we're actually communicating via dosbox)...but that in itself might be a good thing ; we can read the dosbox source. I've already grabbed the GOG release (after doh123 nominated it as a possible), and the 11,2 doesn't really like it (32->8 color mode rubbish but I haven't fiddled yet) - I'll see if I can recreate the 'all working' scenario Rens posted first.
Extremely helpful to know the exact situation wrt windows/drivers here, thanks for that - it helps remove speculation.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #18 from Mr Nobody limited_choice@hotmail.com 2010-12-31 23:24:18 CST --- (In reply to comment #15)
[older apps]
that would cover re-volt, it was a win98 game.
...I wonder if we should close this bug as being a 'misnomer', and have folks
submit bugs on a per app basis, to better vet the situation...
I know I don't have any weight in this conversation at all, but I don't agree with this. fundamentally, if the point of wine is to "run windows apps without installing windows", then it should be able to do the same things windows can. if xp/win7/etc can auto-translate usb devices in such a way that older games can use them seamlessly, then wine should be able to do that too. otherwise you just end up given credence to the "wine never works, just dual boot" people.
I think you misunderstood me - what I'm saying is the issue is present in both linux and OSX ; it's not just a Mac thing (which is what this bug's Subject suggests) -- fact is, Mac OSX joystick support *does* work, but this entirely depends on which app you're talking about, and when we're talking about older apps, USB HID input doesn't work in linux -either- most of time ; if you want to tag this bug with Mac OSX and have it tarnish the look of an Apple, that's fine - I personally do not think it's justified however ;)
I do not for a minute think everything is *right* with USB HID input on OSX, what I posit is that there's something more fundamentally awry here that effects both platforms...and hey...the Mac's copping all the blame <grin>..
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #19 from Mr Nobody limited_choice@hotmail.com 2011-01-01 01:21:50 CST --- Okay....confirming that situation wrt Red Baron 3D -- USB HID works in linux with this title but not so in OSX....wine-1.3.10 on both machines.
..that's actually wrong ; USB HID works with DosBox in linux and not with OSX...
I think dosbox in itself is enough of a test app (should've thought of this earlier ;) -- you can grab the win32 port of dosbox, install it into wine, you don't need an app, just launch the input mapper (wine dosbox.exe -startmapper).
In linux, the Saitek ST-90 is immediately visible in the mapper interface ; you don't have to touch anything - even the digital throttle works as expected.
In OSX, nada -- neither the USB HID device descriptor is seen by the mapper, nor any data obviously ... if we're not hitting the emulator, it'll never get to the app...(and if we're not hitting the doxbox emulator, likely other win32 apps are so disposed too).
This is only one facet here though - but a good place to start. We still have cases where, like with IL-2, USB HID isn't seen by either OSX or linux in wine, but a gameport connected HID works fine in linux with it (btw, I grabbed the Steam version of IL-2 Sturmovik 1946 and it's misbehaving the same way), and I know of a few apps that don't want to see the xpad in OSX but work fine with such in linux (but this is possibly disparity between the 360controller driver and the linux xpad.ko driver).
As I understand it, Aric Stewart did most of the recent work with the OSX joystick driver in wine - we probably need some of his wisdom here.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #20 from david.dljunk@gmail.com 2011-01-01 01:59:22 CST --- (In reply to comment #19)
Okay....confirming that situation wrt Red Baron 3D -- USB HID works in linux with this title but not so in OSX....wine-1.3.10 on both machines.
..that's actually wrong ; USB HID works with DosBox in linux and not with OSX...
I think dosbox in itself is enough of a test app (should've thought of this earlier ;) -- you can grab the win32 port of dosbox, install it into wine, you don't need an app, just launch the input mapper (wine dosbox.exe -startmapper).
In linux, the Saitek ST-90 is immediately visible in the mapper interface ; you don't have to touch anything - even the digital throttle works as expected.
In OSX, nada -- neither the USB HID device descriptor is seen by the mapper, nor any data obviously ... if we're not hitting the emulator, it'll never get to the app...(and if we're not hitting the doxbox emulator, likely other win32 apps are so disposed too).
This is only one facet here though - but a good place to start. We still have cases where, like with IL-2, USB HID isn't seen by either OSX or linux in wine, but a gameport connected HID works fine in linux with it (btw, I grabbed the Steam version of IL-2 Sturmovik 1946 and it's misbehaving the same way), and I know of a few apps that don't want to see the xpad in OSX but work fine with such in linux (but this is possibly disparity between the 360controller driver and the linux xpad.ko driver).
As I understand it, Aric Stewart did most of the recent work with the OSX joystick driver in wine - we probably need some of his wisdom here.
Interesting I've never tried to get the Windows version of DosBox working in Wine. However, I can report that the normal OS X version of DosBox through Boxer finds the joystick (at least the games I run in it seem to recognize the joystick's axes). :)
Well ... best of luck and btw ... happy new years. :)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #21 from Mr Nobody limited_choice@hotmail.com 2011-01-01 03:01:52 CST --- errata: wrt IL-2 Sturmovik 1946 (Steam), even the USB joystick in linux *has* to appear at /dev/js0 or it doesn't work (too many HIDs, I forgot to unplug one ;) -- a retest with the USB Saitek ST-90 joystick @ /dev/js0 discloses IL-2 *does* see the USB HID in linux, but *only* if it's the first joystick device.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #22 from david.dljunk@gmail.com 2011-01-03 14:51:39 CST --- (In reply to comment #21)
errata: wrt IL-2 Sturmovik 1946 (Steam), even the USB joystick in linux *has* to appear at /dev/js0 or it doesn't work (too many HIDs, I forgot to unplug one ;) -- a retest with the USB Saitek ST-90 joystick @ /dev/js0 discloses IL-2 *does* see the USB HID in linux, but *only* if it's the first joystick device.
So if I can sum up the thread, even just for my own sake, we have 3 applications where USB joysticks (HID devices) work in Wine-Linux but not Wine-OS X: IL-2, Red Baron 3D, and DosBox. We have 1 application where a USB HID device works in Wine-OS X: Flatout. Does this give any indication of where the problems may lie?
P.S. Upon re-reading the thread, I think there is some confusion over Red Baron 3D and DosBox. Red Baron 3D doesn't use DosBox. DosBox is only for Red Baron 1. GOG's installer for the Red Baron pack forces you to install DosBox even if you don't install Red Baron 1, which confused me at first too, made me think RedBaron 3D was a game requiring DosBox. But, in fact, Red Baron 3D is a regular windows app. I have Red Baron 3D running on both Windows 7 and OS X (minus joystick functionality in OS X of course) without DosBox. So where Red Baron 3D and DosBox don't see a joystick, those are actually two different examples of applications not reading the USB HID device through Wine in OS X.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #23 from Mr Nobody limited_choice@hotmail.com 2011-01-03 21:27:12 CST --- (In reply to comment #22)
P.S. Upon re-reading the thread, I think there is some confusion over Red Baron 3D and DosBox. Red Baron 3D doesn't use DosBox. DosBox is only for Red Baron 1. GOG's installer for the Red Baron pack forces you to install DosBox even if you don't install Red Baron 1, which confused me at first too, made me think RedBaron 3D was a game requiring DosBox. But, in fact, Red Baron 3D is a regular windows app. I have Red Baron 3D running on both Windows 7 and OS X (minus joystick functionality in OS X of course) without DosBox. So where Red Baron 3D and DosBox don't see a joystick, those are actually two different examples of applications not reading the USB HID device through Wine in OS X.
This would be correct, apols for not mentioning as much...it was during my test of the GoG Red Baron pack that I discovered dosbox wasn't seeing USB HID ; you are right, Red Baron 3D doesn't use dosbox ; that said, if USB HID is working in linux with dosbox, same should be so for OSX. Dosbox just stands out as a test target in my mind, as it's open source and the devs will be able to exactly determine what input method the win32 port uses that isn't working in OSX with wine. Sorry for any confusion.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #24 from doh123@gmail.com 2011-01-04 13:54:09 CST --- (In reply to comment #22)
So if I can sum up the thread, even just for my own sake, we have 3 applications where USB joysticks (HID devices) work in Wine-Linux but not Wine-OS X: IL-2, Red Baron 3D, and DosBox. We have 1 application where a USB HID device works in Wine-OS X: Flatout. Does this give any indication of where the problems may lie?
Vega Strike... I haven't tested it in about 6 months, so it might need to be tested again, but I fought with it for awhile.
Vega Strike windows version in windows, my joystick works fine.
Vega Strike Mac version in OSX, my joystick works fine.
Vega Strike Windows version in Wine, Joystick doesn't work at all.
The Mac version has poor support and sometimes hard to get to work with 3rd party mods... so that is why I was trying...
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #25 from david.dljunk@gmail.com 2011-01-06 02:01:42 CST --- (In reply to comment #23)
This would be correct, apols for not mentioning as much...it was during my test of the GoG Red Baron pack that I discovered dosbox wasn't seeing USB HID ; you are right, Red Baron 3D doesn't use dosbox ; that said, if USB HID is working in linux with dosbox, same should be so for OSX. Dosbox just stands out as a test target in my mind, as it's open source and the devs will be able to exactly determine what input method the win32 port uses that isn't working in OSX with wine. Sorry for any confusion.
Got it. In fact, like doh's example of Vega Strike in the previous post, DosBox also has an OSX version with working USB joystick reader code. That might provide some additional info or insight into this bug. Maybe. :)
Has anyone ever tried using SDL (http://www.libsdl.org/index.php) or anything like that in WINE? I notice SDL has joystick code for OSX, Linux, and Win32. Do you think adding the SDL source code to the WINE engine would help any? Or perhaps a code-to-code comparison for the different treatments of joysticks in SDL vs. WINE would lead somewhere? (or perhaps even doing something like that for DosBox vs WINE since DosBox's OSX version also supports joysticks?)
It seems like some people have made SDL.dlls for WINE (http://bugs.winehq.org/show_bug.cgi?id=10086) - perhaps using an SDL.dll for OSX joystick to replace/augment dinput would work? How would one go about doing something like that?
Or am I talking out of my ***? Feel free to tell me it's the last option. :) I fully admit that I know very little about which I speak.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #26 from david.dljunk@gmail.com 2011-01-06 02:07:09 CST --- btw I do know enough to recognize that SDL code and dll's are for SDL-based games ... however, I was thinking if SDL code can recognize joysticks properly is OSX (and to be honest I haven't tested in OSX SDL games to know that it does work properly) then maybe comparing to code that works could improve dinput for OSX. Also I believe DosBox uses SDL for some things (though not for joysticks I believe - at least for v0.73).
Again, probably speaking out of my ***. :)
http://bugs.winehq.org/show_bug.cgi?id=18424
sagarp14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagarp14@gmail.com
--- Comment #27 from sagarp14@gmail.com 2011-01-10 14:49:39 CST --- I am trying to use my sony playstation 3 dualshock 3 controller for project64. When I go to configure the plugin (N-rages Directinput8 V2 1.80a) it does not recognize the controller under the "devices" tab.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #28 from david.dljunk@gmail.com 2011-02-03 23:01:00 CST --- Just checking in ... has there been any progress? Mr. Nobody is this something you've been looking into or do you think this topic requires the interest of full-on wine-dev? Should I attempt another well-worded appeal? :) (thanks for the kudos btw)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #29 from Mr Nobody limited_choice@hotmail.com 2011-02-05 05:56:08 CST --- (In reply to comment #28)
Just checking in ... has there been any progress? Mr. Nobody is this something you've been looking into or do you think this topic requires the interest of full-on wine-dev? Should I attempt another well-worded appeal? :) (thanks for the kudos btw)
Not that I know of - I do chat online with one of the wine-devs involved for/with introducing the OSX joystick support, but I haven't had the opportunity to natter about this issue yet (he's a very busy fellow). I believe there's enough information here for the devs to isolate test case(s) to check against...I certainly believe there's enough interest from the Mac quarter to warrant someone steering this to a live-happily-ever-after ending, going by the number of posts about the place I see wrt (particularly IL-2) not having joystick HID input in OSX in many win32 games. I think I understand what's happening (or rather not happening as the case may be), but I don't know OSX at all well, I've only had the iMac for < 1yr ; yes, we really need a dev or other wine hacker familiar with OSX to poke at this with burning incense sticks to help get that funny smell of rotten Apples out of the dinput hallway carpet =) Hopefully the planets will realign soon again, now that MacWorld has been and gone, and I can find out something more about the whys of this...it all takes time...;)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #30 from david.dljunk@gmail.com 2011-02-07 13:38:13 CST --- (In reply to comment #29)
Not that I know of - I do chat online with one of the wine-devs involved for/with introducing the OSX joystick support, but I haven't had the opportunity to natter about this issue yet (he's a very busy fellow). I believe there's enough information here for the devs to isolate test case(s) to check against...I certainly believe there's enough interest from the Mac quarter to warrant someone steering this to a live-happily-ever-after ending, going by the number of posts about the place I see wrt (particularly IL-2) not having joystick HID input in OSX in many win32 games. I think I understand what's happening (or rather not happening as the case may be), but I don't know OSX at all well, I've only had the iMac for < 1yr ; yes, we really need a dev or other wine hacker familiar with OSX to poke at this with burning incense sticks to help get that funny smell of rotten Apples out of the dinput hallway carpet =) Hopefully the planets will realign soon again, now that MacWorld has been and gone, and I can find out something more about the whys of this...it all takes time...;)
Sounds good, thanks! :)
http://bugs.winehq.org/show_bug.cgi?id=18424
Szabolcs Illes s.illes79@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |s.illes79@gmail.com
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!
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #32 from david.dljunk@gmail.com 2011-02-21 04:34:28 CST --- (In reply to comment #31)
/snip
Very interesting and informative! Thanks for the info and give my thanks to Aric too.
And now a bunch of questions!
So how would one find out about what input method a specific program uses? Does Wine in Linux have direct-serial support? In other words if someone gets xinput working in Wine-OSX could I be reasonably assured that if a program had joystick support in Linux that it would also have joystick support in OSX? I ask of course because I would love to get Red Baron 3D working on my OSX partition and unfortunately it is an old game. However, it has been released several times since its original debut and it does work in Windows 7 with both the standard Windows drivers and the Logitech specific ones. It also works in Wine-Linux. Does that mean it has a good chance of using xinput? As per my first question, how would I find out for sure?
Again, thanks for the info and your curiosity. Hopefully whoever takes an interest in this problem will have a smooth road solving it. As a programmer myself, I know that's asking a lot, but one can still hope. :)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #33 from david.dljunk@gmail.com 2011-02-25 16:09:01 CST --- Upon rereading, Wine-Linux has direct serial connection support.
However, that should only a concern if one is using an serial port to connect a joystick, right? So for the USB joysticks/game controllers, only xinput and dinput matter. Have I got the gist of it?
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #34 from Mr Nobody limited_choice@hotmail.com 2011-02-27 02:40:45 CST --- (In reply to comment #33)
Upon rereading, Wine-Linux has direct serial connection support.
However, that should only a concern if one is using an serial port to connect a joystick, right? So for the USB joysticks/game controllers, only xinput and dinput matter. Have I got the gist of it?
That's about the sum of it -- once the xinput stuff is there for OSX both the linux & mac camps should be on equal footing with dinput/xinput. The older (pre directx) method that works in linux (but would be troublesome to implement in OSX) should, in theory, only affect older win32 apps ; to get a feel of that by looking at it historically...see;
http://en.wikipedia.org/wiki/DirectInput
YoW!
http://bugs.winehq.org/show_bug.cgi?id=18424
slyhigh egglayingwoolmilksow@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |egglayingwoolmilksow@gmail. | |com
http://bugs.winehq.org/show_bug.cgi?id=18424
Jonas Maebe jonas.bugzilla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.bugzilla@gmail.com
--- Comment #35 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-16 04:08:28 CDT --- I looked into this last night after buying Duke Nukem: Manhattan Project from GOG and trying to play it with a Playstation 3 controller. The game saw and correctly identified the controller, but did not react to any button presses. Nevertheless the wine/dlls/dinput/tests/joystick.c test worked fine and did detect all button presses in interactive mode.
The problem with that game is unrelated to xinput. xinput is also still stubbed on all platforms, as far as I can tell.
The problem was that while the Mac OS X joystick support code detects all (HID-supported) joysticks, button presses and stick movements, it does not actually put any events into the DirectInput queue. As a result, not even pure DirectInput games work with joysticks on Mac OS X right now. To prevent such problems in the future, maybe the dinput joystick test should be extended to also test the dintput event queue (but doing so is beyond my abilities).
After fixing that bug the controller worked fine! There are two minor issues, but they're not show stoppers: a) the game is only able to identify the first 12 buttons found by the HID code. It does recognise presses of the other buttons in the configuration screen, but is not able to attach any name to them and they also don't work during gameplay. Maybe that's due to wine identifying the controller as a joystick rather than as a gamepad (I don't know whether simply changing the identification from joystick to gamepad is safe, or whether you have to use a different interface in that case) b) the buttons are mislabeled in the game: the dpad buttons are recognised as buttons 5-6-7-8, and the buttons on the right hand side are identified as a dpad. It also detects moving one of the two sticks as equivalent to pressing the corresponding "dpad" button (which, as mentioned before, are not actually the dpad buttons), which is a bit more annoying.
I'll attach the patch to fix the event queue problem tonight when I'm back home.
http://bugs.winehq.org/show_bug.cgi?id=18424
Paul The Tall paulthetall@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paulthetall@gmail.com
--- Comment #36 from Paul The Tall paulthetall@gmail.com 2011-06-16 04:13:56 CDT --- Great! Will it be implanted in the next wine release?
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #37 from Mr Nobody limited_choice@hotmail.com 2011-06-16 10:25:17 CDT --- (In reply to comment #35)
I looked into this last night after buying Duke Nukem: Manhattan Project from GOG and trying to play it with a Playstation 3 controller. The game saw and correctly identified the controller, but did not react to any button presses. Nevertheless the wine/dlls/dinput/tests/joystick.c test worked fine and did detect all button presses in interactive mode.
The problem with that game is unrelated to xinput. xinput is also still stubbed on all platforms, as far as I can tell.
The problem was that while the Mac OS X joystick support code detects all (HID-supported) joysticks, button presses and stick movements, it does not actually put any events into the DirectInput queue. As a result, not even pure DirectInput games work with joysticks on Mac OS X right now. To prevent such problems in the future, maybe the dinput joystick test should be extended to also test the dintput event queue (but doing so is beyond my abilities).
After fixing that bug the controller worked fine! There are two minor issues, but they're not show stoppers: a) the game is only able to identify the first 12 buttons found by the HID code. It does recognise presses of the other buttons in the configuration screen, but is not able to attach any name to them and they also don't work during gameplay. Maybe that's due to wine identifying the controller as a joystick rather than as a gamepad (I don't know whether simply changing the identification from joystick to gamepad is safe, or whether you have to use a different interface in that case) b) the buttons are mislabeled in the game: the dpad buttons are recognised as buttons 5-6-7-8, and the buttons on the right hand side are identified as a dpad. It also detects moving one of the two sticks as equivalent to pressing the corresponding "dpad" button (which, as mentioned before, are not actually the dpad buttons), which is a bit more annoying.
I'll attach the patch to fix the event queue problem tonight when I'm back home.
Hi Jonas, thanks for taking a look at it. 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 =)...
...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. 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 ...
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #38 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-16 10:57:14 CDT --- Created an attachment (id=35160) --> (http://bugs.winehq.org/attachment.cgi?id=35160) Hook up Mac OS X joysticks to DirectInput event queue
Here's the aforementioned patch.
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.
http://bugs.winehq.org/show_bug.cgi?id=18424
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #40 from Austin English austinenglish@gmail.com 2011-06-16 13:19:12 CDT --- Patches should be sent to wine-patches@winehq.org. They are not picked up from bugzilla.
Cheers.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #41 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-16 14:14:26 CDT --- (In reply to comment #40)
Patches should be sent to wine-patches@winehq.org. They are not picked up from bugzilla.
Done, thanks for the heads up.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #42 from david.dljunk@gmail.com 2011-06-17 01:41:27 CDT --- (In reply to comment #35)
I looked into this last night after buying Duke Nukem: Manhattan Project from GOG and trying to play it with a Playstation 3 controller. The game saw and correctly identified the controller, but did not react to any button presses. Nevertheless the wine/dlls/dinput/tests/joystick.c test worked fine and did detect all button presses in interactive mode.
The problem with that game is unrelated to xinput. xinput is also still stubbed on all platforms, as far as I can tell.
The problem was that while the Mac OS X joystick support code detects all (HID-supported) joysticks, button presses and stick movements, it does not actually put any events into the DirectInput queue. As a result, not even pure DirectInput games work with joysticks on Mac OS X right now. To prevent such problems in the future, maybe the dinput joystick test should be extended to also test the dintput event queue (but doing so is beyond my abilities).
After fixing that bug the controller worked fine! There are two minor issues, but they're not show stoppers: a) the game is only able to identify the first 12 buttons found by the HID code. It does recognise presses of the other buttons in the configuration screen, but is not able to attach any name to them and they also don't work during gameplay. Maybe that's due to wine identifying the controller as a joystick rather than as a gamepad (I don't know whether simply changing the identification from joystick to gamepad is safe, or whether you have to use a different interface in that case) b) the buttons are mislabeled in the game: the dpad buttons are recognised as buttons 5-6-7-8, and the buttons on the right hand side are identified as a dpad. It also detects moving one of the two sticks as equivalent to pressing the corresponding "dpad" button (which, as mentioned before, are not actually the dpad buttons), which is a bit more annoying.
I'll attach the patch to fix the event queue problem tonight when I'm back home.
That's fantastic news! Thank you!
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #43 from Mr Nobody limited_choice@hotmail.com 2011-06-17 04:47:34 CDT --- (In reply to comment #38)
Created an attachment (id=35160)
--> (http://bugs.winehq.org/attachment.cgi?id=35160) [details]
Hook up Mac OS X joysticks to DirectInput event queue
Here's the aforementioned patch.
Applied the above patch to a pristine wine-1.3.22 - compile & install (MacOSX 10.6.7) -- ~/.wine was destroyed & recreated ; fresh app installs with $homedir cleansed of any app config dirs/files ... note: make sure you don't have any helper app like 'USB Overdrive' running & active on the HID being used.
For the sake of the bug, I'm here just testing with a USB connected Saitek ST90 analog joystick - it has 6 readable inputs (X, Y, F1, F2, Trigger & digital throttle). There are so many apps affected by this, I figured I'd just start with those mentioned here first...
GOG release of RedBaron / RedBaron 3D (wherein the former title is hoisted on DosBox and the latter is a standalone app) ; no improvement in either, joystick events still not being recognized... (in the dosbox case with the -startmapper cli switch, it's apparent no joystick events are being seen by dosbox still)
Steam release of IL-2: Sturmovik 1946 -- this app now *does* see the joystick, but it had little idea what to do with the digital throttle. (I have the GOG release of this title as well, which I've yet to check). One would need be careful prejudging results with flight-sims ; a single X/Y axis joystick really isn't enough to fly a 'real' plane with, and some flight sims are hardcoded to expect to see rudder bars/pedals ... point is, the hardcoded config and what your HID offers don't always make sense, and often there's little scope to remap things to your liking...
..in short, nice work Jonas! Definitely a step forward, but as I suspected, there's still a few wrinkles to consider...ie; why does RedBaron 3D work with joystick in linux, and still not here even with the patch... I've still a number of HIDs & win32 apps to check, but at least seeing joystick in IL-2 is encouraging & positive ....
..if you need any specific testing done/logs etc etc, just let me know -- you've made the itch worse =)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #44 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-17 06:26:11 CDT --- (In reply to comment #43)
(In reply to comment #38)
Created an attachment (id=35160)
--> (http://bugs.winehq.org/attachment.cgi?id=35160) [details] [details]
Hook up Mac OS X joysticks to DirectInput event queue
Here's the aforementioned patch.
Applied the above patch to a pristine wine-1.3.22
For completeness sake: I only tested with 1.3.17. I'm not updating because of bug 27156
The Mac OS X joystick code has not changed between 1.3.17 and git head though.
GOG release of RedBaron / RedBaron 3D (wherein the former title is hoisted on DosBox and the latter is a standalone app) ; no improvement in either, joystick events still not being recognized... (in the dosbox case with the -startmapper cli switch, it's apparent no joystick events are being seen by dosbox still)
Steam release of IL-2: Sturmovik 1946 -- this app now *does* see the joystick, but it had little idea what to do with the digital throttle.
It's strange that previously it didn't see the joystick and now it does. I did not change anything whatsoever to the joystick detection code (and as mentioned in my original message, in my case the gamepad was already seen before I applied my patch).
(I have the GOG release of this title as well, which I've yet to check). One would need be careful prejudging results with flight-sims ; a single X/Y axis joystick really isn't enough to fly a 'real' plane with, and some flight sims are hardcoded to expect to see rudder bars/pedals ... point is, the hardcoded config and what your HID offers don't always make sense, and often there's little scope to remap things to your liking...
The current joystick code can report up to six regular axes (X, Y, Z, and then "rotation" variants of those same axes), an "unlimited" number of additional axes (translated from HID "slider" controls), and an "unlimited" number of POV (point-of-view) controls. "Unlimited" in this context means "as long as the total number of controls, including buttons, is <= 127".
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #45 from Mr Nobody limited_choice@hotmail.com 2011-06-17 07:11:12 CDT --- (In reply to comment #44)
(In reply to comment #43)
(In reply to comment #38)
Created an attachment (id=35160)
--> (http://bugs.winehq.org/attachment.cgi?id=35160) [details] [details] [details]
Hook up Mac OS X joysticks to DirectInput event queue
Here's the aforementioned patch.
Applied the above patch to a pristine wine-1.3.22
For completeness sake: I only tested with 1.3.17. I'm not updating because of bug 27156
The Mac OS X joystick code has not changed between 1.3.17 and git head though.
GOG release of RedBaron / RedBaron 3D (wherein the former title is hoisted on DosBox and the latter is a standalone app) ; no improvement in either, joystick events still not being recognized... (in the dosbox case with the -startmapper cli switch, it's apparent no joystick events are being seen by dosbox still)
Steam release of IL-2: Sturmovik 1946 -- this app now *does* see the joystick, but it had little idea what to do with the digital throttle.
It's strange that previously it didn't see the joystick and now it does. I did not change anything whatsoever to the joystick detection code (and as mentioned in my original message, in my case the gamepad was already seen before I applied my patch).
<snip>
..apologies, I wasn't precisely clear about this -- IL-2 doesn't declare whether a HID is available or not - what I should've said was that previously (without the patch) IL-2 wasn't seeing any HID *data* ; with the patch, it does....
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #46 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-17 07:37:41 CDT --- (In reply to comment #45)
..apologies, I wasn't precisely clear about this -- IL-2 doesn't declare whether a HID is available or not - what I should've said was that previously (without the patch) IL-2 wasn't seeing any HID *data* ; with the patch, it does....
Ah, I see. That's indeed progress then.
PS, regarding DOSBox: it probably uses SDL for its joystick input, and SDL does not use DirectInput. Instead, it uses functions such as joyGetNumDevs() from winmm. That dll is implemented in wine, but as far as I can tell it depends on joystick-specific drivers to provide the actual support. I guess that's the "direct serial connection" support mentioned in earlier messages. So it's normal that my patch does not change anything about that.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #47 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-17 10:43:30 CDT --- (In reply to comment #46)
PS, regarding DOSBox: it probably uses SDL for its joystick input, and SDL does not use DirectInput.
I've just noticed that the development versions of SDL have added DirectInput support under Windows. So if you rebuild DOSBox against SDL 1.3, things may work better.
I've also seen that the Linux code allows Windows apps to remap the axes based on registry keys while the Mac code doesn't. You may want to try to adding a call to setup_dinput_options() (possibly along with some support code to make it possible to use the remapping information afterwards) to the Mac OS X code like in the Linux code at http://source.winehq.org/source/dlls/dinput/joystick_linuxinput.c#L474
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #48 from Austin English austinenglish@gmail.com 2011-06-17 13:31:46 CDT --- (In reply to comment #41)
(In reply to comment #40)
Patches should be sent to wine-patches@winehq.org. They are not picked up from bugzilla.
Done, thanks for the heads up.
Committed: http://source.winehq.org/git/wine.git/commitdiff/90d8608185e44c4c1973d163568...
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #49 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-17 13:36:05 CDT --- (In reply to comment #48)
Committed: http://source.winehq.org/git/wine.git/commitdiff/90d8608185e44c4c1973d163568...
Great :)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #50 from david.dljunk@gmail.com 2011-06-19 03:49:55 CDT --- (In reply to comment #49)
(In reply to comment #48)
Committed: http://source.winehq.org/git/wine.git/commitdiff/90d8608185e44c4c1973d163568...
Great :)
I was wondering if I could be of help in diagnosis ... I have some flight simulators and a joystick I'd like to try out. However, I don't have git, but since this is the only commit I want to try out, can I just download a clean copy of a Wine engine source code and copy-paste your new joystick code into joystick_osx.c? Cheers!
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #51 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-19 11:33:23 CDT --- (In reply to comment #50)
I was wondering if I could be of help in diagnosis ...
Just to make it clear: I personally probably won't work further on this (except maybe some things to improve the PS3 controller behaviour). Of course, any diagnostics information you post can be useful to other people interested in working on this.
I have some flight simulators and a joystick I'd like to try out. However, I don't have git, but since this is the only commit I want to try out, can I just download a clean copy of a Wine engine source code and copy-paste your new joystick code into joystick_osx.c?
Yes, you can do that (since the changes do not depend on any other recent wine changes). Rather than copy-pasting, it's however better to copy the patch inside the wine directory, then open a terminal window, change into the wine directory and type patch -p1 < name_you_gave_to_the_patch_file
Note that building wine is not that easy because of all the extra dependencies. I also had to force gcc to generate 32 bit code for the configure process to finish successfully, even though the wiki says that this should no longer be necessary.
In general, I've found the easiest way to build wine is to use http://code.google.com/p/osxwinebuilder/ (it automatically downloads all dependencies and deals with all special parameter requirements), but the downside is that it has no support for applying patches.
Given that wine has a 2 week release cycle for the unstable branch (at least that's what I read somewhere on the wiki), the next unstable release that includes this patch should be out in about 5 days though (and then you should be able to use osxwinebuilding without any special options).
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #52 from david.dljunk@gmail.com 2011-06-23 01:57:39 CDT --- I put the patch manually into a fresh 1.3.18 source code and compiled it in Wineskin. I am using a Logitech Extreme 3D pro. I can confirm Mr. Nobody's results that the GOG version of Red Baron 3D still does not see joystick commands but that the joystick can now control flight in IL-2 Sturmovik (GOG version). My joystick uses a slider rather than a digital throttle and the slider works. So IL-2 at least appears to have full functionality for my joystick! (I have yet to test if ALL buttons work, but the trigger does and that's what counts the most :P.) I think I will next test Independence War 1 (space sim). Again, thanks for the patch!
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #53 from david.dljunk@gmail.com 2011-06-23 20:56:47 CDT --- Sadly the patch does not seem to have helped give joystick control in Independence War 1. Both Independence War 1 and Red Baron 3D are late 90's games so they may be using the same version of dinput.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #54 from Mr Nobody limited_choice@hotmail.com 2011-06-23 23:38:43 CDT --- (In reply to comment #47)
(In reply to comment #46)
PS, regarding DOSBox: it probably uses SDL for its joystick input, and SDL does not use DirectInput.
I've just noticed that the development versions of SDL have added DirectInput support under Windows. So if you rebuild DOSBox against SDL 1.3, things may work better.
...wrt the win32 build of DOSBox, that would be correct ... however as Aric already indicated to me, there was/is some nastiness involved with getting that older method to work with the wine OSX dinput stuffs (to the point he didn't think it wouldn't get done 'any time soon' ;) That said, consideration of the DOSBox kind of situations (many GOG titles are hoisted/bundled with win32 DOSBox), is possibly a tad moot, because instead of going OS <-> wine <-> win32 emul <-> app, one can do OS <-> OS port of emul <-> app instead, and not use wine at all. I just checked this using the OSX binaries of DOSBox 0.74, and it immediately recognized & bound the Saitek ST90 as a 3 axis, 3 button USB Stick to the appropriate DOS input structures...
I only mention this, here, because I know the GOG Red Baron Pack (and quite a number of other GOG titles) are run/bundled with the win32 build of DOSBox, and in such cases, an alternative is to use wine to install the GOG release, and then move the content 'somewhere else' and replace the win32 DOSBox.exe with the OS-native DOSBox binary, and run the game using that - it should then work 'as expected' with your USB connected HID(s) ... in the GOG Red Baron Pack, you should probably run the older DOS game in that pack this way... the newer '3D' version of Red Baron in the same GOG bundle, is still subject to this bug.
I've also seen that the Linux code allows Windows apps to remap the axes based on registry keys while the Mac code doesn't. You may want to try to adding a call to setup_dinput_options() (possibly along with some support code to make it possible to use the remapping information afterwards) to the Mac OS X code like in the Linux code at http://source.winehq.org/source/dlls/dinput/joystick_linuxinput.c#L474
Thanks for the pointer ... I'll find some time this w/e and see if I can get a trace on what's happening in linux wrt the apps that haven't improved here in OSX and see if that functionality is being used. Regardless, getting IL-2 (and others like it) working is a boon =)
http://bugs.winehq.org/show_bug.cgi?id=18424
Molochmac jlspecht@noos.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jlspecht@noos.fr
--- Comment #55 from Molochmac jlspecht@noos.fr 2011-06-24 04:11:55 CDT --- (In reply to comment #52)
I put the patch manually into a fresh 1.3.18 source code and compiled it in Wineskin. I am using a Logitech Extreme 3D pro. I can confirm Mr. Nobody's results that the GOG version of Red Baron 3D still does not see joystick commands but that the joystick can now control flight in IL-2 Sturmovik (GOG version). My joystick uses a slider rather than a digital throttle and the slider works. So IL-2 at least appears to have full functionality for my joystick! (I have yet to test if ALL buttons work, but the trigger does and that's what counts the most :P.) I think I will next test Independence War 1 (space sim). Again, thanks for the patch!
I'm not sure this is the place to ask, but could you tell me how you "patched" Wine ? Wich doc do you open, to copy what where ? I got an old Microsoft Sidewinder 3d (force feedback), wich i'd like to use in Sturmovik and Combat Flight Sim 3… By the way, don't understand why the ports of FSX and Falcon 4 work with the joystick, and not Sturmovik ?… Would it help to install the Microsoft driver that came with the joytick ? I tried it, but the installer does'nt see any USB port…
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #56 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-24 04:27:03 CDT --- (In reply to comment #53)
Sadly the patch does not seem to have helped give joystick control in Independence War 1. Both Independence War 1 and Red Baron 3D are late 90's games so they may be using the same version of dinput.
They probably don't use DirectInput at all, but the "winmm" interface (just like SDL 1.2.x on Windows). That one is not hooked up on Mac OS X at this time (and my patch does not change anything about that).
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #57 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-24 04:33:19 CDT --- (In reply to comment #54)
(In reply to comment #47)
I've also seen that the Linux code allows Windows apps to remap the axes based on registry keys while the Mac code doesn't. You may want to try to adding a call to setup_dinput_options() (possibly along with some support code to make it possible to use the remapping information afterwards) to the Mac OS X code like in the Linux code at http://source.winehq.org/source/dlls/dinput/joystick_linuxinput.c#L474
Thanks for the pointer ... I'll find some time this w/e and see if I can get a trace on what's happening in linux wrt the apps that haven't improved here in OSX and see if that functionality is being used.
That's different. The ones that work on Linux but not at all on Mac OS X probably use the aforementioned winmm interface. That one is implemented for Linux (in joystick_linux.c), but not for Mac OS X (joystick_osx.c only contains the DirectInput implementation).
My suggestion was only regarding getting your joystick to work better with IL-2 (maybe the game has some registry keys that remap the control that wasn't working for you under Mac OS X, but which does work under Linux).
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #58 from david.dljunk@gmail.com 2011-06-25 04:41:31 CDT --- (In reply to comment #56)
(In reply to comment #53)
Sadly the patch does not seem to have helped give joystick control in Independence War 1. Both Independence War 1 and Red Baron 3D are late 90's games so they may be using the same version of dinput.
They probably don't use DirectInput at all, but the "winmm" interface (just like SDL 1.2.x on Windows). That one is not hooked up on Mac OS X at this time (and my patch does not change anything about that).
Interesting, I've never even heard of winmm before. Do you have a link describing it? I just sent a query to one of the I-war devs (he lurks on the GOG forums) over what joystick interface they used, dinput or winmm.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #59 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-25 04:50:13 CDT --- (In reply to comment #58)
Interesting, I've never even heard of winmm before.
See my comment 46 above :)
Do you have a link describing it?
No, just the wine source code: http://source.winehq.org/source/dlls/winmm/joystick.c
Googling (winmm joystick) also gives quite a few hits.
PS for those that didn't see it yet: wine 1.3.23 has been released, and it includes the patch.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #60 from david.dljunk@gmail.com 2011-06-25 05:25:45 CDT --- (In reply to comment #59)
(In reply to comment #58)
Interesting, I've never even heard of winmm before.
See my comment 46 above :)
Do you have a link describing it?
No, just the wine source code: http://source.winehq.org/source/dlls/winmm/joystick.c
Googling (winmm joystick) also gives quite a few hits.
Ah I see now. Hmmm ... I hope that can be implemented in OS X like in Linux if that is what is stopping joysticks in Red Baron 3D and Independence War 1 from working.
PS for those that didn't see it yet: wine 1.3.23 has been released, and it includes the patch.
Yes I had noticed the 1.3.23 has been released with the patch. :) I haven't tried it yet, but running the 1.3.18 version I did get the following fixmes:
fixme:dinput:SysMouseWImpl_Acquire Clipping cursor to (0,0)-(1920,1080) fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:wave:wodDsCreate DirectSound not implemented fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead. fixme:wave:AudioUnit_SetVolume independent left/right volume not implemented (1.000000, 1.000000) fixme:wave:wodDsCreate DirectSound not implemented fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead.
The middle ones are to do with get_osx_device_elements ... any idea what that is about?
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #61 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-25 05:51:52 CDT --- (In reply to comment #60)
Yes I had noticed the 1.3.23 has been released with the patch. :) I haven't tried it yet, but running the 1.3.18 version I did get the following fixmes:
fixme:dinput:SysMouseWImpl_Acquire Clipping cursor to (0,0)-(1920,1080) fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:dinput:get_osx_device_elements Unhandled type 257 fixme:wave:wodDsCreate DirectSound not implemented fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead. fixme:wave:AudioUnit_SetVolume independent left/right volume not implemented (1.000000, 1.000000) fixme:wave:wodDsCreate DirectSound not implemented fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead.
The middle ones are to do with get_osx_device_elements ... any idea what that is about?
Yes, I also get them (and some others) for the PS3 controller. You can probably ignore them. Those controller element types correspond to kIOHIDElementTypeFeature, which according to Apple means "Describes input and output elements not intended for consumption by the end user".
I don't know who is supposed to consume them instead (or even who/what the "end user" is in this context) nor what they mean, but they definitely do not correspond to buttons, hat switches, axes, force feedback (which isn't supported yet in the OS X code either, fwiw), and the like.
It's possible that they could nevertheless be passed on to DirectInput in a meaningful way, but I don't know how since I don't know what they mean.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #62 from Mr Nobody limited_choice@hotmail.com 2011-06-25 18:09:20 CDT --- (In reply to comment #57)
(In reply to comment #54)
(In reply to comment #47)
I've also seen that the Linux code allows Windows apps to remap the axes based on registry keys while the Mac code doesn't. You may want to try to adding a call to setup_dinput_options() (possibly along with some support code to make it possible to use the remapping information afterwards) to the Mac OS X code like in the Linux code at http://source.winehq.org/source/dlls/dinput/joystick_linuxinput.c#L474
Thanks for the pointer ... I'll find some time this w/e and see if I can get a trace on what's happening in linux wrt the apps that haven't improved here in OSX and see if that functionality is being used.
That's different. The ones that work on Linux but not at all on Mac OS X probably use the aforementioned winmm interface. That one is implemented for Linux (in joystick_linux.c), but not for Mac OS X (joystick_osx.c only contains the DirectInput implementation).
..indeed, I checked Red Baron 3D and it seems to be using winmm:joyGetPosEx to obtain the joystick data, so likely it is you've hit the nail on the head here.. ..(but I don't know OSX anywhere near well enough to meld in the needed code)..
...I've also checked a few other (dinput) titles with wine-1.3.23 and whereas they didn't have joystick input before, now they do .. so that's a good win...
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #63 from david.dljunk@gmail.com 2011-06-26 04:32:08 CDT --- (In reply to comment #62)
(In reply to comment #57)
(In reply to comment #54)
(In reply to comment #47)
I've also seen that the Linux code allows Windows apps to remap the axes based on registry keys while the Mac code doesn't. You may want to try to adding a call to setup_dinput_options() (possibly along with some support code to make it possible to use the remapping information afterwards) to the Mac OS X code like in the Linux code at http://source.winehq.org/source/dlls/dinput/joystick_linuxinput.c#L474
Thanks for the pointer ... I'll find some time this w/e and see if I can get a trace on what's happening in linux wrt the apps that haven't improved here in OSX and see if that functionality is being used.
That's different. The ones that work on Linux but not at all on Mac OS X probably use the aforementioned winmm interface. That one is implemented for Linux (in joystick_linux.c), but not for Mac OS X (joystick_osx.c only contains the DirectInput implementation).
..indeed, I checked Red Baron 3D and it seems to be using winmm:joyGetPosEx to obtain the joystick data, so likely it is you've hit the nail on the head here.. ..(but I don't know OSX anywhere near well enough to meld in the needed code)..
...I've also checked a few other (dinput) titles with wine-1.3.23 and whereas they didn't have joystick input before, now they do .. so that's a good win...
One of the devs of I-war thought dinput was used for joysticks, but he wasn't sure. How would I check if something was dinput vs. winmm?
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #64 from Jonas Maebe jonas.bugzilla@gmail.com 2011-06-26 12:01:54 CDT --- (In reply to comment #62)
..indeed, I checked Red Baron 3D and it seems to be using winmm:joyGetPosEx to obtain the joystick data, so likely it is you've hit the nail on the head here.. ..(but I don't know OSX anywhere near well enough to meld in the needed code)..
I have also done next to no high level Mac OS X (or other OS) programming. My regular programming consists of working on linkers, dynamic instrumentation tools and compiler components.
But it's really not that hard. For the Mac OS X HID stuff, look at the HID Calibrator stuff I mentioned in comment 39, the HID headers (/System/Library/Frameworks/IOKit.framework/Headers/hid and .../hidsystem) and the existing code in joystick_osx.c. I also found the USB HID documentation useful for background information: http://www.usb.org/developers/devclass_docs/Hut1_11.pdf
The Linux DirectInput code is in joystick_linuxinpuc.c, the winmm code in joystick_linux.c. The code in both files seemed fairly similar at first sight. In fact, at first I had no idea why both were present and while searching for their purpose I found a thread on wine-devel where someone proposed merging them (but that was deemed to be not that easy because of the differences in models between winmm and dinput).
In any case, by putting linux_joystick.c and linux_joystickinput.c side by side, and joystick_osx.c next to that, I don't think it should be that hard to create a Mac OS X version for winmm. I don't have any games that require that though, and even if I had I currently don't really have time for it either.
...I've also checked a few other (dinput) titles with wine-1.3.23 and whereas they didn't have joystick input before, now they do .. so that's a good win...
Good!
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #65 from Mr Nobody limited_choice@hotmail.com 2011-06-26 20:37:35 CDT --- (In reply to comment #64)
I have also done next to no high level Mac OS X (or other OS) programming. My regular programming consists of working on linkers, dynamic instrumentation tools and compiler components.
But it's really not that hard. For the Mac OS X HID stuff, look at the HID Calibrator stuff I mentioned in comment 39, the HID headers (/System/Library/Frameworks/IOKit.framework/Headers/hid and .../hidsystem) and the existing code in joystick_osx.c. I also found the USB HID documentation useful for background information: http://www.usb.org/developers/devclass_docs/Hut1_11.pdf
The Linux DirectInput code is in joystick_linuxinpuc.c, the winmm code in joystick_linux.c. The code in both files seemed fairly similar at first sight. In fact, at first I had no idea why both were present and while searching for their purpose I found a thread on wine-devel where someone proposed merging them (but that was deemed to be not that easy because of the differences in models between winmm and dinput).
Hehe, don't worry - when I was actively into code it was 25+ years ago, involved BCPL and for the most part was mooted in the industrial sector ; I'm a real fish out of water around here most of the time ;)
Thanks for the additional clarity above -- I walked the same code and discovered the same things (but didn't find the wine-devel posting explaining why the two portions were being kept apart, thanks for that)... but at any rate, I figured I was looking at a whole new OSX portion needing to be done. In fact, doesn't the logic here maintain that the existing 'joystick_osx.c' should be renamed to 'joystick_osxinput.c' (this would follow the functional/namespace conventions of joystick_linuxinput.c). Likewise, if the code portion for winmm is in joystick_linux.c then same should be so for OSX with a new portion to support winmm in that? (which would be the namespace 'joystick_osx.c')...
...it was about there I muttered "Oh dear" to myself, and realized it was beyond my own experience. I might ask Aric about same ; he's much more familiar with these things and will know where the winmm stuff should go... oh, and should you find the time/inclination to look further at this and need an example win32 game to do same with, let me know - I'll happily purchase a candidate for you 8)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #66 from Mr Nobody limited_choice@hotmail.com 2011-06-28 20:49:15 CDT --- (In reply to comment #63)
One of the devs of I-war thought dinput was used for joysticks, but he wasn't sure. How would I check if something was dinput vs. winmm?
You just need to snoop (trace) the relevant winedebug channels (dinput, winmm, joystick) and observe the calls being made by the app. You need take a bit of care with winmm, as it's also (primarily?) an API for audio playback, and apps may still use this portion of it but derive the HID input data using dinput instead. My guess is this 'made sense' at the time, because most HIDs were connected via the midi/gameport that was part of older style soundcards. In any event, observing that RB3D was calling winmm:joyGetPosEx is enough of a daft clue =)
http://bugs.winehq.org/show_bug.cgi?id=18424
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.5 |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=18424
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #67 from Bruno Jesus 00cpxxx@gmail.com 2012-08-31 20:22:50 CDT --- Is this still an issue in wine 1.5.12 (or newer)?
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #68 from Jonas Maebe jonas.bugzilla@gmail.com 2012-09-01 02:57:33 CDT --- (In reply to comment #67)
Is this still an issue in wine 1.5.12 (or newer)?
There have been no patches/commits whatsoever to add support for joysticks via winmm for Mac OS X (nor have the Linux winmm/directinput joystick drivers been merged by making underlying changes to wine that enables it to share the joystick driver code for both programming models), so I can't imagine that it would suddenly automagically work.
I'm not the one with programs that use winmm for joystick support though, so I'll leave it up to others to test.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #69 from Szabolcs Illes s.illes79@gmail.com 2012-09-02 03:35:11 CDT --- works for me
I'm using wineskin (with wine 1.4) for osx and I can use a joystick and steering wheel in games.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #70 from Jonas Maebe jonas.bugzilla@gmail.com 2012-09-02 03:55:09 CDT --- (In reply to comment #69)
works for me
I'm using wineskin (with wine 1.4) for osx and I can use a joystick and steering wheel in games.
I can virtually guarantee you that those are all DirectInput games, which were fixed by the commit mentioned in comment #48.
The remaining problems are with games that use winmm to interface with the joystick, such as Independence War 1 and Red Baron 3D mentioned in comment #53.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #71 from Bruno Jesus 00cpxxx@gmail.com 2012-09-02 06:58:56 CDT --- Jonas, this winmm joystick issues affects only OSX? If the bug affects linux we could ask Lucas Zawacki to take a look.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #72 from Jonas Maebe jonas.bugzilla@gmail.com 2012-09-02 08:16:01 CDT --- (In reply to comment #71)
Jonas, this winmm joystick issues affects only OSX? If the bug affects linux we could ask Lucas Zawacki to take a look.
Yes, it's only Mac OS X. See comment #57.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #73 from david.dljunk@gmail.com 2013-01-30 05:13:25 CST --- (In reply to comment #64)
I have also done next to no high level Mac OS X (or other OS) programming. My regular programming consists of working on linkers, dynamic instrumentation tools and compiler components.
But it's really not that hard. For the Mac OS X HID stuff, look at the HID Calibrator stuff I mentioned in comment 39, the HID headers (/System/Library/Frameworks/IOKit.framework/Headers/hid and .../hidsystem) and the existing code in joystick_osx.c. I also found the USB HID documentation useful for background information: http://www.usb.org/developers/devclass_docs/Hut1_11.pdf
The Linux DirectInput code is in joystick_linuxinpuc.c, the winmm code in joystick_linux.c. The code in both files seemed fairly similar at first sight. In fact, at first I had no idea why both were present and while searching for their purpose I found a thread on wine-devel where someone proposed merging them (but that was deemed to be not that easy because of the differences in models between winmm and dinput).
In any case, by putting linux_joystick.c and linux_joystickinput.c side by side, and joystick_osx.c next to that, I don't think it should be that hard to create a Mac OS X version for winmm. I don't have any games that require that though, and even if I had I currently don't really have time for it either.
...I've also checked a few other (dinput) titles with wine-1.3.23 and whereas they didn't have joystick input before, now they do .. so that's a good win...
Good!
I'm probably totally off-base since I have even less experience. :) But from my limited understanding of the code, it would seem to be that joystick_osx and joystick_linux are the corollaries of each other and that they are both for dinput. I cannot see why one would be for dinput and the other winmm - however, joystick_linuxinput seems to talk with effect_linuxinput and implements force-feedback joysticks for linux.
Is it possible that the winmm code in the winmm dll itself is working for linux but not mac for some reason? Or that the mac side is always trying to use dinput while the linux side can "fall back" on winmm?
Another interesting test case that I noticed has been Freespace 1 from GOG. If you start it up, the game launcher recognizes that a joystick is plugged in, but does not accept commands from that joystick once one is actually playing the game.
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #74 from david.dljunk@gmail.com 2013-02-01 04:55:35 CST --- I think I may have figured out why Linux-wine can communicate with joysticks through a winmm interface, but not OS X. Does the below seem logical?
Looking at the joystick code in dlls/winmm/joystick.c: in order to work it opens up a driver and then uses driver commands for the rest of the code to send commands to the winmm interface.
line 69: static BOOL JOY_LoadDriver(DWORD dwJoyID) { if (dwJoyID >= MAXJOYSTICK) return FALSE; if (JOY_Sticks[dwJoyID].hDriver) return TRUE;
JOY_Sticks[dwJoyID].hDriver = OpenDriverA("winejoystick.drv", 0, dwJoyID); return (JOY_Sticks[dwJoyID].hDriver != 0); }
If you look at dlls/winejoystick.drv/joystick.c, the code is Linux only. An OS X version would need to be written. Feasible?
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #75 from david.dljunk@gmail.com 2013-02-06 20:05:26 CST --- Here's a summary of what I've found looking at dinput and winmm:
------------ dinput
1. Linux has two dinput joystick implementations: 1) for regular joysticks, 2) for force-feedback joysticks. The list of items at the end of each program give away which functionalities have been implemented and which haven't. For instance, in joystick_linux.c "JoystickAGenericImpl_Poll" indicates that polling the joystick has been implemented but "IDirectInputDevice2AImpl_GetForceFeedbackState" indicates getting the force feedback information has not. Whereas in joystick_linuxinput, instead of "IDirectInputDevice2AImpl_GetForceFeedbackState" it has "JoystickAImpl_GetForceFeedbackState". OS X does not have force-feedback joystick code implemented.
2. Interestingly joystick_osx.c does not have the acquire or release functions implemented while both linux.c and linux_input.c do ("JoystickLinuxAImpl_Acquire","JoystickLinuxAImpl_Unacquire"). In keeping with this the Linux programs have the purely internal functions IDirectInputDevice8W_from_impl (and 8A) used in the acquire function implemented in Linux joystick files but not OS X. I've not experienced any bugs or problems so far in dinput games using wine-OS X, though I see bug reports and patches associated with the acquire/unacquire functions on the Linux side. Is there something about the OS X implementation that doesn't need this, or are we missing some dinput functionality that I'm simply not aware of on the OS X side?
As an aside: what's the difference between AINSII type A and UNICODE type W devices and why do some functions need to be written for each but others don't? I assume it is the type of messages being sent and received. Are they all joysticks or do gamepads use one and joysticks the other?
------------ winmm
winmm is looks easier to understand and shorter than dinput. :) I think I have a basic grip of the functions. Within the winmm folder, we have joystick.c. It seems some winmm functions were not truly implemented like ConfigChanged, but otherwise everything seems there. I'm not sure if the "messages" were implemented (http://msdn.microsoft.com/en-us/library/dd743594(v=vs.85).aspx) as I don't see any reference to them but also not sure if that's actually important as even possible as we have to communicate through the Linux/OS X layer anyway and they seem very limited in their functionality/age.
1. As aforementioned it calls a Linux-only driver named "winejoystick.drv".
static BOOL JOY_LoadDriver(DWORD dwJoyID) { if (dwJoyID >= MAXJOYSTICK) return FALSE; if (JOY_Sticks[dwJoyID].hDriver) return TRUE;
JOY_Sticks[dwJoyID].hDriver = OpenDriverA("winejoystick.drv", 0, dwJoyID); return (JOY_Sticks[dwJoyID].hDriver != 0); }
should probably be changed to:
static BOOL JOY_LoadDriver(DWORD dwJoyID) { if (dwJoyID >= MAXJOYSTICK) return FALSE; if (JOY_Sticks[dwJoyID].hDriver) return TRUE;
#if defined(HAVE_IOKIT_HID_IOHIDLIB_H) JOY_Sticks[dwJoyID].hDriver = OpenDriverA("wine_osxjoystick.drv", 0, dwJoyID); #else JOY_Sticks[dwJoyID].hDriver = OpenDriverA("wine_linuxjoystick.drv", 0, dwJoyID); #endif return (JOY_Sticks[dwJoyID].hDriver != 0); }
check if have the OSX type interface, then load the OS X driver, if not load the linux one (with the consequent change in the name of the current linux driver).
2. I noticed in the the current linux driver code (and winmm.c) reference to changes the authors wanted to make. Some I think were made (inclusion of new Linux 2.2 APIs), but others talk about folding all the joystick code in with the rest of the Winmm code and making the joystick driver part of the lolvl driver code. This was never done and exists outside the scope of my knowledge base. So I'm dealing with this as though the plan is to create a mac version of the linux driver that currently exists.
3. In winejoystick.drv, there is "joystick.c", the functions and structs are as follows:
- tagWINE_JSTCK (needs some modification for OS X)
- JSTCK_drvGet (I think no changes needed)
- JSTCK_drvOpen (I think no changes needed)
- JSTCK_drvClose (needs to be changed for OS X, close the OS X device manager)
- JSTCK_OpenDevice (can be folded into JSTCK_GetDevCaps or rewritten, find the requested OS X joystick/gamepad)
- JSTCK_GetDevCaps (needs to find the requested joystick/gamepad and return its properties - number of axes, buttons, etc ... - to lpCaps)
- JSTCK_GetPosEx (needs to be written for OS X, get the current state of all buttons, axes, etc ... of the requested device and return that information to lpInfo)
- JSTCK_GetPos (no changes needed, simply calls JSTCK_GetPosEx)
- JSTCK_DriverProc (no changes needed, simply calls the above functions)
------------
Anyway that's the summary so far of everything I think I know. :)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #76 from david.dljunk@gmail.com 2013-02-07 06:09:04 CST --- (In reply to comment #75)
I'm not sure if the "messages" were implemented (http://msdn.microsoft.com/en-us/library/dd743594(v=vs.85).aspx) as I don't see any reference to them but also not sure if that's actually important as even possible as we have to communicate through the Linux/OS X layer anyway and they seem very limited in their functionality/age.
Never mind about this, they are there in mmsystem.h, I was just blind :)
http://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #77 from david.dljunk@gmail.com 2013-02-09 05:06:21 CST --- So I think I've reached the limit of my usefulness for now. The commands to find and access joysticks in OS X through IOKit seem completely arcane to me. I've attempted to study not only the OS X dinput joystick implementation, but also Apple's developer pages describing IOKit and the HID library and there seems to be a lot of ancillary material I would also have to become comfortable with in order to program a winmm joystick interface myself. Hopefully what I've written above in Comment 75 will be useful as a guide to what needs to be done, but the actual writing of the winmm driver code is at the moment too far outside the scope of my skill set.
If anybody reading this bug report has the necessary knowledge and would like to contribute their time to writing code, I would be very much obliged and happy to help test it.
Thanks for reading!
http://bugs.winehq.org/show_bug.cgi?id=18424
PatrickM patrick_maloney@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |patrick_maloney@hotmail.com
--- Comment #78 from PatrickM patrick_maloney@hotmail.com 2013-08-25 19:49:30 CDT --- 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
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 =)..
https://bugs.winehq.org/show_bug.cgi?id=18424
Henrik Haftmann heha@hrz.tu-chemnitz.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |heha@hrz.tu-chemnitz.de
--- Comment #80 from Henrik Haftmann heha@hrz.tu-chemnitz.de --- I can confirm that joyGetPosEx doesn't return postion values but always zero.
I have an uncommon USB "joystick" here with one button and one axis. http://www.tu-chemnitz.de/~heha/pc/FunkUsb/#2
Its single button reports radio signal attenuation, and the single axis reports a rolling 16-bit event timestamp (range -32768 .. +32767), in milliseconds.
While jstest works but shows degraded values (due to some default calibration which is yet of another concern), winmm:joxGetPosEx() returns always zero for the axis. However, the button event works fine.
My test software is: http://www.tu-chemnitz.de/~heha/hs/Funkuhr.zip
(It works fine when timestamping from X-axis is switched off.) Source code is included.
https://bugs.winehq.org/show_bug.cgi?id=18424
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #81 from Ken Thomases ken@codeweavers.com --- I have just submitted patches to add support for OS X to the WinMM joystick driver:
http://source.winehq.org/patches/data/109979 http://source.winehq.org/patches/data/109980
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #82 from Ken Thomases ken@codeweavers.com --- My patches have been accepted:
http://source.winehq.org/git/wine.git/?a=commit;h=65711634ce97e3e01e7ac70d95...
Please retest, with the latest Wine git, problems which are believed to have resulted from lack of WinMM-style joystick support on OS X.
https://bugs.winehq.org/show_bug.cgi?id=18424
Josh Pettus jshpettus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jshpettus@gmail.com
--- Comment #83 from Josh Pettus jshpettus@gmail.com --- Created attachment 51057 --> https://bugs.winehq.org/attachment.cgi?id=51057 WineLog
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #84 from Josh Pettus jshpettus@gmail.com --- Hi Ken,
Thank-you so much for looking into this. I compiled the master branch on 10.10 an compiled it with clang. I then tried wine with GoG's X-Wing Alliance. The good news is that it looks like the joystick is detected. The bad news is everything crashes. I attached the WineLog I got.
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #85 from Josh Pettus jshpettus@gmail.com --- Comment on attachment 51057 --> https://bugs.winehq.org/attachment.cgi?id=51057 WineLog
Running Master branch with Ken's winmm OSX support patches with X-Wing Alliance
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #86 from Ken Thomases ken@codeweavers.com --- Created attachment 51058 --> https://bugs.winehq.org/attachment.cgi?id=51058 Fix for off-by-one error in Mac joystick code
(In reply to Josh Pettus from comment #84)
Thank-you so much for looking into this.
You're welcome. Thank you for testing.
I compiled the master branch on 10.10 an compiled it with clang. I then tried wine with GoG's X-Wing Alliance. The good news is that it looks like the joystick is detected. The bad news is everything crashes. I attached the WineLog I got.
OK, I think I see the problem. I had an off-by-one error in my code. I'm attaching a patch that should fix it. Please retest. Also, if it's still broken, please collect logs with the +joystick debug logging channel. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #87 from Josh Pettus jshpettus@gmail.com --- Awesome! It WORKS!
XWingAlliance has some other issues I have to work through, but it detected the joystick. Also I tried it with Wing Commander Kilrathi Saga (with some new wcdx patches available on wcnews.com) and worked perfectly!
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #88 from Ken Thomases ken@codeweavers.com --- (In reply to Josh Pettus from comment #87)
Awesome! It WORKS!
XWingAlliance has some other issues I have to work through, but it detected the joystick. Also I tried it with Wing Commander Kilrathi Saga (with some new wcdx patches available on wcnews.com) and worked perfectly!
Glad to hear it. Thanks for testing.
I have submitted the fix: http://source.winehq.org/patches/data/110055
https://bugs.winehq.org/show_bug.cgi?id=18424
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #89 from Ken Thomases ken@codeweavers.com --- The final fix has been committed. And with that, I believe this bug is fixed. This bug has covered too many different (although related) issues (e.g. dinput vs. winmm joystick support). So, I recommend that future problems with joystick support on OS X be filed into separate bugs.
http://source.winehq.org/git/wine.git/?a=commit;h=77432ac45db59440af1aa75e36...
https://bugs.winehq.org/show_bug.cgi?id=18424
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |65711634ce97e3e01e7ac70d953 | |88da5e208f90e
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #90 from Jonas Maebe jonas.bugzilla@gmail.com --- Just wanted to add my thanks!
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #91 from Ken Thomases ken@codeweavers.com --- (In reply to Jonas Maebe from comment #90)
Just wanted to add my thanks!
You're welcome and thank you for your prior work on this issue. And everybody else who worked on the OS X support in dinput, since the new winmm stuff was built largely by copying code from there. ;)
https://bugs.winehq.org/show_bug.cgi?id=18424
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #92 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.39.
https://bugs.winehq.org/show_bug.cgi?id=18424
--- Comment #93 from david.dljunk@gmail.com --- (In reply to Ken Thomases from comment #91)
(In reply to Jonas Maebe from comment #90)
Just wanted to add my thanks!
You're welcome and thank you for your prior work on this issue. And everybody else who worked on the OS X support in dinput, since the new winmm stuff was built largely by copying code from there. ;)
I know this was awhile ago - I just want to say thanks as well! :)
-
wine-bugs＠winehq.org