-----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@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
On Tue, Nov 1, 2011 at 2:11 PM, Alexey Loukianov mooroon2@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@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
* 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@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
-
Alexey Loukianov -
GOUJON Alexandre -
Jerome Leclanche -
Saulius Krasuckas