If you have ever looked at playing games on Linux through WINE, you are probably aware by now that there’s a bunch of hacks involved to getting a Xbox360 pad to work with games. Usually this means grabbing an older version of the little Windows tool called xbox360ce.exe, a few xinput dlls, and a xbox360 configuration file and dump that unholy mix into the Windows’ game’s folder, and pray that everything works as expected. It’s just like witchcraft, except that you won’t be burned for that anymore these days. Honestly, this situation is far from being satisfying. I know we all want clean ports for Linux anyway, but there’s always going to be a ton of games that will never get ported, and WINE can be a good solution for those. The less hackery tricks it needs to support controllers, the better.
The good news is that this may change in the near future. I have been in touch with Aric, one of the Codeweavers developers (official devs for the WINE/Crossover project) who has been working to have proper xinput support in WINE.
This is what he could share with me about the current status of things:
Aric: Right now WINE’s xinput support is very skeletal at best. There is the framework for future progress but, as present, it is not functioning at all. That is why tools like xbox360ce.exe are recommended to try to allow xinput games to be able to see controllers through dinput. Xbox controllers themselves should work in dinput games. It is just games that require xinput that have this complexity.
Right now I am doing active work on implementing ground level HID support for controllers, the hope is that by implementing HID, that will provide a nice uniform base for a clean implementation of xinput in the near future. There are a few other implementations of xinput that have proposed in the wine-devel mailing list or are available on the internet, but none have been accepted into WINE at this stage.
If you ever check github, you may encounter tools like koku-xinput-wine (https://github.com/KoKuToru/
Aric: As far as I know none of those implementation have been submitted to the wine patch process, and if they have been then the developers did not go through the process of fixing up and readying the patches for wine inclusion. Admittedly that process can be very time consuming and often difficult as there is a very high bar to reach to get code included in WINE. Often developers get frustrated with the process and simple publish their own WINE branch, but that means the code never gets into the main WINE project.
Of course what matters in the end to us gamers is WHEN we actually get a working solution. It looks like it’s not too far away, and that it’s been already worked on for a long time:
Aric: Right now the process of getting raw HID support in wine has been more than an 18 month process and there is still a fair bit more to get included. I am hoping that we can have this foundation in place this calendar year. However then the xinput work needs to be done on top of this. I would expect 2017 is much more likely, but it is very hard to predict anything timeline wise with WINE development. But there is a visible path forward which is nice!
In the meantime, you can keep relying on xbox360ce as it’s apparently the safest bet. For games that allow remapping of controls, using a Steam Controller with custom configuration can also yield pretty decent results if you map it to emulate a keyboard but it’s not ideal for games that are only planned with a gamepad in mind.
If you want to learn more about what WINE/Crossover developers do, I’d recommend you check our earlier articles on the subject as well as our recent podcast with James Ramey, the president of Codeweavers. You can also support their efforts by getting a Crossover license (and you can always download a demo of Crossover to test it first).
At BoilingSteam, we strongly dislike ads and that is why you won't find any during your visit. If you like what we do, please consider supporting us on Patreon. You can also sign up to our newsletter (No Spam!), or our RSS feed or even Twitter.