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

Re: [PATCH 6/6] wined3d: Restore the display mode on focus change.

by Henri Verbeet

On 18 November 2014 21:26, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(!EnumDisplaySettingsW(adapter->DeviceName, ENUM_REGISTRY_SETTINGS, &new_mode)) Formatting. > + else if (current_mode.dmPelsWidth == new_mode.dmPelsWidth > + && current_mode.dmPelsHeight == new_mode.dmPelsHeight > + && current_mode.dmBitsPerPel == new_mode.dmBitsPerPel > + && (current_mode.dmDisplayFrequency == new_mode.dmDisplayFrequency > + || !(new_mode.dmFields & DM_DISPLAYFREQUENCY)) > + && (current_mode.u2.dmDisplayFlags == new_mode.u2.dmDisplayFlags > + || new_mode.dmFields & DM_DISPLAYFLAGS)) Shouldn't that be "!(new_mode.dmFields & DM_DISPLAYFLAGS)"? > - struct wined3d_display_mode original_mode; > + struct wined3d_display_mode original_mode, d3d_mode; I might have just gone for "mode", but I don't care strongly.

Nov. 19, 2014

Re: [PATCH 1/2] ole32/tests: Release() doesn't return HRESULT code

by Nikolay Sivov

On 11/19/2014 12:27 PM, Marvin wrote: > 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=10342 > > Your paranoid android. > > > === wvistau64 (32 bit moniker) === > moniker: unhandled exception c0000005 at 00425FC9 > > === w2008s64 (32 bit moniker) === > moniker: unhandled exception c0000005 at 00425FC9 > > === w7u (32 bit moniker) === > moniker: unhandled exception c0000005 at 00425FC9 > > === w8 (32 bit moniker) === > moniker: unhandled exception c0000005 at 00425FC9 > > === wvistau64 (64 bit moniker) === > moniker: unhandled exception c0000005 at 00000000004209EA > > === w2008s64 (64 bit moniker) === > moniker: unhandled exception c0000005 at 00000000004209EA > I don't see how this patch could crash it like that, it doesn't change test sequence at all. Also works just fine on Win8.1 VM.

Nov. 19, 2014

Re: [PATCH 1/2] ole32/tests: Release() doesn't return HRESULT code

by Marvin

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=10342 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004209EA === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004209EA

Nov. 19, 2014

Re: ole32: Simplify a function by removing no-op code (PVS-Studio).

by Michael Stefaniuc

On 11/19/2014 09:51 AM, Sebastian Lackner wrote: > On 19.11.2014 09:26, Michael Stefaniuc wrote: >> MSHLFLAGS_NORMAL is 0. >> --- >> dlls/ole32/stubmanager.c | 19 +------------------ >> 1 file changed, 1 insertion(+), 18 deletions(-) >> >> diff --git a/dlls/ole32/stubmanager.c b/dlls/ole32/stubmanager.c >> index 96d710d..1aca924 100644 >> --- a/dlls/ole32/stubmanager.c >> +++ b/dlls/ole32/stubmanager.c >> @@ -536,7 +536,6 @@ HRESULT ipid_get_dispatch_params(const IPID *ipid, APARTMENT **stub_apt, > > Although logically correct, I am not sure if this is what it should look like. > > In ole32/marshal for example there is also: > > --- snip --- > if (flags & MSHLFLAGS_TABLEWEAK) > TRACE(" MSHLFLAGS_TABLEWEAK"); > if (!(flags & (MSHLFLAGS_TABLESTRONG|MSHLFLAGS_TABLEWEAK))) > TRACE(" MSHLFLAGS_NORMAL"); > if (flags & MSHLFLAGS_NOPING) > TRACE(" MSHLFLAGS_NOPING"); > --- snip --- > > This could probably mean that fixing the if condition is a more correct solution, but I don't know that part well enough. Maybe, maybe not. The code is 9-10 years old, if it wasn't a problem until now then going with the "obviously correct" logical transformation is the safer bet to not get the patch into Pending. bye michael

Nov. 19, 2014

Re: ole32: Simplify a function by removing no-op code (PVS-Studio).

by Sebastian Lackner

On 19.11.2014 09:26, Michael Stefaniuc wrote: > MSHLFLAGS_NORMAL is 0. > --- > dlls/ole32/stubmanager.c | 19 +------------------ > 1 file changed, 1 insertion(+), 18 deletions(-) > > diff --git a/dlls/ole32/stubmanager.c b/dlls/ole32/stubmanager.c > index 96d710d..1aca924 100644 > --- a/dlls/ole32/stubmanager.c > +++ b/dlls/ole32/stubmanager.c > @@ -536,7 +536,6 @@ HRESULT ipid_get_dispatch_params(const IPID *ipid, APARTMENT **stub_apt, > /* returns TRUE if it is possible to unmarshal, FALSE otherwise. */ > BOOL stub_manager_notify_unmarshal(struct stub_manager *m, const IPID *ipid) > { > - BOOL ret = TRUE; > struct ifstub *ifstub; > > if (!(ifstub = stub_manager_ipid_to_ifstub(m, ipid))) > @@ -545,23 +544,7 @@ BOOL stub_manager_notify_unmarshal(struct stub_manager *m, const IPID *ipid) > return FALSE; > } > > - EnterCriticalSection(&m->lock); > - > - /* track normal marshals so we can enforce rules whilst in-process */ > - if (ifstub->flags & MSHLFLAGS_NORMAL) > - { > - if (m->norm_refs) > - m->norm_refs--; > - else > - { > - ERR("attempted invalid normal unmarshal, norm_refs is zero\n"); > - ret = FALSE; > - } > - } > - > - LeaveCriticalSection(&m->lock); > - > - return ret; > + return TRUE; > } > > /* handles refcounting for CoReleaseMarshalData */ > Although logically correct, I am not sure if this is what it should look like. In ole32/marshal for example there is also: --- snip --- if (flags & MSHLFLAGS_TABLEWEAK) TRACE(" MSHLFLAGS_TABLEWEAK"); if (!(flags & (MSHLFLAGS_TABLESTRONG|MSHLFLAGS_TABLEWEAK))) TRACE(" MSHLFLAGS_NORMAL"); if (flags & MSHLFLAGS_NOPING) TRACE(" MSHLFLAGS_NOPING"); --- snip --- This could probably mean that fixing the if condition is a more correct solution, but I don't know that part well enough.

Nov. 19, 2014

Re: [PATCH 1/2] mmdevapi: allow GetPropValue function in audio drivers

by Nikolay Sivov

On 18.11.2014 20:59, Mark Harmstone wrote: > + if (SUCCEEDED(hr)) > + { > + MMDevice_SetPropValue(id, flow, prop, &pv); > + > + if (pv.vt == VT_LPWSTR) > + HeapFree(GetProcessHeap(), 0, pv.u.pwszVal); > + } > + out->vt = VT_LPWSTR; > + out->u.pwszVal = HeapAlloc(GetProcessHeap(), 0, 256 * sizeof(WCHAR)); This is a wrong way dealing with PROPVARIANT, you need to use PropVariantClear() and InitPropVariantFromString() - PROPVARIANT implies CoTaskMemAlloc/CoTaskMemFree memory management.

Nov. 18, 2014

Re: [PATCH 6/6] wined3d: Restore the display mode on focus change.

by Marvin

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=10336 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2446: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2451: Test failed: The focus window is active. device.c:2459: Test failed: Got unexpected hr 0x88760869. device.c:2465: Test failed: Got unexpect screen size 800x600. device.c:2485: Test failed: Got unexpect screen size 800x600. device.c:2621: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:2997: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3001: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3024: Test failed: Failed to reset device, hr 0x88760868. device.c:3028: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3032: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3046: Test failed: Failed to set foreground window. device.c:3050: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:3054: Test failed: Expected device window extended style 0x108, got 0x100.

Nov. 18, 2014

Re: [PATCH 4/6] d3d8/tests: Test mode restoration on focus loss.

by Marvin

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=10334 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2446: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2451: Test failed: The focus window is active. device.c:2459: Test failed: Got unexpected hr 0x88760869. device.c:2465: Test failed: Got unexpect screen size 800x600. device.c:2485: Test failed: Got unexpect screen size 800x600. device.c:2621: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:2997: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3001: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3024: Test failed: Failed to reset device, hr 0x88760868. device.c:3028: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3032: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3046: Test failed: Failed to set foreground window. device.c:3050: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:3054: Test failed: Expected device window extended style 0x108, got 0x100.

Nov. 18, 2014

Re: wined3d: Add NVIDIA Geforce GT 750M to supported device list.

by Andrei Slăvoiu

În ziua de Mar 18 Noi 2014, la 17:22:35, Matteo Bruni a scris: > Modifying that SM4 check is fine but we'd still require GLSL 1.50 and > that means the check is still going to fail with those drivers. In > theory we could also tone it down and e.g. only look for the SM4-level > features supported by all the drivers but I'm not sure the end result > would make a lot of sense. I'm not saying t modify the SM4 check in the glsl backend, that one needs to make sure the driver exposes everything needed for converting all features of DX10. I was thinking of adding another extra check to d3d_level_from_caps similar to the one that checks for GLSL 1.30 for the mesa drivers. But since now that function no longer has access to gl_info and it would be very ugly to add it back just for this extension how about setting a new lets call it WINED3D_SHADER_CAP_GEOMETRY_SHADER4 to wined3d_caps in case this extension is found but not everything that is required for true SM4 support?

Nov. 18, 2014

Re: [PATCH 2/2] winealsa: implement GetPropValue and return device path

by Nikolay Sivov

On 18.11.2014 20:59, Mark Harmstone wrote: > --- a/dlls/winealsa.drv/Makefile.in > +++ b/dlls/winealsa.drv/Makefile.in > @@ -1,5 +1,5 @@ > MODULE = winealsa.drv > -IMPORTS = uuid ole32 advapi32 > +IMPORTS = uuid ole32 advapi32 user32 > DELAYIMPORTS = winmm > EXTRALIBS = $(ALSA_LIBS) If you need this only for wsprintfW() you could try sprintfW() from include/wine/unicode.h.

Nov. 18, 2014