-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Good day to all,
I've got a general question about the Windows subsystem I'm a bit interested of and considering spending some time trying to implement it. What I'm talking about is "new" input handling API MS positions as the DirectInput successor: XInput 1.x. Looks like currently Wine includes general stubs for older version of XInput dlls ("legacy stipped down" XInput9_1_0, and later versions ranging from 1.1 up to 1.3; XInput 1.4 which is documented to be the core component of upcoming Windows 8 isn't implemented yet). Stubs are pretty much what they are: general placeholders so APPs would be able to link to these DLLs and get semi-correct return codes from procs.
What I'm interested in (and that's is the reason I'm posting to devlist) is what are the plans on real implementation of MS XInput API? Are there anybody working on topic? Were there any preliminary patches floating around aimed at implementing this API in Wine?
I'm asking this question because I had recently tried to use force-feedback capable gamepad by Thrustmaster under Wine and found it to be working pretty well through DirectInput[8] API, but not being accessible through XInput API and thus failing to properly work with force-feedback enabled applications. Reading the docs on MSDN made me believe that force-feedback on GamePads can't be properly handled through DirectInput API - it was MS design decision to deprecate DI in favor of XInput and no to extend DI effects support with "rumble" effect. Thus to get proper behavior for GamePads force-feedback under Wine it is required to implement XInput API.
General investigation on topic shows that this isn't as easy as it might seem at a first glance. Just looking at code sniplet by MS that accomplishes task of filtering out XInput-capable devices from DirectInput enumerated device list shows that MS is just the old-bad MS: relying on third-party low-level system API (WMI) to enumerate all the available PnP devices of a certain class and then filter them out based on VID/PID and a part of PNPID substring isn't a good programming practice IMO. In any case it is a thing that should be somehow dealt with in Wine since current and future games might be already using this technique and are certainly using both DirectInput and XInput to handle various types of "game input devices".
That being said, and in case there no one out there is working on the topic, what considerations should I stick with if I would proceed with trying to implement XInput API in Wine? Thanks in advance for answers and insights.
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
On Tue, Nov 1, 2011 at 00:47, Alexey Loukianov mooroon2@mail.ru wrote:
What I'm interested in (and that's is the reason I'm posting to devlist) is what are the plans on real implementation of MS XInput API? Are there anybody working on topic? Were there any preliminary patches floating around aimed at implementing this API in Wine?
Some patches: http://www.winehq.org/pipermail/wine-patches/2008-October/063787.html
http://www.winehq.org/pipermail/wine-patches/2008-October/063799.html http://www.winehq.org/pipermail/wine-patches/2008-October/063800.html http://www.winehq.org/pipermail/wine-patches/2008-October/063801.html http://www.winehq.org/pipermail/wine-patches/2008-October/063802.html
http://www.winehq.org/pipermail/wine-patches/2008-October/064046.html http://www.winehq.org/pipermail/wine-patches/2008-October/064047.html http://www.winehq.org/pipermail/wine-patches/2008-October/064048.html http://www.winehq.org/pipermail/wine-patches/2008-October/064049.html
And discussions:
http://www.winehq.org/pipermail/wine-devel/2008-October/070145.html
http://www.winehq.org/pipermail/wine-devel/2010-June/084349.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
01.11.2011 21:12, Austin English wrote:
Some patches: ...
And discussions: ...
Austin, thanks for posting these links. I've seen patches by Andrew posted in October, 2008 and the initial discussion that followed those postings to the list when been doing my own search on the topic. These patches seemed to be a little "hairy" to my personal taste and they need re-basing to the current Wine codebase. On the other hand it wouldn't be too hard as XInput isn't a very complicated API per se.
What I had missed when been doing the search on topic is a discussion from June, 2010 started by Roderick Colenbrander. IMHO the most interesting part from that discussion are comments from Alexandre Julliard stating that input handling should be done through X11.
X11 in general and XI2 in particular don't provide an easy way to detect if some picked XI2 device is a mouse, a keyboard or a "game input device". Input devices effects like "rumble/vibro" or "force feedback" are also unsupported in the current XI2 implementation. XInput core protocol is defined in a way that it's possible to extend it with required features. It is an enhancement request that should be reported to Xorg team, exactly as Alexandre stated in another message from that discussion thread.
I had done a quick search through Xorg bugzilla and was unable to find any bug/ench. reports targeted at adding aforementioned features to the XI2/Xserver, so I had filled a new bug report that is available here: https://bugs.freedesktop.org/show_bug.cgi?id=42489
Getting back on topic, even if required bits of functionality would finally land into Xorg/XI2, it wouldn't happen in a near future. On the other hand having gamepads working with XInput-capable apps under Wine without (or with minimal amount of) any special measures would be a cool feature that end-users would like to have "right now" (I'm is an example of such "end-user" despite being advanced enough to compile and get X360ce XInput-to-DI8 wrapper working under Wine with my gamepad).
I would like to revive the discussion about the way XInput API might be implemented in Wine "for now", so users would be able to use their gamepads under Wine during the long wait until required bits of functionality would finally land into X11/Xorg/XI2 (in case it would ever happen at all).
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
I've got a general question about the Windows subsystem I'm a bit interested of and considering spending some time trying to implement it. What I'm talking about is "new" input handling API MS positions as the DirectInput successor: XInput 1.x.
If you really want it to get in just do it via DI. Use old patches and projects like x360ce for ideas, code, and documentation. Too bad x360ce is in c#.
Implementing XInput "properly" via X11 is impossible. X11 does not support force-feedback joysticks. One can wait for another 5 years for broken interface. And another 5 to get it fixed.
Vitaliy.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
02.11.2011 06:05, Vitaliy Margolen wrote:
If you really want it to get in just do it via DI. Use old patches and projects like x360ce for ideas, code, and documentation. Too bad x360ce is in c#.
x360ce XInput1_3.dll implementation is written in pure C (well, polluted with things like C++ comments and variables declarations in the middle of control block, but anyways). The only part written in C# is GUI which has one purpose: provide the user with a way to edit x360ce.ini file in a human-friendly way.
XInput1_3.dll from x360ce in generally works fine with Wine if you supply it with a correct config for your gamepad. It allows one to use gamepads in some XInput aware programs, I had tested it with success in LIMBO, Rage and Braid. OTOH there are apps that fail to detect XInput devices with it, most likely due to the detection scheme MS recommends to use which involve devices enumeration via WMI. On Windows x360ce uses "hooks" to hijack some DI and WMI procs and support an APP with the data it wants to get in order to detect the presence of Xbox360 gamepad controller. IMO this technique is "a bad way to do a simple thing" and apps that use it are poorly designed (it's not their fault, it's MS who introduced this mess), but in case there would be built-in XInput implementation in Wine - it should be able to handle correctly such cases. I had already mentioned it earlier in one of the messages I sent to list.
As for "just doing via DI": despite I like the concept of implementing XI over DI8 (it would give immediate benefit to the Wine users on all platforms where joysticks are supported via DI), I'm not sure it is a good idea to quickly head on to writing code if the design concepts used are not acceptable from the point of Wine devteam. Coding "just for fun" was fun when I was fifteen and had a lot of free spare time. It is still fun nowdays, but the amount of time available to spend doing JFF coding became pretty short/limited. Because of that I had decided to write a message to a wine-devel in order to discuss code design concepts that are acceptable for XInput implementation to be included in Wine codebase prior to launching Eclipse and starting to code.
Implementing XInput "properly" via X11 is impossible. X11 does not support force-feedback joysticks. One can wait for another 5 years for broken interface. And another 5 to get it fixed.
Exactly. I totally agree with it and had already mentioned in one of my prior messages that it would be handy to have somewhat working XInput implementation in Wine while waiting for X11 to be fixed which isn't guaranteed to happen at all. Knowing that we might face something like Wayland to become popular and widely installed display server in about 5 years also doesn't add up to the "use X11" concept.
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
-
Alexey Loukianov -
Austin English -
Vitaliy Margolen