- wine-devel - winehq.org

[PATCH] Added Nvidia GT 9700M
by Kim Malmo 19 Apr '16

19 Apr '16

Thanks for your feedback Henri. By looking at similar cards in the code I found the GT/GTS description were often omitted from mobile (M) cards. I wanted to keep the same text formatting. This is indeed the GT version and I can add that to the patch. I will sign off the next patch, still getting to grips with git. -- Date: Mon, 18 Apr 2016 19:00:33 +0200 From: Henri Verbeet<hverbeet(a)gmail.com> To: wine-devel<wine-devel(a)winehq.org> Cc: Kim Malmo<kimmalmo(a)protonmail.ch> Subject: Re: [PATCH] Added Nvidia GT 9700M Message-ID: <CAOsNvwyqyR1swwYaPUhiOpu7+TtBRuC9yg33Zi4+KYE1J0EyEw(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On 18 April 2016 at 18:39, Kim Malmo<berencamlost(a)msn.com> wrote: > From: Kim Malmo<kimmalmo(a)protonmail.ch> > > --- > dlls/wined3d/directx.c | 2 ++ > dlls/wined3d/wined3d_private.h | 1 + > 2 files changed, 3 insertions(+) > You're missing the Signed-off-by line. Passing -s to format-patch will add it. > + {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700M, "NVIDIA GeForce 9700M", DRIVER_NVIDIA_GEFORCE8, 512 }, Is that the correct description string for the card? I'm only finding references to the 9700M GT and 9700M GTS.

2 2

Re: [PATCH 04/10] wined3d: Add support for rendering to 2D array textures.
by Henri Verbeet 19 Apr '16

19 Apr '16

On 19 April 2016 at 00:01, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Layered rendering is not supported yet. > > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/wined3d/context.c | 84 +++++++++++++++++++++++++----------------- > dlls/wined3d/directx.c | 6 +++ > dlls/wined3d/wined3d_private.h | 5 ++- > 3 files changed, 60 insertions(+), 35 deletions(-) > This one conflicts with 121430.

1 0

Re: [PATCH 2/2] include/wincon.h: add some undocumented prototypes
by Hugh McMaster 19 Apr '16

19 Apr '16

On Tuesday, 19 April 2016 11:25 AM UTC+10, Austin English wrote: > +/* Undocumented */ > +WINBASEAPI DWORD WINAPI GetNumberOfConsoleFonts(void); [...] > +/* Undocumented */ > +WINBASEAPI BOOL WINAPI SetConsoleFont(HANDLE, DWORD); [...] > +/* Undocumented */ > +WINBASEAPI BOOL WINAPI SetConsoleIcon(HICON); > +WINBASEAPI BOOL WINAPI SetConsoleMode(HANDLE,DWORD); As with your previous patch, these functions can only be called via GetModuleHandle and GetProcAddress on Windows, so they shouldn't be included in wincon.h. -- Hugh McMaster

1 1

RE: [PATCH 1/2] kernel32: add GetConsoleFontInfo stub
by Hugh McMaster 19 Apr '16

19 Apr '16

On Tuesday, 19 April 2016 11:25 AM, Austin English wrote: >+BOOL WINAPI GetConsoleFontInfo(HANDLE hOutput, BOOL bMaximize, DWORD numFonts, CONSOLE_FONT *info) >+{ >+ FIXME("(%p %d %u %p): stub!\n", hOutput, bMaximize, numFonts, info); >+ SetLastError(ERROR_CALL_NOT_IMPLEMENTED); >+ return FALSE; >+} Please add this function after the GetConsoleFontSize function. We should keep the "Ex" functions in their own group at the bottom of console.c. Also, avoid Hungarian notation for bMaximize. That's okay for the HANLDE, although it should be hConsole. to match the surrounding code. >+/* Undocumented */ >+WINBASEAPI BOOL WINAPI GetConsoleFontInfo(HANDLE, BOOL, DWORD, CONSOLE_FONT *); I can't check right now, but I'm fairly certain GetConsoleFontInfo should not be included in wincon.h. IIRC, this function cannot be called directly from a console program, only via GetModuleHandle and GetProcAddress. -- Hugh McMaster

1 0

Re: [PATCH 4/4] inetcomm/tests: Add IMimeMessage SetOption tests
by Marvin 19 Apr '16

19 Apr '16

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=22311 Your paranoid android. === wvistau64 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w864 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w1064 (64 bit mimeole) === Found no trace of the test summary line or of a crash

1 0

Re: ddraw/tests: A spelling fix for a d3d ok() message.
by Marvin 19 Apr '16

19 Apr '16

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=22306 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: advapi32/tests: Some spelling fixes for the security ok() messages.
by Marvin 19 Apr '16

19 Apr '16

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=22304 Your paranoid android. === w1064 (32 bit security) === security.c:3964: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

1 0

Re: [Tools] testbot/TestAgent: Better indicate the file transfer position/range in case of errors.
by Francois Gouget 19 Apr '16

19 Apr '16

Should I resend or change this patch? On Mon, 11 Apr 2016, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > testbot/lib/WineTestBot/TestAgent.pm | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/testbot/lib/WineTestBot/TestAgent.pm b/testbot/lib/WineTestBot/TestAgent.pm > index 74e7395..82ca97f 100644 > --- a/testbot/lib/WineTestBot/TestAgent.pm > +++ b/testbot/lib/WineTestBot/TestAgent.pm > @@ -486,7 +486,7 @@ sub _RecvFile($$$$) > if (!defined $r) > { > alarm(0); > - $self->_SetError($FATAL, "got a network error while receiving '$Filename' ($self->{rpc}:$Name:$Pos/$Size): $!"); > + $self->_SetError($FATAL, "got a network error while receiving '$Filename' ($self->{rpc}:$Name:$Pos+$s/$Size): $!"); > return; # out of eval > } > if ($r == 0) > @@ -501,7 +501,7 @@ sub _RecvFile($$$$) > if (!defined $w or $w != $r) > { > alarm(0); > - $self->_SetError($ERROR, "an error occurred while writing to '$Filename' ($self->{rpc}:$Name:$Pos/$Size): $!"); > + $self->_SetError($ERROR, "an error occurred while writing to '$Filename' ($self->{rpc}:$Name:$Pos+$r/$Size): $!"); > $self->_SkipRawData($Name, $Remaining); > return; # out of eval > } > @@ -806,7 +806,7 @@ sub _SendFile($$$$) > if (!defined $r) > { > alarm(0); > - $self->_SetError($FATAL, "an error occurred while reading from '$Filename' ($self->{rpc}:$Name:$Pos/$Size): $!"); > + $self->_SetError($FATAL, "an error occurred while reading from '$Filename' ($self->{rpc}:$Name:$Pos+$s/$Size): $!"); > return; # out of eval > } > if ($r == 0) > @@ -821,7 +821,8 @@ sub _SendFile($$$$) > if (!defined $w or $w != $r) > { > alarm(0); > - $self->_SetError($FATAL, "got a network error while sending '$Filename' ($self->{rpc}:$Name:$Pos+$s/$Size): $!"); > + # Overwrite _Write()'s error message with a more appropriate one > + $self->_SetError($FATAL, "got a network error while sending '$Filename' ($self->{rpc}:$Name:$Pos+$r/$Size): $!"); > return; # out of eval > } > } > -- > 2.8.0.rc3 > > > -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 1

wined3d: Add Nvidia GT 9700M
by Kim Malmo 18 Apr '16

18 Apr '16

Thanks Caron, that's exactly the kind of feedback I wanted. I now feel really stupid. The spacing and line breaks comes from copy/pasting the patch into an email, as I couldn't get git-send-email to work. Apparently, it has it's own package in Ubuntu. That's causing the linebreaks. The spacing I cannot explain, but ofcourse both come out clean when using git-send-email. Thanks for that. That's still no excuse for sending a patch with bad formatting though. Now I just have to figure out how to properly use git-send-email so I can add the comments I want. I'm new to git. Do I need to sign off my own patches? Just curious how it works, I had imagined one of the proper developers had to sign it off. -- Actually, you sent it to the right place. There are some things you should have a look at that my eyes are drawn to. First, when reviewed here, the patch has odd line breaks and spacing: https://source.winehq.org/patches/data/121371 It's also missing your signed-off-by line. You can read about how to add that here: https://wiki.winehq.org/Submitting_Patches Your patch should come through clean and match the surrounding style. I had a patch accepted adding the same number of lines in the same general places, pay close attention to how the two differ in appearance: https://source.winehq.org/patches/data/121336 I'm looking at those patches simply by going to this page to make sure everything "looks" okay: https://source.winehq.org/patches/ Note the red "X" indicating the missing sign-off next to your patch. You would do yourself many favors by using git send-email to send patches or in the very least, take a moment to create a patch and check it over once, twice, three times, before sending. I commit to my local tree and then I do: git format-patch origin and compare what's going on and then I make sure Wine still builds after my changes. I catch a lot of mistakes that way (like missing a comma...). Thank you for sending a patch and following up on it. Others might have more feedback for you. -Caron

2 1

Re: [PATCH] Added Nvidia GT 9700M
by Henri Verbeet 18 Apr '16

18 Apr '16

On 18 April 2016 at 18:39, Kim Malmo <berencamlost(a)msn.com> wrote: > From: Kim Malmo <kimmalmo(a)protonmail.ch> > > --- > dlls/wined3d/directx.c | 2 ++ > dlls/wined3d/wined3d_private.h | 1 + > 2 files changed, 3 insertions(+) > You're missing the Signed-off-by line. Passing -s to format-patch will add it. > + {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700M, "NVIDIA GeForce 9700M", DRIVER_NVIDIA_GEFORCE8, 512 }, Is that the correct description string for the card? I'm only finding references to the 9700M GT and 9700M GTS.

1 0

Re: [PATCH 1/2] d3drm: Implement IDirect3DRM*::CreateObject.
by Henri Verbeet 18 Apr '16

18 Apr '16

On 17 April 2016 at 22:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -1054,10 +1058,50 @@ static ULONG WINAPI d3drm3_Release(IDirect3DRM3 *iface) > static HRESULT WINAPI d3drm3_CreateObject(IDirect3DRM3 *iface, > REFCLSID clsid, IUnknown *outer, REFIID iid, void **out) > { > - FIXME("iface %p, clsid %s, outer %p, iid %s, out %p stub!\n", > + void *object_struct; ... > + if (IsEqualGUID(clsid, &CLSID_CDirect3DRMTexture)) > + { > + if (FAILED(hr = d3drm_texture_create((struct d3drm_texture **)&object_struct))) > + { > + *out = NULL; > + return hr; > + } > + object = (IUnknown *)&((struct d3drm_texture *)object_struct)->IDirect3DRMTexture3_iface; > + } Why do you need "object_struct"?

2 8

Re: ddraw [v3]: Move ComputeSphereVisibility tests to ddraw7
by Henri Verbeet 18 Apr '16

18 Apr '16

On 18 April 2016 at 09:02, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Thos one with my valid email address. > Please try to match the structure and style of the other tests in ddraw7.c, and please use git send-email for submitting patches.

1 0

Re: [PATCH] d3dx9: Don't complain when overwriting effect object id 0.
by Matteo Bruni 18 Apr '16

18 Apr '16

2016-04-18 15:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Matteo, > > I must be missing something, but don't you forget to free the > object->data when it is reallocated at least for object id 0 when it is > not FIXME anymore? I suppose you don't but I looked through several > times and do not see how it can be freed when it was allocated previously. > > Regards, > Paul. No, you're right, I forgot the free altogether. Let's drop this patch, unless it's too late. I'll send a fix either way.

1 2

wined3d: Add Nvidia GT 9700M
by Kim Malmo 18 Apr '16

18 Apr '16

I posted this one to wine-patches, I realize I may have sent it to the wrong mailing list. I would probably want some feedback on this one, as it's basically a dirty hack I put together. Critisism welcome. Posted here: https://www.winehq.org/pipermail/wine-patches/2016-April/149298.html wined3d: Add Nvidia GT 9700M Bug: https://bugs.winehq.org/show_bug.cgi?id=36031 --- dlls/wined3d/directx.c | 2 ++ dlls/wined3d/wined3d_private.h | 1 + 2 files changed, 3 insertions(+) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 8358930..6b115d3 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -1230,6 +1230,7 @@ static const struct gpu_description gpu_description_table[] = {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9400GT, "NVIDIA GeForce 9400 GT", DRIVER_NVIDIA_GEFORCE8, 256 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9500GT, "NVIDIA GeForce 9500 GT", DRIVER_NVIDIA_GEFORCE8, 256 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600GT, "NVIDIA GeForce 9600 GT", DRIVER_NVIDIA_GEFORCE8, 384 }, + {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700M, "NVIDIA GeForce 9700M", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800GT, "NVIDIA GeForce 9800 GT", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_210, "NVIDIA GeForce 210", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GT220, "NVIDIA GeForce GT 220", DRIVER_NVIDIA_GEFORCE8, 512 }, @@ -1819,6 +1820,7 @@ cards_nvidia_binary[] = {"GTS 150", CARD_NVIDIA_GEFORCE_9800GT}, /* Geforce 9 - highend / Geforce 200 - midend */ {"9800", CARD_NVIDIA_GEFORCE_9800GT}, /* Geforce 9 - highend / Geforce 200 - midend */ {"GT 140", CARD_NVIDIA_GEFORCE_9600GT}, /* Geforce 9 - midend */ + {"9700M", CARD_NVIDIA_GEFORCE_9700M}, /* Geforce 9 - midend */ {"9600", CARD_NVIDIA_GEFORCE_9600GT}, /* Geforce 9 - midend */ {"GT 130", CARD_NVIDIA_GEFORCE_9500GT}, /* Geforce 9 - midend low / Geforce 200 - low */ {"GT 120", CARD_NVIDIA_GEFORCE_9500GT}, /* Geforce 9 - midend low / Geforce 200 - low */ diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 24515da..95dd88b 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -1739,6 +1739,7 @@ enum wined3d_pci_device CARD_NVIDIA_GEFORCE_9400GT = 0x042c, CARD_NVIDIA_GEFORCE_9500GT = 0x0640, CARD_NVIDIA_GEFORCE_9600GT = 0x0622, + CARD_NVIDIA_GEFORCE_9700M = 0x064a, CARD_NVIDIA_GEFORCE_9800GT = 0x0614, CARD_NVIDIA_GEFORCE_210 = 0x0a23, CARD_NVIDIA_GEFORCE_GT220 = 0x0a20, -- 1.9.1

2 1

Re: riched20: Use SetRect instead of open coding it.
by Huw Davies 18 Apr '16

18 Apr '16

On 18 Apr 2016, at 09:11, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > --- a/dlls/riched20/paint.c > +++ b/dlls/riched20/paint.c > @@ -617,10 +617,8 @@ static void ME_DrawParaDecoration(ME_Context* c, ME_Paragraph* para, int y, RECT > MoveToEx(c->hDC, c->pt.x, y + bounds->top, NULL); > LineTo(c->hDC, c->pt.x, y + para->nHeight - bounds->bottom); > if (border_details[idx].dble) { > - rc.left = c->pt.x + 1; > - rc.right = rc.left + border_width; > - rc.top = y + bounds->top; > - rc.bottom = y + para->nHeight - bounds->bottom; > + SetRect(&rc, c->pt.x + 1, y + bounds->top, rc.left + border_width, > + y + para->nHeight - bounds->bottom); This is using rc.left uninitialised. Huw.

2 2

Re: user32/tests: Use SetRect instead of open coding it.
by Marvin 18 Apr '16

18 Apr '16

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=22284 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2485: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2496: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2485: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2496: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

2 1

Re: wbemprox/tests: Add initial tests for ASSOCIATORS query.
by Hans Leidekker 18 Apr '16

18 Apr '16

On Sun, 2016-04-17 at 21:03 +0200, Sebastian Lackner wrote: > +static void test_associators( IWbemServices *services ) > +{ > + static const WCHAR query1[] = > + {'A','S','S','O','C','I','A','T','O','R','S',' ','O','F',' ','{','W','i','n','3','2','_', > + 'v','L','o','g','i','c','a','l','D','i','s','k','.', 'D','e','v','i','c','e','I','D','=','"','C',':','"','}',0}; Should that be 'Win32_LogicalDisk'?

2 1

Re: ddraw [v3]: Move ComputeSphereVisibility tests to ddraw7
by Marvin 18 Apr '16

18 Apr '16

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=22283 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: ddraw [V2]: Move ComputeSphereVisibilty to ddraw7
by Marvin 18 Apr '16

18 Apr '16

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=22282 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: ddraw: Move ComputeSphereVisibilty to ddraw7
by Marvin 18 Apr '16

18 Apr '16

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=22281 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: d3dxof & d3dx9_36: Unknown spelling fixes.
by Matteo Bruni 17 Apr '16

17 Apr '16

2016-04-15 14:29 GMT+02:00 Francois Gouget <fgouget(a)free.fr>: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > dlls/d3dx9_36/tests/shader.c | 2 +- > dlls/d3dxof/tests/d3dxof.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) The changes look fine but could you please split the patch in two?

1 0

Re: [PATCH 6/6] d3dx9: Add test for D3DXSHMultiply3 arguments aliasing.
by Matteo Bruni 17 Apr '16

17 Apr '16

2016-04-14 14:10 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: A few nitpicks: > + const FLOAT expected_aliased[20] = > + { 454.092499f,2.126404f, 5.570401f, 15.330379f, 22.796087f, 43.604126f, > + 4.273841f, 175.772034f, 237.672729f, 1.09f, 1.1f, 1.11f, 1.12f, 1.13f, > + 1.14f, 1.15f, 1.16f, 1.17f, 1.18f, 1.19f }; You can use just 'float' and the indentation style we use in "modern" code. You can fixup the previous array declaration too if you want but it's also fine if you don't. > + for (i = 0; i < 20; i++) > + c[i] = a[i]; > + D3DXSHMultiply3(c, c, b); > + for (i = 0; i < 20; i++) > + ok(relative_error(c[i], expected_aliased[i]) < admitted_error, "Expected[%d] = %f, received = %f\n", i, expected[i], c[i]); This line is too long.

1 0

Re: [PATCH 3/6] d3dx9: D3DXQuaternionSquadSetup should support arguments aliasing.
by Matteo Bruni 17 Apr '16

17 Apr '16

2016-04-14 14:10 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: Neither of those are your faults, but since you're at it... > - if ( D3DXQuaternionDot(pq0, pq1) < 0.0f ) > + if (D3DXQuaternionDot(pq0, pq1) < 0.0f) > temp2 = add_diff(&zero, pq0, -1.0f); > else > temp2 = *pq0; also remove the double space. > @@ -1634,7 +1635,9 @@ void WINAPI D3DXQuaternionSquadSetup(D3DXQUATERNION *paout, D3DXQUATERNION *pbou > temp1.z *= -0.25f; > temp1.w *= -0.25f; > D3DXQuaternionExp(&temp1, &temp1); > - D3DXQuaternionMultiply(pbout, pcout, &temp1); > + D3DXQuaternionMultiply(pbout, &cout, &temp1); > + *paout = aout; > + *pcout = cout; > > return; > } Please also remove the unnecessary return.

1 0

Re: [v12 4/4] d3dx9: Implement setting named shader constants in effect.
by Matteo Bruni 17 Apr '16

17 Apr '16

2016-04-14 12:30 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: A bunch of nitpicks: > + for (i = 0; i < parameters_count; i++) ++i > + TRACE("sampler %s, register index %u, state count %u.\n", params[i]->name, > + cdesc[i].RegisterIndex, sampler->state_count); You probably want to use debugstr_a(). > +static HRESULT set_shader_constants_device(struct IDirect3DDevice9 *device, struct d3dx_regstore *rs, > + D3DXPARAMETER_TYPE type, enum pres_reg_tables table) > +{ > + unsigned int start, n; Better to call it "count" for consistency IMO. > + if (!n) > + continue; That works but a break seems clearer.

1 0

Re: d3d9/tests: Spelling fixes for a couple of ok() calls.
by Marvin 16 Apr '16

16 Apr '16

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=22235 Your paranoid android. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [2/2] kernel32/tests: Port stack commit tests to x86_64.
by Alexandre Julliard 15 Apr '16

15 Apr '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > START_TEST(virtual) > { > +#ifdef __x86_64__ > + static const char code_current_teb[] = { > + 0x65, 0x48, 0x8b, 0x04, 0x25, 0x30, 0x00, 0x00, 0x00, 0xc3 }; > +#endif It would be cleaner to use the existing inline function from winnt.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/6] wined3d: Implement texture DC creation on top of D3DKMTCreateDCFromMemory().
by Marvin 14 Apr '16

14 Apr '16

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=22198 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=1. === w1064 (64 bit d3d9ex) === d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=1. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH 2/6] wined3d: Implement texture DC creation on top of D3DKMTCreateDCFromMemory().
by Marvin 14 Apr '16

14 Apr '16

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=22197 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: compobj.dll16: Fix implementation of StringFromGUID2.
by Nikolay Sivov 14 Apr '16

14 Apr '16

On 14.04.2016 19:44, Sebastian Lackner wrote: > -INT WINAPI StringFromGUID216(REFGUID id, LPOLESTR str, INT cmax) > +INT WINAPI StringFromGUID216(REFGUID id, LPOLESTR16 str, INT cmax) It also should use INT16, with spec file fixed accordingly.

1 0

Fullscreen upscaling
by David Guillen Fandos 14 Apr '16

14 Apr '16

Hey there! I was looking into doing some automatic upscale for HiDPI screens (mine is 3200*1800). It would be some knob that allows the user to choose a x2 scaling for fullscreen apps and similar stuff. After reading winex11.drv I saw that it wouldn't be that hard to report 1/2 of the actual monitor resolution and then just upscale whatever gets rendered to the gdi_display (so we would have an unscaled surface and then blit that with a 2x scaling to the gdi_display). I guess that some other modifications would be needed though. Any comments on this? I think it could be useful for some people, nowadays that screens just got lots of pixels. Thanks! David G.F.

3 3

Re: [v2 PATCH] dwrite/tests: A test for glyphBox* metrics
by Marvin 14 Apr '16

14 Apr '16

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=22191 Your paranoid android. === w864 (32 bit font) === The test timed out

2 1

Re: [v2 PATCH 2/2] d3d10core: Support NULL RenderTargetView pointer in ClearRenderTargetView
by Marvin 14 Apr '16

14 Apr '16

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=22171 Your paranoid android. === w7u (32 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w7pro64 (32 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w8 (32 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w864 (32 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w1064 (32 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w7pro64 (64 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w864 (64 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w1064 (64 bit device) === device.c:6244: Test failed: Got unexpected value 2.35098856e-038 at (0, 0).

1 0

Re: [v2 PATCH 1/2] d3d10core: Support NULL DepthStecilView pointer in ClearDepthStencilView
by Marvin 14 Apr '16

14 Apr '16

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=22170 Your paranoid android. === w7u (32 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w7pro64 (32 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w8 (32 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w864 (32 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w1064 (32 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w7pro64 (64 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w864 (64 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0). === w1064 (64 bit device) === device.c:6235: Test failed: Got unexpected value 2.35098856e-038 at (0, 0).

1 0

Re: [PATCH] dwrite/tests: A test for glyphBox* metrics
by Sebastian Lackner 14 Apr '16

14 Apr '16

On 14.04.2016 06:13, Nikolay Sivov wrote: > + ok(m1->glyphBoxBottom == expected->glyphBoxBottom, "font %s: glyphBoxLeft %d, expected %d\n", wine_dbgstr_w(nameW), > + m1->glyphBoxBottom, expected->glyphBoxBottom); There is a copy&paste in the ok() message error here.

1 0

Re: [v11 1/4] d3dx9: Implement fxlc constants (expressions) in effect.
by Matteo Bruni 13 Apr '16

13 Apr '16

2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -369,12 +410,17 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > goto err_out; > } > count = 1; > - hr = ID3DXConstantTable_GetConstantDesc(ctab, hc, &cdesc[i], &count); > - if (FAILED(hr)) > + if (FAILED(hr = ID3DXConstantTable_GetConstantDesc(ctab, hc, &cdesc[i], &count))) > { > FIXME("Could not get constant desc, hr %#x.\n", hr); > goto err_out; > } > + if (count != 1) > + { > + FIXME("Unexpected constant descriptors count %u.\n", count); > + hr = D3DERR_INVALIDCALL; > + goto err_out; > + } Notice that, since you set count to 1 before calling GetConstantDesc(), the only possible results are 0 or 1 and the 0 case should be already handled by the "if (FAILED())" branch. You might use a temporary array of 3 elements and pass 3 as count, then only copy the first element to the destination so the rest of the code is unchanged while still giving a chance for the FIXME to trigger. Not sure it's worth it though, maybe just adding support for multiple descriptors (even only in struct d3dx_const_tab and the immediately related code) might be a better plan. > +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, > + D3DXHANDLE hc, struct d3dx_parameter *param) > +{ > + ID3DXConstantTable *ctab = const_tab->ctab; > + D3DXCONSTANT_DESC desc; > + unsigned int const_count, param_count, i, j, n, table, start_offset; > + unsigned int minor, major, major_stride, param_offset; > + BOOL transpose, get_element; > + unsigned int desc_count; > + > + desc_count = 1; > + ID3DXConstantTable_GetConstantDesc(ctab, hc, &desc, &desc_count); > + if (desc_count != 1) > + { > + FIXME("Unexpected constant descriptors count %u.\n", desc_count); > + return D3DERR_INVALIDCALL; > + } Same here, in this case the descriptors are only used locally so both options above should be easier to do. > + if (const_count != param_count) > + { > + FIXME("Number of elements or struct members differs between parameter and constant.\n"); > + return D3DERR_INVALIDCALL; > + } You could print the two counts here. Not a big deal though. Looks good otherwise.

2 2

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.
by Matteo Bruni 13 Apr '16

13 Apr '16

2016-04-07 17:41 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > switch (state->type) > { > case ST_CONSTANT: > + *param_value = param->data; > + *out_param = param; > + return D3D_OK; > case ST_PARAMETER: > + param = param->referenced_param; > *param_value = param->data; > *out_param = param; > return D3D_OK; It doesn't matter (this is perfectly fine) but you could have kept the fallthrough by switching these two cases around. > +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, > + D3DXHANDLE hc, struct d3dx_parameter *param) > +{ > + ID3DXConstantTable *ctab = const_tab->ctab; > + D3DXCONSTANT_DESC desc; > + unsigned int const_count, param_count, i, j, n, table, start_offset; > + unsigned int minor, major, major_stride, param_offset; > + BOOL transpose, get_element; > + > + ID3DXConstantTable_GetConstantDesc(ctab, hc, &desc, &const_count); This isn't correct, although it currently works. const_count is supposed to be an inout parameter for GetConstantDesc() (you could potentially have multiple instances of the same constant in different register sets). The current implementation of GetConstantDesc() doesn't check the parameter and blindly returns only the first descriptor, also setting const_count to 1 (actually the following descriptors aren't even parsed currently by the constant table code IIRC) so this ends up working, although that's a bug and at some point it might get fixed which would in turn break this. Also it's a bit of an "overload" to use the same variable here and as the count of constant elements / members in the following lines, it's probably nicer to use two separate variables. BTW you're using GetConstantDesc() correctly in get_constants_desc(). > + table = const_tab->regset2table[desc.RegisterSet]; > + if (table >= PRES_REGTAB_COUNT) > + { > + FIXME("Unexpected register set %u.\n", desc.RegisterSet); > + return D3DERR_INVALIDCALL; > + } Since regset2table is defined by us ERR() is maybe more appropriate here. It might make sense to also check desc.RegisterSet before accessing the array. > + hc = ID3DXConstantTable_GetConstant(const_tab->ctab, NULL, i); > + if (!hc) > + { > + FIXME("Could not get constant.\n"); > + hr = D3DERR_INVALIDCALL; You could probably also print the value of 'i' in the FIXME. Up to you, but you could switch the then and else branches and drop the '!' in the if condition. > + if (oi->func_all_comps) > + { > + if (oi->input_count * ins->component_count > ARGS_ARRAY_SIZE) > + { > + FIXME("Too many arguments (%u) for one instruction.\n", oi->input_count * ins->component_count); > + return E_FAIL; > + } I think this check should be outside of the if (oi->func_all_comps) block. > + hr = set_constants(&peval->pres.regs, &peval->pres.inputs); > + if (FAILED(hr)) > + return hr; > + > + hr = execute_preshader(&peval->pres); > + if (FAILED(hr)) > + return hr; Not a big deal but since you're there... You could merge the function calls with the respective if, like you're doing in some other patches of the series.

2 6

Re: [v11 4/4] d3dx9: Implement setting named shader constants in effect.
by Matteo Bruni 13 Apr '16

13 Apr '16

2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > static HRESULT d3dx9_apply_state(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > - struct d3dx_state *state, int parent_index) > + struct d3dx_state *state, unsigned int parent_index); > + > +HRESULT d3dx_set_shader_const_fxlc(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > + struct d3dx_parameter *param, BOOL vs) Nitpick, the _fxlc suffix doesn't seem correct at this point I think. Just call it d3dx_effect_set_shader_constants() or something similar? The function can probably be static too. > +static HRESULT set_shader_constants_device(struct IDirect3DDevice9 *device, struct d3dx_regstore *rs, > + D3DXPARAMETER_TYPE type, enum pres_reg_tables table) > +{ > + unsigned int start, n; Maybe call it "count" instead of "n"? It's up to you though.

1 0

Re: [v11 2/4] d3dx9: Add basic opcodes to preshader.
by Matteo Bruni 13 Apr '16

13 Apr '16

2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -3834,11 +3831,16 @@ static void test_effect_preshader(IDirect3DDevice9 *device) > v = i < 8 ? (unsigned int *)&light.Diffuse : (unsigned int *)&light.Ambient; > ok(hr == D3D_OK, "Got result %#x.\n", hr); > for (j = 0; j < 4; ++j) > + { > + unsigned int mask; > + > + mask = ~0u << test_effect_preshader_op_results[i].tolerance_bit_count; > todo_wine_if(test_effect_preshader_op_results[i].todo[j]) > - ok(v[j] == test_effect_preshader_op_results[i].result[j], > + ok((v[j] & mask) == (test_effect_preshader_op_results[i].result[j] & mask), That doesn't seem right. You can just use compare_float() to do a correct float comparison.

1 0

Re: [PATCH v2 4/5] d3d9/tests: Add some tests for the properties of the DC returned by surface GetDC().
by Marvin 13 Apr '16

13 Apr '16

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=22150 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=1. === w1064 (64 bit d3d9ex) === d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=1. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH v2 3/5] ddraw/tests: Add some tests for the properties of the DC returned by surface GetDC().
by Marvin 13 Apr '16

13 Apr '16

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=22149 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [5/9] webservices: Add support for reading enum values.
by Marvin 13 Apr '16

13 Apr '16

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=22153 Your paranoid android. === build (build) === Make failed

1 0

Re: hidclass.sys: Fix spelling of a private struct's name.
by Aric Stewart 13 Apr '16

13 Apr '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> On 4/13/16 4:28 AM, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > dlls/hidclass.sys/hid.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index 2820c9d..34c2a09 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -39,7 +39,7 @@ typedef NTSTATUS (WINAPI *pAddDevice)(DRIVER_OBJECT *DriverObject, DEVICE_OBJECT > /* Ring buffer functions */ > struct ReportRingBuffer; > > -typedef struct _BASE_DEVICE_EXTENSTION { > +typedef struct _BASE_DEVICE_EXTENSION { > HID_DEVICE_EXTENSION deviceExtension; > > HID_COLLECTION_INFORMATION information; >

1 0

Re: [PATCH v2 2/5] wined3d: Be more strict with wined3d_texture_get_dc() calls from d3d9.
by Marvin 13 Apr '16

13 Apr '16

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=22148 Your paranoid android. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH v2 1/5] wined3d: Be more lenient with wined3d_texture_get_dc() calls from ddraw.
by Marvin 13 Apr '16

13 Apr '16

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=22147 Your paranoid android. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH v2 1/5] wined3d: Be more lenient with wined3d_texture_get_dc() calls from ddraw.
by Marvin 13 Apr '16

13 Apr '16

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=22146 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 07/11] dxgi: Do not store IDXGIOutputs in IDXGIAdapter.
by Henri Verbeet 13 Apr '16

13 Apr '16

On 12 April 2016 at 12:29, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +HRESULT dxgi_output_create(struct dxgi_adapter *adapter, struct dxgi_output **output) > +{ > + if (!(*output = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(**output)))) > + { > + *output = NULL; > + return E_OUTOFMEMORY; > + } Explicitly setting output variables to NULL on failure can be ok (although I don't think it's needed for dxgi_output_create()), but note that *output is already NULL when HeapAlloc() fails.

1 0

Re: ole32/tests: Fix spelling of a few variable names.
by Marvin 13 Apr '16

13 Apr '16

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=22145 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w1064 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w1064 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A

1 0

Re: ucrtbase: Add __std_exception_destroy/copy
by Piotr Caban 13 Apr '16

13 Apr '16

Hi Daniel, please add following tests (and fix implementation): + src.what = NULL; + src.dofree = 0; + p___std_exception_copy(&src, &dst); + ok(!dst.what, "dst.what != NULL\n"); + ok(!dst.dofree, "dst.dofree != FALSE\n"); + + src.what = NULL; + src.dofree = 1; + p___std_exception_copy(&src, &dst); + ok(!dst.what, "dst.what != NULL\n"); + ok(!dst.dofree, "dst.dofree != FALSE\n"); Thanks, Piotr

1 0

Re: [PATCH 5/5] gdi32: Implement DC creation from pre-existing memory.
by Huw Davies 13 Apr '16

13 Apr '16

On Tue, Apr 12, 2016 at 06:09:32PM +0200, Henri Verbeet wrote: > diff --git a/dlls/gdi32/tests/bitmap.c b/dlls/gdi32/tests/bitmap.c > index e19c552..1b818b3 100644 > --- a/dlls/gdi32/tests/bitmap.c > +++ b/dlls/gdi32/tests/bitmap.c > @@ -5642,14 +5648,262 @@ static void test_SetDIBitsToDevice_RLE8(void) ... > + ok(size == sizeof(dib), "%s: Got unexpected size %d, expected %u.\n", > + test_data[i].name, size, sizeof(dib)); You have a couple of sizeof()s in ok()s. Other than that it looks good to me. Huw.

1 0

Re: [PATCH v2] ole32: Fix memory leak in CompositeMonikerImpl_Construct.
by Alexandre Julliard 13 Apr '16

13 Apr '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: F> Coverity #713613, "Variable This going out of scope leaks the storage it > points to." > > If we need to loop through This->tabMoniker and call IMoniker_Release on > each of its items, we should do the same in the other three similar > error paths in this function. Please let me know if this is what you > want. Yes, even if Coverity doesn't warn about the reference leaks, it should be fixed completely, otherwise once the warning is gone we'll forget about it. -- Alexandre Julliard julliard(a)winehq.org

1 0

2025

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