MS XInput*.dll implementation
mooroon2 at mail.ru
Tue Nov 1 02:47:52 CDT 2011
-----BEGIN PGP SIGNED MESSAGE-----
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 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.
Alexey Loukianov mailto:mooroon2 at mail.ru
System Engineer, Mob.:+7(926)218-1320
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the wine-devel