July 2014 - Wine-devel - list.winehq.org

Re: (Retry)[4/5] imm32: Restrict crossthread Association and destruction
by Marvin 30 Jul '14

30 Jul '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=8186 Your paranoid android. === wvistau64 (32 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed === w2008s64 (32 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed === wvistau64 (64 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed === w2008s64 (64 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed

1 0

Re: (Retry)[6/6]imm32: limit cross thread access to ImmSet* functions
by Aric Stewart 30 Jul '14

30 Jul '14

Sorry this patch is mislabeled as [6/6] it should be [5/5] -aric On 7/30/14, 3:32 PM, Aric Stewart wrote: > Resolves bug 35361 > --- > dlls/imm32/imm.c | 21 +++++++++++++++++++++ > dlls/imm32/tests/imm32.c | 28 ++++++++++++++-------------- > 2 files changed, 35 insertions(+), 14 deletions(-) > > > > >

1 0

Re: shell32: Create profile directories available in Vista and above
by Alexandre Julliard 30 Jul '14

30 Jul '14

Michael Müller <michael(a)fds-team.de> writes: > diff --git a/include/shlobj.h b/include/shlobj.h > index 9025a73..dcea14e 100644 > --- a/include/shlobj.h > +++ b/include/shlobj.h > @@ -1529,6 +1529,15 @@ HRESULT WINAPI SHGetFolderPathW(HWND hwnd, int nFolder, HANDLE hToken, DWORD dwF > #define CSIDL_CDBURN_AREA 0x003b > #define CSIDL_COMPUTERSNEARME 0x003d > #define CSIDL_PROFILES 0x003e > + > +/* Wine internal CSIDLs */ > +#define CSIDL_WINE_CONTACTS 0x0043 > +#define CSIDL_WINE_DOWNLOADS 0x0047 > +#define CSIDL_WINE_LINKS 0x004d > +#define CSIDL_WINE_APPDATA_LOCALLOW 0x004e > +#define CSIDL_WINE_SAVED_GAMES 0x0062 > +#define CSIDL_WINE_SEARCHES 0x0063 This should be private to shell32. Also please avoid the WINE_ prefix, that makes it sound like they are Wine extensions (the defines may not exist on Windows, but the folders do). -- Alexandre Julliard julliard(a)winehq.org

1 0

Confusion with submitting changes
by Kyle Marek 30 Jul '14

30 Jul '14

I am looking at the pages on winehq for development for wine. I am noticing that everything is talking about guidelines for making patches and submitting patches. Can I not make a pull request on my changes? I also noticed that it said that not everyone can submit patches and i inferred by the linked pages that it's to prevent legal trouble. How can I become eligible to submit changes?

3 3

Re: Regarding DXVA support in Wine (DXVA2 -> VA_API)
by Jaeyong Yoo 29 Jul '14

29 Jul '14

Oops sorry, the mail sent while I'm writing... Here goes again: Hello Wine I’ve seen Michael Muller is writing DXVA2 -> VA_API conversion in the following link: http://www.winehq.org/pipermail/wine-devel/2014-March/103687.html I'm wondering the current status of Michael's work. Is there more progress, such as supporting MPEG4 APIs? Best regards, Jaeyong

1 0

Regarding DXVA support in Wine (DXVA2 -> VA_API)
by Jaeyong Yoo 29 Jul '14

29 Jul '14

Hello Wine, I've seen Michael Muller is writing DXVA2 -> VA_API conversion in the following link:

1 0

Re: mshtml: Added IHTMLInputElement_get_form method implementation. (try 2)
by Jacek Caban 29 Jul '14

29 Jul '14

Hi Zhenbo, On 07/29/14 05:24, Zhenbo Li wrote: > + nsres = nsIDOMHTMLInputElement_GetForm(This->nsinput, &nsform); > + if (NS_FAILED(nsres) || nsform == NULL) { > + ERR("GetForm failed: %08x, nsform: %p\n", nsres, nsform); > + p = NULL; Not setting output value would be probably fine in this case, but if you do, please do it right (*p = NULL;). Jacek

1 0

Re: mshtml: Added IHTMLWindow2::navigate implementation.
by Marvin 28 Jul '14

28 Jul '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=8129 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [3/3] wined3d: replace vendor specific callbacks with generic code that uses vendor specific renderer string tables
by Henri Verbeet 28 Jul '14

28 Jul '14

On 26 July 2014 20:24, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > + /*Direct 3D 11*/ I guess this happened while rebasing.

2 1

Re: XInput over SDL
by akjsdfk sdkfnskd 28 Jul '14

28 Jul '14

> My 2c is that this is more of an issue than SDL. Using SDL is probably > fine if there are good arguments that support its use and the > Wine-internal layering makes sure that xinput_*.dll, dinput > and winmm see the same joystick configuration. You could think about > calling SDL from winex11.drv or dinput. I think you missed the point completely here. Example I posted link for is not if you see/can use device or you don't as device is visible full time. Games use this code to decide which interface they use that way to run, DInput or XInput. And since that code does following - enumerate all DInput visible devices (XInput are exposed there too) ---- for each DInput device check if it is XInput ------ for each passed DInput device parse trough all system devices and when you find it (!!!!!) -------- check if device ID contains "IG_", if it does lets proclaim this XInput compatible now if any of devices was XInput compatible LoadLibrary ("XInput1_3.dll") and use XInput API, if there was no compatible device then LoadLibrary ("DInput.dll") and use DInput API. This all happens in game, not in Windows or Wine. In wine case, NO compatible device is reported (!!!!!) - This part is where my question was aiming for, which part of wine creates devices here, so I wouldn't need to hack CoSetProxyBlanket This part has nothing to do with DInput or XInput. Wine simply doesn't provide XInput compatible device when game parses them with CoSetProxyBlanket setup enumeration Maybe you missed it before "*If you want your game to support legacy DirectInput <http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).a…>** devices, you may use DirectInput and XInput side by side. When enumerating your DirectInput devices, all DirectInput devices will enumerate correctly. All XInput devices will show up as both XInput and DirectInput devices, but they should not be handled through DirectInput. You will need to determine which of your DirectInput devices are legacy devices, and which are XInput devices, and remove them from the enumeration of DirectInput devices.*" >From same page > I guess here you mean the X input extension rather than Microsoft's > xinput_*.dll, right? I guess XInput works better in remote X11 > situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I > don't really know how SDL talks to the joystick.) No, I meant exactly what I said. XInput is terribly deficient API. And as far as remote situations, X11 has way too terrible remote display to be usable for game in 50x50 resolution, way off some normal @Vincent Povirk > From what I could tell, SDL has a game controller api that's very > similar to xinput, which is pretty nice, and it can be configured to > map to any controller. It goes further, you can access same device as Joystick and handle axis and buttons manually or you can access it as Gamepad and have instant correct axis/button mapping. Not to mention haptic in XInput is downright terribly deficient (set left/right, ok it works), SDL is downright brilliant on haptic handling Since I'm not native english speaker, some parts might sound like I would try to persuade in use of SDL. If it does, I sincerely apologize and believe me... I don't, I'm honestly only interested in my question regarding who/where creates devices in CoSetProxyBlanket part p.s. sorry for double message Stefan, accidentally only sent response to you and not to list with regards wh1sper_123 On 28 July 2014 20:43, akjsdfk sdkfnskd <wh1sper.123.wtfit(a)gmail.com> wrote: > > My 2c is that this is more of an issue than SDL. Using SDL is probably > > fine if there are good arguments that support its use and the > > Wine-internal layering makes sure that xinput_*.dll, dinput > > and winmm see the same joystick configuration. You could think about > > calling SDL from winex11.drv or dinput. > > I think you missed the point completely here. > > Example I posted link for is not if you see/can use device or you don't as > device is visible full time. Games use this code to decide which interface > they use that way to run, DInput or XInput. And since that code does > following > - enumerate all DInput visible devices (XInput are exposed there too) > ---- for each DInput device check if it is XInput > ------ for each passed DInput device parse trough all system devices and > when you find it (!!!!!) > -------- check if device ID contains "IG_", if it does lets proclaim this > XInput compatible > > now if any of devices was XInput compatible LoadLibrary ("XInput1_3.dll") > and use XInput API, if there was no compatible device then LoadLibrary > ("DInput.dll") and use DInput API. This all happens in game, not in Windows > or Wine. In wine case, NO compatible device is reported > > (!!!!!) - This part is where my question was aiming for, which part of > wine creates devices here, so I wouldn't need to hack CoSetProxyBlanket > > This part has nothing to do with DInput or XInput. Wine simply doesn't > provide XInput compatible device when game parses them with CoSetProxyBlanket > setup enumeration > > Maybe you missed it before "*If you want your game to support > legacy DirectInput > <http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).a…>** devices, > you may use DirectInput and XInput side by side. When enumerating your > DirectInput devices, all DirectInput devices will enumerate correctly. All > XInput devices will show up as both XInput and DirectInput devices, but > they should not be handled through DirectInput. You will need to determine > which of your DirectInput devices are legacy devices, and which are XInput > devices, and remove them from the enumeration of DirectInput devices.*" > From same page > > > I guess here you mean the X input extension rather than Microsoft's > > xinput_*.dll, right? I guess XInput works better in remote X11 > > situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I > > don't really know how SDL talks to the joystick.) > > No, I meant exactly what I said. XInput is terribly deficient API. And as > far as remote situations, X11 has way too terrible remote display to be > usable for game in 50x50 resolution, way off some normal > @Vincent Povirk > > From what I could tell, SDL has a game controller api that's very > > similar to xinput, which is pretty nice, and it can be configured to > > map to any controller. > > It goes further, you can access same device as Joystick and handle axis > and buttons manually or you can access it as Gamepad and have instant > correct axis/button mapping. Not to mention haptic in XInput is downright > terribly deficient (set left/right, ok it works), SDL is downright > brilliant on haptic handling > > > Since I'm not native english speaker, some parts might sound like I would > try to persuade in use of SDL. If it does, I sincerely apologize and > believe me... I don't, I'm honestly only interested in my question > regarding who/where creates devices in CoSetProxyBlanket part > > with regards > wh1sper_123 > > > On 28 July 2014 19:50, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2014-07-26 22:52, schrieb akjsdfk sdkfnskd: >> > - hotplugging/unplugging (well, only if game didn't use DInput to >> > scan new devices. if it is pure XInput, then it just works) >> My 2c is that this is more of an issue than SDL. Using SDL is probably >> fine if there are good arguments that support its use and the >> Wine-internal layering makes sure that xinput_*.dll, dinput >> and winmm see the same joystick configuration. You could think about >> calling SDL from winex11.drv or dinput. >> >> > - far better API than XInput >> I guess here you mean the X input extension rather than Microsoft's >> xinput_*.dll, right? I guess XInput works better in remote X11 >> situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I >> don't really know how SDL talks to the joystick.) >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJT1o1zAAoJEN0/YqbEcdMwWiYP/1/hOzt/v6VIp+gDS+cYJF5u >> 4fRyjT4zoWoFmOUrtApSj1VaBA2DeIaeeT97D0AAvD+FQ0GLaSYcEbn2EqLTcPJO >> N2IGHeTABdt3IBcD1Ya4AOVAryITaqoR83qmI6KElv/jrdpNDD6BaMemcFDno4Tm >> pqAYdlZBlFUWP5kEcSp7OsztNWCin0gdQ6BRRnU8nhtBtlOC5qV9VQPW5CQ66SDK >> +CM+3YkzARMoqmPk1qNu/OnkrubRRuwpHLsCySkfE9WnIDd29tIEAvMThUeZ8ucN >> OKmdIhs+RSOijrZecj0QDzhNA3fPR+EYx+OFr6h10Y3PxOgdwwAstDoakEhk1x4Y >> /jQu0XKtP6hDqCtSruxE8Ny3Hpb8p/zsdodHIhmp1W99QdHLbnKVdZJiCYBLToFW >> AVJ69NPm4Ae92jerN8pesHEl5B7kIGkQepCCpxWUjwPVWEjbB6fEcegGcGN/ccNn >> EWiBm1+14L5wgPSPCG/DhAfEPtfsig7TLdsL6zIZFLq0/+O6PVmjW9ezjT1PD00U >> NP7VqmYWY5Is7XtWI6NQ1Vqi5En47uKz+ZaQLPB0ExQB57XrubMo6C6aE53Q4HRg >> 5Kmh7vTBZecXPZGToT6Eg3z3y1Bc6B9piipxxfRzuqOU6EUzqHO8RzG/LuMrOLG7 >> kHdS1Q1gRro1FRAFDT3M >> =gcqc >> -----END PGP SIGNATURE----- >> > >

1 0