wine-devel January 2017

wine-devel@winehq.org

54 participants
144 discussions

Re: [PATCH v3 1/4] ddraw: Don't crash if writing out a new ddraw1 surface segfaults.
by Marvin 28 Jan '17

28 Jan '17

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=28113 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:1662: Test failed: Got unexpected color 0x000000ff.

1 0

Re: [PATCH v3 1/4] ddraw: Don't crash if writing out a new ddraw1 surface segfaults.
by Sebastian Lackner 28 Jan '17

28 Jan '17

On 28.01.2017 22:59, Alex Henrie wrote: > + __TRY > { > - *surface = NULL; > - return hr; > + if (FAILED(hr)) > + { > + *surface = NULL; > + return hr; > + } Its not possible to use return in a __TRY block.

1 0

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.
by Henri Verbeet 27 Jan '17

27 Jan '17

On 27 January 2017 at 19:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] && needs_srgb_write(context, state, fb)) > + if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] > + && ((!(context->d3d_info->wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL) > + && fb->render_targets[0] && fb->render_targets[0]->format_flags & WINED3DFMT_FLAG_SRGB_WRITE) > + || state->render_states[WINED3D_RS_SRGBWRITEENABLE])) I think this looks suspicious, why is this more correct? In particular, wouldn't this enable sRGB clears on formats without WINED3DFMT_FLAG_SRGB_WRITE? Patch 2/5 hints that that may be intentional, but in that case, shouldn't this be independent of ARB_framebuffer_sRGB support?

2 3

Re: [PATCH v2 1/4] ddraw: Don't write out if a ddraw1 surface of size 0 is requested.
by Alex Henrie 27 Jan '17

27 Jan '17

2017-01-27 5:43 GMT-07:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 26 January 2017 at 06:20, Alex Henrie <alexhenrie24(a)gmail.com> wrote: >> + hr = IDirectDraw_CreateSurface(ddraw, &surface_desc, &surface, NULL); >> + ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr); >> + ok(surface == (IDirectDrawSurface *)0xdeadbeef || broken(!surface) /* 32-bit on Win8/10 */, >> + "Got unexpected surface %p.\n", surface); > Where does this pass without the broken()? It writes NULL to surface > for me on Windows 7, and appears to handle the exception when an > invalid pointer is passed in. http://testbot.winehq.org/JobDetails.pl?Key=28086 The following testbot VMs are the only ones that zero out the surface pointer: w8 (32 bit ddraw1) w864 (32 bit ddraw1) w1064 (32 bit ddraw1) Maybe the behavior of newer versions of Windows depends on the video card driver? -Alex ---------- Forwarded message ---------- From: Marvin <testbot(a)winehq.org> Date: 2017-01-27 10:00 GMT-07:00 Subject: TestBot job 28086 results: ddraw: Don't write out if a ddraw1 surface of size 0 is requested. To: Alex Henrie <alexhenrie24(a)gmail.com> VM Status Number of test failures build completed wxppro completed 0 w2003std completed 0 wvistau64 completed 0 w2008s64 completed 0 w7u completed 0 w7pro64 completed 0 w8 completed 1 w864 completed 1 w1064 completed 2 wvistau64 completed 0 w2008s64 completed 0 w7pro64 completed 0 w864 completed 0 w1064 completed 1 === build (build) === No build failures found === wxppro (32 bit ddraw1) === No test failures found === w2003std (32 bit ddraw1) === No test failures found === wvistau64 (32 bit ddraw1) === No test failures found === w2008s64 (32 bit ddraw1) === No test failures found === w7u (32 bit ddraw1) === No test failures found === w7pro64 (32 bit ddraw1) === No test failures found === w8 (32 bit ddraw1) === ddraw: ddraw1.c:1971: Test failed: Got unexpected surface 00000000. === w864 (32 bit ddraw1) === ddraw: ddraw1.c:1971: Test failed: Got unexpected surface 00000000. === w1064 (32 bit ddraw1) === ddraw: ddraw1.c:1971: Test failed: Got unexpected surface 00000000. ddraw1.c:2299: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === wvistau64 (64 bit ddraw1) === No test failures found === w2008s64 (64 bit ddraw1) === No test failures found === w7pro64 (64 bit ddraw1) === No test failures found === w864 (64 bit ddraw1) === No test failures found === w1064 (64 bit ddraw1) === ddraw: ddraw1.c:2299: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

2 1

Re: [PATCH] d3dx11: Add D3DX11CreateShaderResourceViewFromMemory stub. (resend)
by Matteo Bruni 27 Jan '17

27 Jan '17

2017-01-25 12:19 GMT+01:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > dlls/d3dx11_42/Makefile.in | 1 + > dlls/d3dx11_42/d3dx11_42.spec | 2 +- > dlls/d3dx11_43/Makefile.in | 1 + > dlls/d3dx11_43/d3dx11_43.spec | 2 +- > dlls/d3dx11_43/shader.c | 36 ++++++++++++++++++++++++++++++++++++ > 5 files changed, 40 insertions(+), 2 deletions(-) > create mode 100644 dlls/d3dx11_43/shader.c I had a better look at the patch and unfortunately I don't think this is okay as is. Sorry that I missed it the first time around. The D3DX11CreateShaderResourceViewFrom* functions are probably supposed to be very thin wrappers over the corresponding D3DX11CreateTextureFrom* functions. So e.g. for D3DX11CreateShaderResourceViewFromMemory() an implementation calling D3DX11CreateTextureFromMemory() and then ID3D11Device_CreateShaderResourceView(device, ...) on the returned resource is probably all there is to it. Except that, for the pump != NULL case, you want to do the work on the thread pump so e.g. create the the SRV in a ID3DX11DataProcessor. Anyway, it's still okay to me to go with just a stub or with an implementation only taking into account the !pump case. You need to add the function definition to d3dx11tex.h though. Also, given that this is really a texture function, it doesn't make sense to put it in a new shader.c file. Just adding it to texture.c seems fine.

1 0

Re: opengl32: add OpenGL 3.3/4.0 extensions
by Vito Paradiso 27 Jan '17

27 Jan '17

i quite didn’t understand > Il giorno 16 gen 2017, alle ore 22:49, Marvin <testbot(a)winehq.org> ha scritto: > > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "No patch". > > This means that no patch was found in your mail. > > If you do not understand the reason for this status, disagree with our > assessment, or are simply not sure how to proceed next, please ask for > clarification by replying to this email.

1 0

Re: [PATCH] d3d8/tests: Fix copy&paste issue in compare_mode (cppcheck)
by Henri Verbeet 27 Jan '17

27 Jan '17

On 27 January 2017 at 05:58, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > - unsigned int h = mode_b->h - mode_b->h; > + unsigned int h = mode_a->h - mode_b->h; This is correct of course, but I'd hesitate to call copy/paste on it.

1 0

Re: [PATCH v2 1/4] ddraw: Don't write out if a ddraw1 surface of size 0 is requested.
by Henri Verbeet 27 Jan '17

27 Jan '17

On 26 January 2017 at 06:20, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > + hr = IDirectDraw_CreateSurface(ddraw, &surface_desc, &surface, NULL); > + ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr); > + ok(surface == (IDirectDrawSurface *)0xdeadbeef || broken(!surface) /* 32-bit on Win8/10 */, > + "Got unexpected surface %p.\n", surface); Where does this pass without the broken()? It writes NULL to surface for me on Windows 7, and appears to handle the exception when an invalid pointer is passed in.

1 0

Re: ntprint: Fix PSetupCreateMonitorInfo spec file entry
by Huw Davies 27 Jan '17

27 Jan '17

On Thu, Jan 26, 2017 at 11:46:57PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntprint/ntprint.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > diff --git a/dlls/ntprint/ntprint.spec b/dlls/ntprint/ntprint.spec > index 8869776..3687979 100644 > --- a/dlls/ntprint/ntprint.spec > +++ b/dlls/ntprint/ntprint.spec > @@ -2,7 +2,7 @@ > @ stub PSetupAssociateICMProfiles > @ stub PSetupBuildDriversFromPath > @ stub PSetupCreateDrvSetupPage > -@ stdcall PSetupCreateMonitorInfo(long ptr ptr) > +@ stdcall PSetupCreateMonitorInfo(ptr ptr ptr) > @ stub PSetupCreatePrinterDeviceInfoList > @ stub PSetupDestroyDriverInfo3 > @ stdcall PSetupDestroyMonitorInfo(long) > I get exceptions running the tests on 32-bit Windows (with or without this patch) which go away when I call the function with just two arguments - I suspect we should lose the third argument. Huw.

1 0

Re: ntdll: add a stub for NtLoadKey2/ZwLoadKey2
by Dmitry Timoshkov 27 Jan '17

27 Jan '17

Austin English <austinenglish(a)gmail.com> wrote: > +NTSTATUS WINAPI NtLoadKey2(OBJECT_ATTRIBUTES *attr, OBJECT_ATTRIBUTES *file, ULONG flags) > +{ > + NTSTATUS ret; > + > + FIXME("(%p,%p,0x%08x) semi-stub: ignoring flags\n", attr, file, flags); > + ret = NtLoadKey(attr, file); > + > + return ret; > +} There is no need for an intermediate variable. -- Dmitry.

1 0

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2017