June 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 5/7] d3drm: Fix device not assigning width and height after creation.

by Henri Verbeet

On 24 June 2016 at 23:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > HRESULT d3drm_device_set_ddraw_device_d3d(struct d3drm_device *device, IDirect3DRM *d3drm, IDirect3D *d3d, IDirect3DDevice *d3d_device) > { > + IDirectDrawSurface *surface; > + IDirect3DDevice2 *d3d_device2; > + DDSURFACEDESC desc; > + HRESULT hr; > + > device->d3drm = d3drm; > IDirect3DRM_AddRef(d3drm); > device->device = d3d_device; > IDirect3DDevice_AddRef(d3d_device); > > + /* Fetch render target and get width/height from there */ > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirectDrawSurface, (void **)&surface))) > + { > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirect3DDevice2, (void **)&d3d_device2))) > + return hr; > + hr = IDirect3DDevice2_GetRenderTarget(d3d_device2, &surface); > + IDirect3DDevice2_Release(d3d_device2); > + if (FAILED(hr)) > + return hr; > + } > + > + desc.dwSize = sizeof(desc); > + if (FAILED(hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc))) > + { > + IDirectDrawSurface_Release(surface); > + return hr; > + } > + > + device->width = desc.dwWidth; > + device->height = desc.dwHeight; > + IDirectDrawSurface_Release(surface); > + > return IDirect3D_QueryInterface(d3d, &IID_IDirectDraw, (void **)&device->ddraw); > } > This leaks some references (IDirect3DRM, IDirect3DDevice) on error paths, are those on purpose?

June 29, 2016

Re: shell32/tests: Avoid casts from a COM object to an iface.

by Michael Stefaniuc

On 06/29/2016 10:02 AM, 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=23879 > > Your paranoid android. > > > === w1064 (32 bit shlfolder) === > shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 > > === w1064 (64 bit shlfolder) === > shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 This is a pre-existing failure. bye michael

June 29, 2016

Re: shell32/tests: Avoid casts from a COM object to an iface.

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=23879 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 === w1064 (64 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

June 29, 2016

Re: [PATCH] d3dx9: Avoid overflowing debug channel buffer when tracing ASCII effect errors.

by Alistair Leslie-Hughes

Hi Matteo, On 29/06/16 03:06, Matteo Bruni wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > Inspired by a patch by Alistair Leslie-Hughes. > > dlls/d3dx9_36/effect.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(53,7): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(55,9): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "StaticMesh.fx(484,39): warning X3206: implicit truncation of vector type" Hers is the output from your patch. The first too lines are warnings are split across trace statement. Should we use a larger number to attempt to have each error/warning on one line. Best Regards Alistair Leslie-Hughes

June 28, 2016

Re: [PATCH] winex11: fix destroying of top-level windows

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-28 um 11:43 schrieb Henri Verbeet: > On 25 June 2016 at 01:26, Miklós Máté <mtmkls(a)gmail.com> wrote: >> I couldn't reproduce that test failure. I cloned Stefan's >> repository (master branch), applied my glx 1.3 patches that are >> in 1.9.12, and v2 of this patch, and I set the registry keys for >> CSMT (csmt=enabled, strictdrawordering=disabled). The d3d9 tests >> all pass. Did I miss something? Is there a way to tell if CSMT is >> in use? >> > Mostly by messages like "fixme:d3d:context_acquire Acquiring a GL > context from outside the CS thread." > > The d3d9 tests do pass here, but e.g. ddraw7 from the ddraw tests > fails with a GLXBadWindow from X_GLXDestroyWindow. > WINEDEBUG=+synchronous makes it work. There's also a "failed to > create drawable" message that I didn't investigate. FYI, the CSMT patches currently have a race condition when setting up / tearing down devices. I had a hacky workaround for that previously that fixed the random GLXBadWindow failures. I haven't included this patch yet in my "new" rebase because it was somewhat convoluted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcrNhAAoJEN0/YqbEcdMwsXEQAIZ8+4dahYho6RxBa5DsQiMj sqTTXZdEK9strUkVcFjqi0ercm8yU6ubhLMHFgumh+caAGGLiC8TaYQNVQvN6s40 KN9qJ1Vi7Ae11GqWwFVV/MIL6YwYmXnWsgaFlBB8itn50Cv6CT9VyYsJRmw97b7Y 0TRpOhTsaYqsGGWNK1dbfI5LWPKY4cAUCPOMcDY8xpEJUZhcNzg0kHilJn1gQQfh E5klKtq9HQ3qd/xljHvTxdwtTqh/i2QmrDdxONg9546er4QoHHZK4hJ+xu/VOjv0 PVvegnRu8eZKU3V1N/JxN9t3cxL6XXtNmhCik8tfExZGPb6PZCHETqx2xQO9y+hA qV50C6EuQN89AqNwITKaE4NydQ/sDBGg96ld2VKmPsSemvWYgIzswwWeFRVu8zXy HYMMsxNDKjC4nwvLwYuWVuzXQ3vTuYgBk2DxT78huWljDCnuxPf4KpzcQjMNUr4c 3UoO3gZsVH2uGFElD8PTSjzUUR9C4HN94MiwNZ63pqCUSqt2PN68hjZesfdh3bTD 2ljznN/P51PimHKUsaCFdEUdGQnk2vpVovTGt1OQGzIKn51FP9mr4Sf5ltoOPmY0 IkAFE45pcxlZccKjN/Mi7tmSZsizCJ0lUX+vYLm4eC3J7PoRAD6b7+eyDQQr2yG8 AIUTCs57/kr5fbM28x9A =9yQa -----END PGP SIGNATURE-----

June 28, 2016

Re: d3dx10: Implement D3DX10CompileFromMemory.

by Matteo Bruni

2016-06-27 21:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > + TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > + "sflags %#x, eflage %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", "eflage" typo. > diff --git a/dlls/d3dx10_43/d3dx10_43_main.c b/dlls/d3dx10_43/d3dx10_43_main.c > index 0c1ff80..fe56ee0 100644 > --- a/dlls/d3dx10_43/d3dx10_43_main.c > +++ b/dlls/d3dx10_43/d3dx10_43_main.c > @@ -37,6 +37,8 @@ > #include "d3dx10core.h" > #include "d3dx10tex.h" > > +#include "wine/debug.h" That is already included a few lines above. Looks good otherwise.

June 28, 2016

Re: [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection

by Matteo Bruni

2016-06-23 1:45 GMT+02:00 Vijay Kiran Kamuju <infyquest(a)gmail.com>: > [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection > > This add missing fields to the d3dcompiler_shader_reflection based on > http://timjones.tw/blog/archive/2015/09/02/parsing-direct3d-shader-bytecode > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476590(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb694550(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb172432(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476209(v=vs.85).… Thank you for the links, that saved me some time to have to look them up. > + UINT sample_frequency_shader; As far as I understand, that would be better served by a BOOL. > UINT dcl_count; > + UINT def_count; Nitpick but def_count is right before dcl_count in both D3D11_SHADER_DESC and in the shader bytecode, it would be nice to have the same order everywhere. We have tests for this in d3dcompiler_43/tests/reflection.c. Can you please add some tests for those new fields too? Notice that you don't necessarily need n separate new tests for each of the n new features. The patch subject should be something like "d3dcompiler: Add d3d11 fields to struct d3dcompiler_shader_reflection." i.e. no square brackets for the dll prefix and put a colon after it. Also, while not strictly required, it's encouraged to use git send-email, it will inline the patch without wrapping and generally take care of most of the formatting details, assuming git is configured correctly.

June 28, 2016

Re: [v2 PATCH] d3dx9_36: Stop crash when displaying effect errors

by Matteo Bruni

2016-06-22 13:10 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > if (temp_errors) > - TRACE("%s\n", (char *)ID3D10Blob_GetBufferPointer(temp_errors)); > + { > + const char *p = ID3D10Blob_GetBufferPointer(temp_errors); > + SIZE_T size = ID3D10Blob_GetBufferSize(temp_errors); > + const char *end = p + size; > + const char *line = p; > + > + while (p != end) > + { > + if (*p == '\n') > + { > + UINT len = p - line; > + if (len && *(p - 1) == '\r') --len; > + TRACE("%s\n", debugstr_an(line, len)); > + line = ++p; > + } > + else ++p; > + } > + if (line != p) > + TRACE("%s\n", debugstr_an(line, p - line)); > + } This only breaks at '\n', which might still be too much if the lines are particularly long. I also wrote a patch for this a few days ago. I'm going to send it to wine-patches in a bit, I'd appreciate if you can test if it works for you or point out any issue with it.

June 28, 2016

Re: include: Add missing interface declaration.

by Nikolay Sivov

> interface IWbemContext; > interface IWbemServices; > +interface IWbemLocator; > interface IWbemStatusCodeText; > interface IWbemCallResult; > interface IWbemObjectSink; Why do you need this? IWbemLocator is fully defined later in this file.

June 28, 2016

Re: [PATCH] winex11: fix destroying of top-level windows

by Henri Verbeet

On 25 June 2016 at 01:26, Miklós Máté <mtmkls(a)gmail.com> wrote: > I couldn't reproduce that test failure. I cloned Stefan's repository (master > branch), applied my glx 1.3 patches that are in 1.9.12, and v2 of this > patch, and I set the registry keys for CSMT (csmt=enabled, > strictdrawordering=disabled). The d3d9 tests all pass. Did I miss something? > Is there a way to tell if CSMT is in use? > Mostly by messages like "fixme:d3d:context_acquire Acquiring a GL context from outside the CS thread." The d3d9 tests do pass here, but e.g. ddraw7 from the ddraw tests fails with a GLXBadWindow from X_GLXDestroyWindow. WINEDEBUG=+synchronous makes it work. There's also a "failed to create drawable" message that I didn't investigate.

June 28, 2016