February 2017 - Wine-devel - list.winehq.org

Re: comctl32: Update the tooltip rectangle when a tool button is hidden
by Nikolay Sivov 21 Feb '17

21 Feb '17

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: [PATCH 3/4] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work.
by Marvin 21 Feb '17

21 Feb '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=28786 Your paranoid android. === w864 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 2/4] d3d9/tests: Work around a r500 Windows point sprite bug.
by Marvin 21 Feb '17

21 Feb '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=28785 Your paranoid android. === w1064 (64 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00000080 for no color attribute test.

1 0

Re: [PATCH 1/4] d3d8/tests: Work around a r500 Windows point sprite bug.
by Marvin 21 Feb '17

21 Feb '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=28784 Your paranoid android. === wvistau64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w2008s64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w7pro64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w864 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w1064 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?)

1 0

Re: [PATCH 3/4] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 23:31, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -10445,6 +10445,8 @@ static void test_pointsize(void) > vertex_pointsize = {64.0f, 64.0f, 0.1f, 48.0f}, > vertex_pointsize_scaled = {64.0f, 64.0f, 0.1f, 24.0f}, > vertex_pointsize_zero = {64.0f, 64.0f, 0.1f, 0.0f}; > + /* Writing a texture coordinate from the shader is technically unnecessary, but is required > + * to make AMD drivers work. Without it, texture coordinates in the pixel shaders are 0. */ Could you make that comment a bit more specific and mention the affected hardware and driver version?

1 0

Re: comctl32: Update the tooltip rectangle when a tool button is hidden
by Nikolay Sivov 20 Feb '17

20 Feb '17

On 20.02.2017 22:17, Eric Kohl wrote: > Signed-off-by: Eric Kohl <eric.kohl(a)t-online.de> > --- > dlls/comctl32/toolbar.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c > index 784745c..bb53d66 100644 > --- a/dlls/comctl32/toolbar.c > +++ b/dlls/comctl32/toolbar.c > @@ -1690,6 +1690,7 @@ TOOLBAR_LayoutToolbar(TOOLBAR_INFO *infoPtr) > if (btnPtr->fsState & TBSTATE_HIDDEN) > { > SetRectEmpty (&btnPtr->rect); > + TOOLBAR_TooltipSetRect(infoPtr, btnPtr); > continue; > } > Hi, Eric. What are symptoms of that? I'd guess it's causing tooltips to appear when they shouldn't, or tooltips from one button to appear for another. Do you have an demo application for that or any easy way to reproduce?

2 1

Re: qcap: Define O_CLOEXEC when needed
by Bruno Jesus 20 Feb '17

20 Feb '17

On Mon, Feb 20, 2017 at 7:28 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > https://bugs.winehq.org/show_bug.cgi?id=42478 > > dlls/qcap/v4l.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/dlls/qcap/v4l.c b/dlls/qcap/v4l.c > index d67df73..19c6f2e 100644 > --- a/dlls/qcap/v4l.c > +++ b/dlls/qcap/v4l.c > @@ -71,6 +71,10 @@ WINE_DEFAULT_DEBUG_CHANNEL(qcap_v4l); > > #ifdef VIDIOCMCAPTURE > > +#ifndef O_CLOEXEC > +#define O_CLOEXEC 2000000 > +#endif Hi, comparing to my fcntl.h the value should be octal: #define O_CLOEXEC 02000000 /* set close_on_exec */ But FreeBSD 10 defines like: #define O_CLOEXEC 0x00100000 02000000 = 524288 0x00100000 = 1048576 So I guess it is better to define as zero or #ifdef it out.

1 1

Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 19 February 2017 at 12:47, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -10746,7 +10746,8 @@ static void test_pointsize(void) > IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > > /* The following code tests point sprites with two textures, to see if each texture coordinate unit > - * generates texture coordinates for the point(result: Yes, it does) > + * generates texture coordinates for the point. Result: Yes, it does, except on some older hardware > + * (r500 and earlier, probably others). > * > * However, not all GL implementations support point sprites(they need GL_ARB_point_sprite), but there > * is no point sprite cap bit in d3d because native d3d software emulates point sprites. Until the > @@ -10802,6 +10803,11 @@ static void test_pointsize(void) > color = getPixelColor(device, 64-4, 64-4); > ok(color == 0x00ff0000, "pSprite: Pixel (64-4),(64-4) has color 0x%08x, expected 0x00ff0000\n", color); > color = getPixelColor(device, 64-4, 64+4); > + if (color == 0x00ff0000) > + { > + skip("Hardware generates point sprite coordinates on texture unit 0 only.\n"); > + goto cleanup_1tex; > + } > ok(color == 0x00000000, "pSprite: Pixel (64-4),(64+4) has color 0x%08x, expected 0x00000000\n", color); > color = getPixelColor(device, 64+4, 64+4); > ok(color == 0x0000ff00, "pSprite: Pixel (64+4),(64+4) has color 0x%08x, expected 0x0000ff00\n", color); This test has been around for a while, did it always fail? I also have the impression the hardware should be able to do this, does this fail on Linux, Windows, or both?

2 1

Re: [PATCH 1/2] ddraw/tests: Check pointer after CreateSurface without a descriptor.
by Stefan Dösinger 20 Feb '17

20 Feb '17

Am 2017-02-17 um 06:05 schrieb Alex Henrie: > dlls/ddraw/tests/dsurface.c | 10 ++++++++++ The rule is to not add new things to these old files, even if it is a minor obvious fix. If you want to change a test in there move it to tests/ddraw*.c (changing the code style, using the existing helper functions in the file, test all versions etc) and implement the change there. See e.g. http://source.winehq.org/patches/data/130355 . Yeah, it's a pesky work, but it needs to be done in the long run anyway.

3 3

Re: [PATCH 3/6] d3d8: Allocate WINED3DCAPS on stack.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 13:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d8/d3d8_private.h | 106 +++++++++++++++++++++++------------------------ > dlls/d3d8/device.c | 12 ++---- > dlls/d3d8/directx.c | 12 ++---- > 3 files changed, 61 insertions(+), 69 deletions(-) > Ideally we'd get rid of the macro as well.

1 0