November 2011 - Wine-Devel - list.winehq.org

Re: MS XInput*.dll implementation

by Alexey Loukianov

-----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-----

Nov. 1, 2011

Re: [PATCH] mmdevapi: Print a winediag message for the registry driver value

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > @@ -126,6 +127,8 @@ static BOOL init_driver(void) > > if(RegQueryValueExW(key, drv_value, 0, NULL, (BYTE*)reg_list, > &size) == ERROR_SUCCESS){ > + TRACE_(winediag)("MMDevAPI driver registry value: %s\n", > + wine_dbgstr_w(reg_list)); I'm not sure that's very useful, winediag messages are supposed to be ERRs. If people having an old broken registry key is really a problem, then we should use a different key, or maybe simply get rid of it and do it through dll overrides or something like that. -- Alexandre Julliard julliard(a)winehq.org

Nov. 1, 2011

Re: MS XInput*.dll implementation

by Austin English

Nov. 1, 2011

Re: MS XInput*.dll implementation

by GOUJON Alexandre

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.

Nov. 1, 2011

Re: MS XInput*.dll implementation

by Jerome Leclanche

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

Nov. 1, 2011

Re: MS XInput*.dll implementation

by Alexey Loukianov

-----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-----

Nov. 1, 2011

re: MS XInput*.dll implementation

by Dan Kegel

Hi, I doubt anyone's working on it (would like to be wrong about that). Things to keep in mind: - contributing test cases is good - looking at Microsoft code, even watching traces with Process Monitor, is bad and can get your code rejected - so contributing test cases is very good. blackbox testing, illuminated by msdn or other doc, is the way to establish the real spec. - pointing to a freely downloadable real game that benefits from a patch is helpful - quick and dirty prototype that kind of works would gather some interest - but to get real code in, do it in small useful chunks, each with a test if possible - See of course http://wiki.winehq.org/SubmittingPatches - Generally pay more attention to people with more patches in, git shortlog -s -n --since="(1year)" origin and of course to people who have contributed input code. I'm just an interested bystander at this point. Good luck! - Dan

Nov. 1, 2011

MS XInput*.dll implementation

by Alexey Loukianov

-----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(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/ iQEcBAEBAgAGBQJOr6QoAAoJEPB9BOdTkBULPA4H/1G4IowO2DGXZPX2728Pb/sV Lx+TisQ2fODW4gzCdCKLdh6CuLkaQCwCRbQ4zqrV6ksW3yLtpYHJ7z2I/kHL2RYX wzXBEU5mYY2b/WVPuL9LETCxMA/fZGBN/2RkSAWpjwpNzLwaGD10KUwyXa6rSFkh eAigINhgSkEX+uHV3ZdKvnuXLrluZQsSwZtudMvxiMfBf8mxBuZtgXyIIaWxTF5z Vo4YKn+QFtUi6CwQA8vPYtm4617TPs8cwTr0p1lOigT3gFqgYQGgDiUK7KZGyDlD YhgwezwUAIgDQAEpUMvXtB5j4fAfqyrXtrQzwoCgzBan4Yf7B5FLKxP0RtWrrL4= =d+Dp -----END PGP SIGNATURE-----

Nov. 1, 2011

Re: [3/4] d3d9/tests: Test partial block locks

by Stefan Dösinger

On Monday 31 October 2011 21:10:41 Henri Verbeet wrote: > On 31 October 2011 20:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > + case D3DPOOL_SCRATCH: > > + case D3DPOOL_SYSTEMMEM: > > + hr = > > IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, > > formats[i].fmt, + D3DPOOL_SCRATCH, &surface, > > 0); > > That doesn't really test D3DPOOL_SYSTEMMEM. That was a pretty simple change, but when I re-ran the tests on Windows to be sure they work the ATI2N test failed. On Nvidia drivers ATI2N has 4x4 blocks, which makes sense, but if you violate that the driver returns E_INVALIDARG instead of D3DERR_INVALIDCALL. Oh well. On AMD, ATI2N has 2x2 blocks, which doesn't make sense to me. When I ran the tests on Windows the last time the 1x1 "blocks" locked fine. I couldn't reproduce that even with the last version of my patch. I've changed the test and implementation according to those results, but before I resubmit them I'll test a few more Windows machines(especially dx9 and xp based ones). What's changed: *) block_size removed, this was unused *) Improved messages, print the pool *) Use block_dimensions / 2 instead of block_dimensions - 1 to construct invalid blocks. *) Adjusted test to 2x2 / 4x4 ATI2N block sizes

Nov. 1, 2011