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

Re: mshtml: call FindMimeFromData with a NULL buffer in ResProtocol_Start
by Paul Chitescu Nov. 2, 2011

Nov. 2, 2011

On Wednesday 02 November 2011 07:19:02 am Austin English wrote: > Fixes http://bugs.winehq.org/show_bug.cgi?id=27115, a regression > introduced by 0825f4b3ff3718752b5f6addd95bc30c10f75d24. Instead of not passing actual read data please fix FindMimeFromData. Reverting the patch will break many programs that store images (GIF, PNG) in resources with non-descriptive names.

1 0

MS XInput*.dll implementation
by Alexey Loukianov Nov. 2, 2011

Nov. 2, 2011

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

3 4

Re: MS XInput*.dll implementation
by Alexey Loukianov Nov. 1, 2011

Nov. 1, 2011

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

4 5

Re: [PATCH] mmdevapi: Print a winediag message for the registry driver value
by Alexandre Julliard Nov. 1, 2011

Nov. 1, 2011

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

1 0

re: MS XInput*.dll implementation
by Dan Kegel Nov. 1, 2011

Nov. 1, 2011

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

1 0

Re: [3/4] d3d9/tests: Test partial block locks
by Henri Verbeet Oct. 31, 2011

Oct. 31, 2011

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.

2 1