Re: MS XInput*.dll implementation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 01.11.2011 11:58, Dan Kegel wrote:
Hi, I doubt anyone's working on it (would like to be wrong about that). Things to keep in mind: ...
Dan, thanks for a quick answer on topic. Besides these general and very valuable keypoints there are some other things that should be clarified (or at least discussed) before proceeding with writing code. Most important things to talk about that I can think of at a first glance: a) Obtaining specs. Black-box testing is always a good thing (had learned it with pain when been studying how to write programs for the Window 3.x). What I've got available to do the tests are three Windows-based PCs, each running different version of OS, namely W2k Prof, WXP Home and Win7 Starter. XP and Seven are surely a good targets for XInput black-box testing and implementing test cases. Not sure for W2k, would need to investigate further. Things getting worse when it comes to hardware: the only "game input device" I have on hand is the aforementioned gamepad by Thrustmaster. MSDN XInput docs state that XInput was primarily targeted at supporting Xbox360 gamepads, and it looks like that there are a bunch of different subtypes of these devices out there in the wild. At the best case I only would be able to investigate XI behavior for most generic XINPUT_DEVSUBTYPE_GAMEPAD type which my gamepad most closely corresponds to. Would try to ask my friends in case they've got some controllers that fit into other XINPUT_DEVSUBTYPE_* categories. b) I'm pretty limited with Linux-only as a host system for Wine. Thus it would be impossible for me to write the code that supports FreeBSD and/or Mac OS X. c) Separate challenge would be to detect the correct XINPUT_DEVSUBTYPE for game input controller under linux. As far as I understand event-driven linux input API correctly, it doesn't have any means of distinction between different game controllers types. What is possible though is to detect VID/PID, the product brand-name and the number of axis and buttons. It makes possible to implement some kind of "device database" and determine the correct XINPUT_DEVSUBTYPE basing on the info from this database, but I don't think it would be the most clear and maintainable solution ever (database should be maintained, populated with new HW defs, e.t.c). d) Code duplication issues. XInput API mirrors DirectInput API at some part and it might be reasonable to re-use code parts from the existing DirectInput linux event-based joystick driver. I am thinking about implementing XInput on top of DirectInput + extending existing DI linux event-based joystick driver COM API with Wine-specific extensions (this is required to add support for "rumble" FF effect). There are Windows drivers out there that work in exactly this way (XBCD in a good example offering drop-in XInput wrapper dll that maps to the DI calls). e) List of games that might benefit from XInput support is pretty big, one may wish to take a look onto this Wiki page for examples: http://en.wikipedia.org/wiki/List_of_XInput_enabled_games Chances are some titles out there are free and open source but investigation is needed to name exact titles. I own some of the commercial titles from that list (for ex. Braid, Borderlands, DiRT, DiRT 2. Fallout 3, Fuel, L4D, L4D2, LIMBO, Grid, RAGE, The Witcher 2, titles from The Orande Box, Portal 2, UT3) so it would be possible for me to test the XInput implementation on the broad range of native apps. Still I would try to search for free (and maybe OSS) Win32 game that might be used by anybody as the "example testcase". - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOr/4kAAoJEPB9BOdTkBULM+QIAKyG73I7BpcWvSqBRpee9ljF HTEMCRG5mKZymSqi+prTQQnQgYs0rdq/paPTzUlYoCtD4ZsoIaNMYRSQUkQuKLHB aO0JFdEJEa6liiABR05y3xfjYqd7am2tHDfHSTTO2o1TCmphJau5QquaSNCG5Sh1 Xe1eoVc6RWMxzgQqFuGtEPV34B1s2wiFzjosXv9NZWSwwxL0m9bgBvDeJKvNcNnT tsymMur2SkWXh9sgKwW0wJ3MENlSk5BP0z4I649EWCHgTf8lfz6HFj8fwShsl3KD SvmP8woqUXl93g5eEqM18bIVFm/gyRYEzVTZJTize8/E9dZtgUbtWoQv3t/c81s= =8M6g -----END PGP SIGNATURE-----
On Tue, Nov 1, 2011 at 2:11 PM, Alexey Loukianov <mooroon2(a)mail.ru> wrote:
d) Code duplication issues. XInput API mirrors DirectInput API at some part and it might be reasonable to re-use code parts from the existing DirectInput linux event-based joystick driver. I am thinking about implementing XInput on top of DirectInput + extending existing DI linux event-based joystick driver COM API with Wine-specific extensions (this is required to add support for "rumble" FF effect). There are Windows drivers out there that work in exactly this way (XBCD in a good example offering drop-in XInput wrapper dll that maps to the DI calls).
e) List of games that might benefit from XInput support is pretty big, one may wish to take a look onto this Wiki page for examples:
I'm no expert in any *input* API, but it sounds like it would be better to reimplement dinput under the xinput api; similarly to how audio has been handled. JL
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 01.11.2011 18:54, Jerome Leclanche wrote:
I'm no expert in any *input* API, but it sounds like it would be better to reimplement dinput under the xinput api; similarly to how audio has been handled.
Despite being more recent API XInput actually is less capable than DI8. Most correct way to compare these API's would be to think about DI8 as a "general and pretty complicated API for handling input devices" while XInput is more likely "API for handling some Xbox360 game input controllers". You may wish to read Wiki page titled something like "XInput vs. DirectInput" for more detailed analysis. P.S. Resending this message to wine-devel list, forgot to CC. - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOsFLGAAoJEPB9BOdTkBUL5fYH/1rRm0AeWih3NttEw+694FpW xRX0YEZWQdj6P5WAsz1vZmsnR7QYjJorLgYxYEysZg6kLKfgAorOw6WPCeHlaFg6 WJu3HGKHXHNmuz/iv4JL9qMK6JM85dw1y7q1RDvbp4VxjXPX58NI/mKTihMMUrGW 7cjKxCMSUodtCO1hPXuvZDh6aq7gZNbdO6UOVYTqKCoFXayy1UdVlseZSErh+Dpx WADNb7zLI6c/mTGvvPzd/QZlRAUoCNILlxMAto1fUW2QIz+xoHr8rybRnQwuyXhB 7u456vl15EYOioHTXBVUZ3KcOUDjkg4xXYatc8cZdRx317pEqOYU/NYcMZ6QqHc= =vAwS -----END PGP SIGNATURE-----
* On Wed, 2 Nov 2011, Alexey Loukianov wrote:
01.11.2011 18:54, Jerome Leclanche wrote:
I'm no expert in any *input* API, but it sounds like it would be better to reimplement dinput under the xinput api; similarly to how audio has been handled.
Despite being more recent API XInput actually is less capable than DI8. Most correct way to compare these API's would be to think about DI8 as a "general and pretty complicated API for handling input devices" while XInput is more likely "API for handling some Xbox360 game input controllers". You may wish to read Wiki page titled something like "XInput vs. DirectInput" for more detailed analysis.
I am just another bystander as well, but a year ago (as was brought in by Austin E. a few msgs ago) Roderick Colenbrander wrote about a possibility (and arising problems) doing this just a way round: http://www.winehq.org/pipermail/wine-devel/2010-June/084395.html Some other guys (more or less related to input, eg. Vitaliy Margolen, Alexandre Julliard, Marcus Meissner) on the same thread have said XInput can work only when done directly (via X11). S.
On 11/01/2011 03:11 PM, Alexey Loukianov wrote:
a) [...] What I've got available to do the tests are three Windows-based PCs You should have a look at https://testbot.winehq.org/ which let you submit a patch on several (VMware'd) Windows machines. But I doubt there is any input devices in these virtual machines. Can someone confirm/infirm this ? the only "game input device" I have on hand is You can also ask people here (or on IRC) to test your patches if they have the hardware. If you read wine-devel archives, you'll find that, from time to time, some people ask to test a patch for a new Gecko release or to run some tests on (mutli-channel) soundcards in order to better understand how it works. b) I'm pretty limited with Linux-only as a host system for Wine. And so do I and probably most of people here. You know, tests are run every (working) day on several machines : keep an eye on the results and provide meaningful error messages to help you fix your code. (see http://test.winehq.org/data/) Of course, if your code depends on OS-specific features, you can wrap your code with defines. And when you'll submit something, you're code will be reviewed so you'll got some feedback.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 01.11.2011 19:23, GOUJON Alexandre wrote:
On 11/01/2011 03:11 PM, Alexey Loukianov wrote:
a) [...] What I've got available to do the tests are three Windows-based PCs You should have a look at https://testbot.winehq.org/ which let you submit a patch on several (VMware'd) Windows machines. But I doubt there is any input devices in these virtual machines. Can someone confirm/infirm this ? AFAIK currently testbots are only being used to test that "conformance tests" affected by patch pass without FAILs under native OS-es.
b) I'm pretty limited with Linux-only as a host system for Wine. And so do I and probably most of people here.... ... Of course, if your code depends on OS-specific features, you can wrap your code with defines.
That's exactly the case here. Low level input APIs differ significantly between various OS for obvious reasons. If it would be decided to head on and write separate driver for XInput instead of re-using already implemented (and working reasonably well) DI8 infrastructure, then such driver would surely be OS dependent and only enabled for compilation in case configure script would determine that the target OS supports required low level API. P.S. Resending this message to wine-devel list, forgot to CC. - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOsFLwAAoJEPB9BOdTkBULTxkH/3mXSnZ43yysvVikTNdwGklv Mp7KK+JX884KgR015BuIczPZVnx/z9FUhXT4YqUHwOBzjW+gNM6+XOJ9Cg0OCMO6 RX/A5LhE+zYKknP5wUWeB6Jztzgq8sfcZAew+v3ARYn8b7t45Ec98lBmDhaFWFbo bo6i1P5Em2XeipKaArnVOt3t7dpJlyFPFSlVV+tNEnKd2UR+EG8HwszHD2YRKzhj sS5anxPBZIkQ2syaFgWIepUUFRnifbx5Km5qhulIxfJBbOqf5djJ8u1npgFZhoGm bsGJQlPu4TPJguWl42UAdlGFAiW3/UkUP3aiyH8zZ3kPEmLtkNy5mWd8EFnUKZ4= =D5Pk -----END PGP SIGNATURE-----
participants (4)
-
Alexey Loukianov -
GOUJON Alexandre -
Jerome Leclanche -
Saulius Krasuckas