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

Re: Fixing up the code style

by Martin Storsjö

On Thu, 13 Feb 2014, Stefan Dösinger wrote: > Martin, Michael or Sebastian: If you are reading this thread maybe you > can share your thoughts from the point of view of someone who isn't a > long-term contributor. I'll try to stay out of the rest of this discussion, but I can at least agree that it's hard to get the coding style right when all the surrounding code is consistently (more or less) in another style, and the pointed out "good style" example files don't use all features (cs.c didn't have any switch cases). // Martin

Feb. 13, 2014

Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks good, thanks! Wrt the testbot failures: It looks like CheckDeviceFormatConversion is in fact the right way to check this - I missed a sentence in the msdn page. I'll send a patch to handle this in this test and yuv_color_test. Real Windows drivers seem to agree with our interpretation of CheckDeviceFormatConversion. (Sorry if this mail arrives twice. I think my mail server swallowed the last one.) Am 2014-02-13 14:52, schrieb Martin Storsjo: > There are no public defines for the YV12 and NV12 > formats, although they do seem to be supported on > actual D3D on windows, at least on the one machine I > tested on. > --- > Removed unnecessary IDirect3DDevice9_SetFVF call. > --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/NuWAAoJEN0/YqbEcdMwg+0P/iXXzioHwCQuR4fQxmaZ0iQa FB/3kQd1E2Gn/k0sV9H+Uqb0s+C6g1/QSk11Q4+KaYjmAgcp7j2BJXi81wksInRV wLix2vEqENroLxoDbVVcjEyvlLBENnkCU88ixzK2IjzDuMGrDBNX6xnpDgE7UQIT ra5JiO6hnY2J6LN78QXomwgIQgtbTURhR+NwyXbYk6uYhWGu3+JoB24Ga0NnRH/p zfNXEWYgcrW05lBUCBEwu7+7XHHaYY45l8/p5o33JqiacYJIvFlwJ/H/Kpcc4bQ1 4yky4k/K2DEwpdlhBAzsGheqs5mAZ7xCYytFH+f1kNbDAfowN9M03wgFjfecPPJa 2UENwr0otG2/NdYyqD4FbfLUQZYnAcP4OdZ2lTIE/oZqlsN7T3d7xVhfzqDjRWP+ NhsCfKFTct+v0DWZpqp9Gcyi2aOJtoxuRFpaQIUHcKnEDD6PzBCLutVVERrhI3Gy 55+j7FfH9MfDT08+EOhK+4VXu74CdIgTUaR2Hm2nZFFw9q4Awh4Ixkd4RjjGFAWP RDnNzInSeaBKFYlwHhIxt5lnnVdIsJTkRvQi+j7g3j9YBMncE88YFWWw8wqkmPaE 9QfCvMCQZp7qmf9ak8A2PfCNDQv4jx4LEoJoNjgloLm8qQq0Yu+JYRpNjyvC6MJa pfw1CcMzFR626dZ9dOW2 =69kR -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: Fixing up the code style

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-13 14:57, schrieb Jacek Caban: > Well, another solution is to be less picky about coding style > during reviews. You gave me a perfect example just after writing > this mail: > > http://www.winehq.org/pipermail/wine-devel/2014-February/102864.html > > I'm mostly talking about the second comment. Seriously? Is that > worth a resend? Maybe, or maybe not. The basic issue still stands. New contributors will look at the existing code, and if its inconsistent how are they supposed to write code that's consistent in itself. That's not a question of pickiness but approach to the problem. Take a look at e.g. http://www.winehq.org/pipermail/wine-patches/2014-February/130297.html . It has plenty of inconsistencies, and none of them are the contributor's fault. Should we ignore that as well? If so, should we allow the codebase to look like that? My impression was that the answers to that were no and no, with the idea that the problem will be fixed by unifying the style together with other, functional changes. That way we end up with picky reviews and IMO that approach is bad. Martin, Michael or Sebastian: If you are reading this thread maybe you can share your thoughts from the point of view of someone who isn't a long-term contributor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/NWiAAoJEN0/YqbEcdMw0WAP/3pxrgE8BZhrFZtdVipd10Yv 8gwg9uB9fzWJfrcjiBoXiCUn7UHLKs3pmsAp/2VtwPVLC1mgAnNOH3uvKW94oz/3 w2jymggEuRr9Xu8CCAu/fcJmg3sLhu/OGM2edwmos5QS82R5oNs+92FStlw2aACM PMAV3Qgt1CLFFRIi/AH5bFHUqb3finphKWl4B2H50s3E3RSxJYkYN2Y8GsdqXdi7 xl/g/QbMWhICddjqbiLreSrRt1I92KIYizCpjK2yhWRlrpk/eDB1CjspsxS1j1+l H2dTLEq7+tL4I3tjoBQs9T/Inz5sgeor6satQqxJYzOaRr0GJrG7egzBId9pAmmP YpOxYr06MRmebDmVjRf388kL2bVZy6IA0dE7EM1dX0X6qJL8pTwjM6FfME10+ijO WVb1scOsTsS8SRSy2LvVmCo0UlUb2/EtADJct91i2nxI5Bdoge3131BBxOr6QIFg 4mywxT1+xPkrJAwVa8vs3R6gQZiNNIZ5Fe9/mP8LkgKTVCB5qMO12UY5a8QRacsf FnPpbVbI4hXxbkftqOTrFGUNUruEEJYLm2jX6fInZ6Jsx86Ix9Lwa1jtGujJIUkH Iki9EvZLX0Qh+BlI+0+A7csbypftbkT+b8WQG7NwXpIX8j38yrtJaFqEInCoHzDM KzyT7fE5o2u5QW3G/WtX =O2Cu -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: Fixing up the code style

by Henri Verbeet

On 13 February 2014 14:57, Jacek Caban <jacek(a)codeweavers.com> wrote: > often no clear answer if it's worth or not. However, my feeling is that > d3d reviewers tend to be way more picky about that than others and maybe > we could solve most of the problems on reviewers' side. I'm not quite sure where you got that impression, in the general case anyway. Personally, I'll point out style issues if the patch is going to need changes anyway, but I'm not going to ask somebody to redo a patch for style reasons alone, unless it's wildly inconsistent. For the record, I think this thread is a waste of time, and would otherwise have ignored it.

Feb. 13, 2014

Re: Fixing up the code style

by Jacek Caban

On 02/13/14 14:09, Stefan Dösinger wrote: > Hi, > > After recently helping two contributors (the Pipelight guys and Martin > Storsjö) through the maze of the Wine code style I think it's best to > lift the ban against style-only patches and unify the code style once > and for all. > > The basic reasoning is that from my point of view the lack of clarity > wrt the code style and lack of automatic enforceability is causing > more issues than the problems style-only patches cause with git blame. > Finding a style-only change with git blame can be handled by running > git blame again. Frustrating contributors on the other hand has no > workaround. > > So I propose to agree on a code style for the entire project, fixing > it up preferably with an automated tool and in the future enforcing > the style with checks in the Testbot. > > Opinions? Well, another solution is to be less picky about coding style during reviews. You gave me a perfect example just after writing this mail: http://www.winehq.org/pipermail/wine-devel/2014-February/102864.html I'm mostly talking about the second comment. Seriously? Is that worth a resend? I know it's often tempting to ask for code style change and there is often no clear answer if it's worth or not. However, my feeling is that d3d reviewers tend to be way more picky about that than others and maybe we could solve most of the problems on reviewers' side. Note that I'm not saying that no code style comments should be made, but those could be limited to cases that really make sense. > Wrt the code style I propose the style that is used in wineserver. It > is the same one as the new style in the d3d code except for > single-line if conditions. There is another problem with coding style than git blame... No, I don't want this style. I hate new lines for each opening bracket like: if(x) { x = 0; y = 1; } This makes the code almost 2 times longer than it needs to be for no good reason. If you need more space to make code cleaner, simply add a blank line where they are useful, not for every bracket. Let's use jscript style ;) Cheers, Jacek

Feb. 13, 2014

Re: [PATCHv4 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-13 14:25, schrieb Martin Storsjo: > + hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | > D3DFVF_TEX0); + ok(hr == D3D_OK, "IDirect3DDevice9_SetFVF > failed, hr = %#x.\n", hr); Another issue I missed: This call is not needed because you don't call DrawPrimitive and friends. I'll send a patch to clean up the same problems I pointed out here in yuv_color_test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/MzZAAoJEN0/YqbEcdMwZysQAIt75Q8zVg7KHGGuTDPPjq+G vtUI+xZryYVHSubEDG7uawf3L9n3QEdF6l5RIEEi7p40NPG9zf7P2eGGrIOoVpqY L5j1WAhnseHVO6e+vuB0/9M4RvSGHMzdTmzsdIz2/LiGgq3ui13semLC10NvybNy nmSNhU4umJAHR/Ize+3UHwgxOmyhyJvZ6I1ieMdprxmmC8LeOM+BAeY+hPZ6T671 jqwK64hRxCJVZdcqbHIV/0SAoFPoy9ndDZvcOe/a0FSqPQJGKCRWVDWd/JF2vH0p utAQcw9exQUga4F+0ds/60TMOVT87V+O4yyV81HeF+eYXR3U7W/IgvNPtvZW/HIM 0QMHYBEXKOLKXmqB2QONBC92l0TZcMZ3prXscexwpsOVMWyr6OHKYDBuo4Doc7av 3bPR9SGDY/V2wCJLIdjXZIWWO9C35JYDN2hrtyhAaCoIN2CBJDsqCPBbA4NcYFiy UOQB9QPExcK0f/Jg2Gqx1nbQ3lqMuCwOz8l3nv4Xwf/sJDbB2WXm6pllR/dmXppG DKx3G9/CrZkKukaSH93BNj9a1BDhIkNbA99CffJfuqH3qj7/QB9n4+VLDZQSB9E7 ykL4qXxXMZcUT47BtHS6wWV/QqRPtW3cG3/a0EUI03+WclYYt0V6KJX3izQEu6Fm XUUxgRjpsTexsjs6Hk/o =xV6C -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: [PATCHv3 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are two more style issues I missed in my previous reviews: > + static const struct > + { > + DWORD color1, color2; > + DWORD rgb1, rgb2; > + } > + test_data[] = > + { > + { 0x000000, 0xffffff, 0x00008800, 0x00ff7dff }, > + { 0xff0000, 0x00ffff, 0x004aff14, 0x00b800ee }, > + { 0x00ff00, 0xff00ff, 0x000024ee, 0x00ffe114 }, > + { 0x0000ff, 0xffff00, 0x00b80000, 0x004affff }, > + { 0xffff00, 0x0000ff, 0x004affff, 0x00b80000 }, > + { 0xff00ff, 0x00ff00, 0x00ffe114, 0x000024ee }, > + { 0x00ffff, 0xff0000, 0x00b800ee, 0x004aff14 }, > + { 0xffffff, 0x000000, 0x00ff7dff, 0x00008800 }, 4 space indents in the data block. > + DWORD color = (x < width/2 && y < height/2) ? test_data[i].color1 : test_data[i].color2; Please use spaces consistently around binary opertions. (i.e. x < width / 2) etc. I think I've also seen some multiplications that are affected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/MXbAAoJEN0/YqbEcdMwJjQP/2OzFt2DE5iEhWuwTOACdXSM 1dhlZnmz4bH+sUymen1dvxIXCLxhKWlLGl5cPkkFk2OCj0B2YlYaheV4qDJj5Cye zfKyrKjv1nfwk86g5YepoS2Ee/ZUdiMkNF+5tq9FkAa5LjStTgpC4KU6Vxpye1i5 Wmv2IBc0jAe84pRoDuZGYt0CT/RqgdHo8yvouK6Z5ytS7ClpLYWrLt/FYhpk0Sjj ITa6l7NksgBVN4ByZW5Pyk9Hf8gZ44qx9J8rzxOGBxLkGGpTOuGLB9MsE4riYwGy M1X10s7llWCs7Qy8Hs96Gg4vfHMS09xgfuYlj3UBKaXJVyRhTIDJpc7iqXA4WDaN mWJUrVaHCPha6ZGW2llC43wh5zECMH1/v98veRICbYqFhlKFzWuhtLq4BOwloJj4 fvJaYivFhkyDsn1y5grO8dGYjirZFNkiG/dIj7XpO8lh+4xGuTrBCO5hWBqICLV2 uQX6woh2MKv7ddFmRdvUuL/emV8oKBKga9t8LgTQdeSX7v//5aPtCLeawPKczpIB yPv2zUIei3G5TAcLlter66KGyvQZgXhiZXwtwq0wCWvNWRitjTztLp+2jrg9uWJ1 JiuhXuBFbsI8r/iiTrYXmZv1vX6BBFfL8I59SS0+J/7dFFZ63F5ePqEsl0WKSQ0W 0haQuTaKNLiVBlP1pmkF =fSNX -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: [PATCHv4 2/3] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks good to me. Am 2014-02-13 13:05, schrieb Martin Storsjo: > --- Fixed the final style issues and added comments about who > activates the GL context. --- dlls/wined3d/arb_program_shader.c | > 204 +++++++++++++++++++++++++------------- 1 file changed, 134 > insertions(+), 70 deletions(-) > > diff --git a/dlls/wined3d/arb_program_shader.c > b/dlls/wined3d/arb_program_shader.c index 93a6e31..a273eac 100644 > --- a/dlls/wined3d/arb_program_shader.c +++ > b/dlls/wined3d/arb_program_shader.c @@ -6768,22 +6768,74 @@ const > struct fragment_pipeline arbfp_fragment_pipeline = { > arbfp_fragmentstate_template, }; > > -struct arbfp_blit_priv { - GLenum yuy2_rect_shader, > yuy2_2d_shader; - GLenum uyvy_rect_shader, uyvy_2d_shader; - > GLenum yv12_rect_shader, yv12_2d_shader; - GLenum > nv12_rect_shader, nv12_2d_shader; - GLenum p8_rect_shader, > p8_2d_shader; +struct arbfp_blit_type +{ + enum complex_fixup > fixup; + GLenum textype; +}; + +struct arbfp_blit_desc +{ + > GLenum shader; + struct arbfp_blit_type type; + struct > wine_rb_entry entry; +}; + +struct arbfp_blit_priv +{ + struct > wine_rb_tree shaders; GLuint palette_texture; }; > > +static int arbfp_blit_type_compare(const void *key, const struct > wine_rb_entry *entry) +{ + const struct arbfp_blit_type *ka = > key; + const struct arbfp_blit_type *kb = > &WINE_RB_ENTRY_VALUE(entry, const struct arbfp_blit_desc, > entry)->type; + + if (ka->fixup != kb->fixup) + return > ka->fixup < kb->fixup ? -1 : 1; + if (ka->textype != > kb->textype) + return ka->textype < kb->textype ? -1 : 1; + > return 0; +} + +/* Context activation is done by the caller. */ > +static void arbfp_free_blit_shader(struct wine_rb_entry *entry, > void *context) +{ + const struct wined3d_gl_info *gl_info = > context; + struct arbfp_blit_desc *entry_arb = > WINE_RB_ENTRY_VALUE(entry, struct arbfp_blit_desc, entry); + + > GL_EXTCALL(glDeleteProgramsARB(1, &entry_arb->shader)); + > checkGLcall("glDeleteProgramsARB(1, &entry_arb->shader)"); + > HeapFree(GetProcessHeap(), 0, entry_arb); +} + +const struct > wine_rb_functions wined3d_arbfp_blit_rb_functions = +{ + > wined3d_rb_alloc, + wined3d_rb_realloc, + wined3d_rb_free, + > arbfp_blit_type_compare, +}; + static HRESULT > arbfp_blit_alloc(struct wined3d_device *device) { + struct > arbfp_blit_priv *priv; device->blit_priv = > HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct > arbfp_blit_priv)); if(!device->blit_priv) { ERR("Out of > memory\n"); return E_OUTOFMEMORY; } + priv = device->blit_priv; > + + if (wine_rb_init(&priv->shaders, > &wined3d_arbfp_blit_rb_functions) == -1) + { + > ERR("Failed to initialize rbtree.\n"); + > HeapFree(GetProcessHeap(), 0, device->blit_priv); + > device->blit_priv = NULL; + return E_OUTOFMEMORY; + } + > return WINED3D_OK; } > > @@ -6793,17 +6845,8 @@ static void arbfp_blit_free(struct > wined3d_device *device) const struct wined3d_gl_info *gl_info = > &device->adapter->gl_info; struct arbfp_blit_priv *priv = > device->blit_priv; > > - GL_EXTCALL(glDeleteProgramsARB(1, &priv->yuy2_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->yuy2_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->uyvy_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->uyvy_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->yv12_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->yv12_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->nv12_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->nv12_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->p8_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->p8_2d_shader)); - > checkGLcall("Delete yuv and p8 programs"); + > wine_rb_destroy(&priv->shaders, arbfp_free_blit_shader, > &device->adapter->gl_info); + checkGLcall("Delete blit > programs"); > > if (priv->palette_texture) gl_info->gl_ops.gl.p_glDeleteTextures(1, > &priv->palette_texture); @@ -7196,12 +7239,14 @@ static BOOL > gen_nv12_read(struct wined3d_shader_buffer *buffer, GLenum > textype, return TRUE; } > > +/* Context activation is done by the caller. */ static GLuint > gen_p8_shader(struct arbfp_blit_priv *priv, const struct > wined3d_gl_info *gl_info, GLenum textype) { GLenum shader; struct > wined3d_shader_buffer buffer; GLint pos; + struct > arbfp_blit_desc *desc; > > /* Shader header */ if (!shader_buffer_init(&buffer)) @@ -7249,14 > +7294,34 @@ static GLuint gen_p8_shader(struct arbfp_blit_priv > *priv, shader_arb_dump_program_source(buffer.buffer); } > > - if (textype == GL_TEXTURE_RECTANGLE_ARB) - > priv->p8_rect_shader = shader; - else - > priv->p8_2d_shader = shader; - shader_buffer_free(&buffer); > > + desc = HeapAlloc(GetProcessHeap(), 0, sizeof(*desc)); + if > (!desc) + { + ERR("Out of memory\n"); + goto > err_out; + } + + desc->type.textype = textype; + > desc->type.fixup = COMPLEX_FIXUP_P8; + desc->shader = shader; + > if (wine_rb_put(&priv->shaders, &desc->type, &desc->entry) == -1) + > { + ERR("Out of memory\n"); + goto err_out; + } + > return shader; + +err_out: + GL_EXTCALL(glDeleteProgramsARB(1, > &shader)); + checkGLcall("GL_EXTCALL(glDeleteProgramsARB(1, > &shader))"); + > GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)); + > checkGLcall("glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)"); + > if (desc) + HeapFree(GetProcessHeap(), 0, desc); + return > 0; } > > /* Context activation is done by the caller. */ @@ -7298,6 +7363,7 > @@ static GLuint gen_yuv_shader(struct arbfp_blit_priv *priv, const > struct wined3d_ struct wined3d_shader_buffer buffer; char > luminance_component; GLint pos; + struct arbfp_blit_desc *desc; > > /* Shader header */ if (!shader_buffer_init(&buffer)) @@ -7428,34 > +7494,32 @@ static GLuint gen_yuv_shader(struct arbfp_blit_priv > *priv, const struct wined3d_ > > shader_buffer_free(&buffer); > > - switch (yuv_fixup) + desc = HeapAlloc(GetProcessHeap(), 0, > sizeof(*desc)); + if (!desc) { - case > COMPLEX_FIXUP_YUY2: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) priv->yuy2_rect_shader = shader; - > else priv->yuy2_2d_shader = shader; - break; - - > case COMPLEX_FIXUP_UYVY: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) priv->uyvy_rect_shader = shader; - > else priv->uyvy_2d_shader = shader; - break; - - > case COMPLEX_FIXUP_YV12: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) priv->yv12_rect_shader = shader; - > else priv->yv12_2d_shader = shader; - break; + > ERR("Out of memory\n"); + goto err_out; + } > > - case COMPLEX_FIXUP_NV12: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) - priv->nv12_rect_shader = > shader; - else - priv->nv12_2d_shader = > shader; - break; - default: - > ERR("Unsupported complex fixup: %d\n", yuv_fixup); + > desc->type.textype = textype; + desc->type.fixup = yuv_fixup; + > desc->shader = shader; + if (wine_rb_put(&priv->shaders, > &desc->type, &desc->entry) == -1) + { + ERR("Out of > memory\n"); + goto err_out; } > > return shader; + +err_out: + GL_EXTCALL(glDeleteProgramsARB(1, > &shader)); + checkGLcall("GL_EXTCALL(glDeleteProgramsARB(1, > &shader))"); + > GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)); + > checkGLcall("glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)"); + > if (desc) + HeapFree(GetProcessHeap(), 0, desc); + return > 0; } > > /* Context activation is done by the caller. */ @@ -7467,6 +7531,8 > @@ static HRESULT arbfp_blit_set(void *blit_priv, struct > wined3d_context *context, enum complex_fixup fixup; const struct > wined3d_gl_info *gl_info = context->gl_info; GLenum textype = > surface->container->target; + struct wine_rb_entry *entry; + > struct arbfp_blit_type type; > > if (surface->flags & SFLAG_CONVERTED) { @@ -7487,39 +7553,37 @@ > static HRESULT arbfp_blit_set(void *blit_priv, struct > wined3d_context *context, > > fixup = get_complex_fixup(surface->resource.format->color_fixup); > > - switch(fixup) + type.fixup = fixup; + type.textype = > textype; + entry = wine_rb_get(&priv->shaders, &type); + if > (entry) { - case COMPLEX_FIXUP_YUY2: - shader = > textype == GL_TEXTURE_RECTANGLE_ARB ? priv->yuy2_rect_shader : > priv->yuy2_2d_shader; - break; - - case > COMPLEX_FIXUP_UYVY: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->uyvy_rect_shader : > priv->uyvy_2d_shader; - break; - - case > COMPLEX_FIXUP_YV12: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->yv12_rect_shader : > priv->yv12_2d_shader; - break; - - case > COMPLEX_FIXUP_NV12: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->nv12_rect_shader : > priv->nv12_2d_shader; - break; - - case > COMPLEX_FIXUP_P8: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->p8_rect_shader : > priv->p8_2d_shader; - if (!shader) shader = > gen_p8_shader(priv, gl_info, textype); + struct > arbfp_blit_desc *desc = WINE_RB_ENTRY_VALUE(entry, struct > arbfp_blit_desc, entry); + shader = desc->shader; + } + > else + { + switch (fixup) + { + case > COMPLEX_FIXUP_P8: + shader = gen_p8_shader(priv, > gl_info, textype); + break; > > - upload_palette(surface, context); - break; > + default: + shader = > gen_yuv_shader(priv, gl_info, fixup, textype); + > break; + } > > - default: + if (!shader) + { > FIXME("Unsupported complex fixup %#x, not setting a shader\n", > fixup); gl_info->gl_ops.gl.p_glEnable(textype); > checkGLcall("glEnable(textype)"); return E_NOTIMPL; + } } - > - if (!shader) shader = gen_yuv_shader(priv, gl_info, fixup, > textype); + if (fixup == COMPLEX_FIXUP_P8) + > upload_palette(surface, context); > > gl_info->gl_ops.gl.p_glEnable(GL_FRAGMENT_PROGRAM_ARB); > checkGLcall("glEnable(GL_FRAGMENT_PROGRAM_ARB)"); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/MUJAAoJEN0/YqbEcdMwJDEQAIEBkWRt2YIly+I+2jO2Y2al MxewjsCeQRf2uFnn4QIVNSfBOrjx6tq5d4aaj0pMlW2O98nXpVJWrHH5suqdX3IP F57tC6bLkucvwuutKFn+h5JohkHw7mjiPjDMYV2H2Lml3Yy0CXDfpSUJsREfTXgl YefKfzxIjckRV/u64kCTOxXCjkeI1LakEWIs8zL8QKXHSUIQtUHfN5uNynbhSnNq SU7+d3B/p/ZFvdOpT6HyhXHyGmx584CcmDTIz9tj6JG0oWmHE6dLZoIrgR/f32iH M0SYfxFEpRhv26a3NFEx98VAHTarZKkMTrcu6QQIgZ0RiC1jpSOvidk98sIK7dbr T+ynOho0GaZt5ZC0pvc1w6GPw7sf040Oz2JcSqIxDX+S5JjqG7PsMvJSYcziY8xJ eBrYgpO/Db5DVyOHfEuFbcS6fyLcO9P9hi2VvhQx2TR9q2XQEMklMamo+OTGng5t cx61mfvCLUF/BsQBteW/SAIHaUGfKgUOgmPIJpucssVbULVXnxI1op1PcczvT6JP xqaG+GiXzuDMulcQR+gnYz7oWnMWj2AA+bPVrTKUhZTbEupUgG9j8CsxeJ678tlk bBKK1p/3UBz1+oc7Qo+Yu6mBVSjPSxwczxmErWe+L7K1kP2L8vtqYg06CSTPH8t7 Y6kf6yuWGIbyapYMcuAO =jA/i -----END PGP SIGNATURE-----

Feb. 13, 2014

Fixing up the code style

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, After recently helping two contributors (the Pipelight guys and Martin Storsjö) through the maze of the Wine code style I think it's best to lift the ban against style-only patches and unify the code style once and for all. The basic reasoning is that from my point of view the lack of clarity wrt the code style and lack of automatic enforceability is causing more issues than the problems style-only patches cause with git blame. Finding a style-only change with git blame can be handled by running git blame again. Frustrating contributors on the other hand has no workaround. So I propose to agree on a code style for the entire project, fixing it up preferably with an automated tool and in the future enforcing the style with checks in the Testbot. Opinions? Wrt the code style I propose the style that is used in wineserver. It is the same one as the new style in the d3d code except for single-line if conditions. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJS/MQGAAoJEN0/YqbEcdMw7rMP+LAP5pnxyy9onITtJVe8swuy pKrS+U1NgLIru9yGuuxUsejUr8gY9hD27nSQQ2OddzSV3pEkY6vmqftSIFVT8Oli d0kEXbxZhlzRe9rCgEJGLGx73ap/LBOm0k3jtslOVONlIyH8AXdEG37a2P7s8SKV D9p0Sw7ggNRF8D0eIszSPKjfUfBYph+9XU1SDA9aEfokv6rs6AFt9xehCOUsdayZ gwqiigg70tkez81GhDRfuXWVn6pdsVpeLDjxF4P2XFMT00OInJIYBIy2w91sxgOs 3vos4X60+qg+sIGxAhxgfLilVQSbBOqvBz9QEUycOduzJK87sVfGtpsipCX4qW1Z QNE+SOINHjazNPB0mydO7s6rThOuZS2BU5nG+ZaXmbe5RBUXLMqqjUmIGL2ZYodJ zQ+3eOHC0H8fxaNhqwpRh5Gq8fVE+xcXauovLv0Ro+FskOitfazIBJEfktjJuXZ8 YZcmLqQAGCwd0Y9pTOTXldoR9ah1+gO7ya5n2ljR0+viAol6KQoUaD4dFNhEur4j cpmW2EDks/wPVrvjX2u8cphHGeOLSjDEErnE/PoX5w7jNarekRWSSalanYB+04SX rjxUXSVq30upNdJ07W2L8gLaHTgHq0rglR1ZrSYEDw5FtaG/Xs4W0YqyX5APl/+O Bj4qRaV70TNOicRNgaA= =DQdS -----END PGP SIGNATURE-----

Feb. 13, 2014

Converting source to unicode, bug 28189

by Hugh McMaster

I've put together a draft patch to address bug 28189, regsvr32: No usage in wineconsole. I'm using resource strings and have converted all of the printf calls to WriteConsoleW. I also converted the source to Unicode, but overall, there are few coding points I'm not quite sure about. If someone could look over the changes and offer some feedback, I'd certainly appreciate it. URL: http://bugs.winehq.org/show_bug.cgi?id=28189 -- Hugh

Feb. 13, 2014

Re: [PATCHv3 3/3] d3d9/tests: Add tests for different YUV texture layouts

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://newtestbot.winehq.org/JobDetails.pl?Key=4869 Your paranoid android. === w8 (32 bit visual) === visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xff7dff. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xb800ee. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xffe114. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x4affff. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x4affff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xb80000. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xb80000. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xffe114. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x24ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x24ee. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xb800ee. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x4aff14. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x4aff14. visual.c:10636: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xff7dff. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x8800. visual.c:10649: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x8800.

Feb. 13, 2014

Re: [PATCHv2 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Thu, 13 Feb 2014, Stefan Dösinger wrote: > You still have a few formatting issues in this patch, I've quoted the > ones I found below. The quotes seem to be missing, but I think I found the places you referred to. I'll resend the full set now. // Martin

Feb. 13, 2014

Re: [PATCHv3] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Two more non-functional nitpicks: Am 2014-02-13 11:16, schrieb Martin Storsjo: > +static void arbfp_free_blit_shader(struct wine_rb_entry *entry, void *context) > +{ > + const struct wined3d_gl_info *gl_info = context; > + struct arbfp_blit_desc *entry_arb = WINE_RB_ENTRY_VALUE(entry, struct arbfp_blit_desc, entry); > + > + GL_EXTCALL(glDeleteProgramsARB(1, &entry_arb->shader)); > + checkGLcall("glDeleteProgramsARB(1, &entry_arb->shader)"); > + HeapFree(GetProcessHeap(), 0, entry_arb); > +} Please add a comment /* Context activation is done by the caller. */ above the function. While you're at it, please also add it above gen_p8_shader. It is not necessary to add this comment above gen_planar_yuv_read and gen_nv12_read because those functions do not call OpenGL functions. > + switch (fixup) > + { > case COMPLEX_FIXUP_P8: > - shader = textype == GL_TEXTURE_RECTANGLE_ARB ? priv->p8_rect_shader : priv->p8_2d_shader; > - if (!shader) shader = gen_p8_shader(priv, gl_info, textype); > - > - upload_palette(surface, context); > + shader = gen_p8_shader(priv, gl_info, textype); > break; > > default: > + shader = gen_yuv_shader(priv, gl_info, fixup, textype); > + break; > + } Please add 4 spaces of indentation, like this switch (fixup) { case foo: code(); more_code(); break; case bar: other_code(); break; } Other than that the code looks good to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/K4ZAAoJEN0/YqbEcdMwHzoP/0/wPibZu3Jy3MAlACpiPlq9 0inM3Egyh/qfYw7Qi8I+2eaAYZKZYy9LZDJ89fXjS87Ip8v+ryoGMXpLeCGgGze4 VV7F/mr/V7OKHs6ObFipmO4pEgqYn6gbc5x87SCuHvEwz70CUOfZiTPzt94d71Z4 Hr69M6wSU4DNOndOr83pJNjEQAff9qIecvNZwp/xlvgg/rZSdr3uMBLap/fJmAGy NtbJVgIAtCovkANBTDmE55U8bPQLdRQapZbBH+JQN3LMxmg3C4pJ++Wnc/1kRmmv 3ZvVSBHdwTK7dPuLx7aGl66gMYo9IdyGUYvD+Jk2GchfhRowwC2FcWDhLEDRhWpd ahQnoa8bTuKgtlTwygWZLm748e8asaC1Chcr5pKj+IZDo/F/qq6U46LL9K5SBFC1 1sTjF578QQ3K5LiCrGv6ivsHvJq+JkwQz0QxDhqJ4Bs0lJ5LEvC54l7XjumDvtfg 8+4slUf/FKhZNjgp/XRF/qip1+hwMehZULlHIo0CBzSjBiNxxKA+IQq/CeKfjAMa cjPkhRW42H/l47IJthepxuMaoNO5WAp75TXha2vwHQY/Axs8AsKqyzTyImuMa50U b+kHVilfW9hjSJWSGbLb7JgCurgTMKHkt1W2+6OQpbFOBrCihr3uQWAifo8+IuTP 3U5Y0hUe8rU9IKyDS0eO =AU5Y -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: [PATCHv2 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You still have a few formatting issues in this patch, I've quoted the ones I found below. I ran the test on my Windows boxes and it passed on the following devices: Windows 7 x86_64, Radeon HD 5770 Windows 7 x86_64, Radeon X1600 Windows 7 x32, Nvidia GeForce 9600 Windows Vista x32, Nvidia GeForce 7400 It did not pass on my very ancient Windows XP x32 laptop with a Radeon 9000 Mobility. It fails there the same way as on the testbot - the card claims to support YUY2 and YV12, but the StretchRect call fails with D3DERR_INVALIDCALL. Do you have any idea why that might happen? If not maybe the best solution is to accept the error with broken() and skip the rest of the test. There's IDirect3D9::CheckDeviceFormatConversion, but according to msdn it only tests backbuffer and adapter format compatibility. That's not the way we implement it, but I don't think we have tests to find out how it's really supposed to behave. Fwiw none of the above machines claims I420 support. There are plenty of other odd formats though. Am 2014-02-12 21:05, schrieb Martin Storsjo: Use 8 space indentation vs the first line of the if and put the && into the next line. Same as above. Curly bracket placement. Same. 8 space indent on line contiuation as in if conditions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/KsdAAoJEN0/YqbEcdMwckoP/RTST4uApXJwApHZeP5DC7M9 9gN0k8G/zKFN/79I9RPC/fVhMbk/uniloVK+uuYwKmNsoFLRnT1ikg320D09KclZ R1+sLK3Cr9x8lR9NAbR/NsCglRupoE3qX916T1QVApWgeGb9WvExkto6rP+DhI8L sw5T/Rtr3odiMKdSXyllXNgZl0cljhd821OXn5bl6A1VpRO5tXJr7WFfMSIl5TUT VDOub/n2bPwKB38wUwxSgd+m/9hgl+4U+z4V1gfyichgVp4gZKSRH+mr96WI3trc eGjWxtH4+kk1LLshxjCaQOJ0fqoMDQbxJjUBtkAqSKYbCvd7KEfbcTcyKfd4mOHX ZgTqsMRlB/jVK2ugmojf2JgCasecDhENcibjOH2DHXe2SbUUx/QV7cFzjGEGiMNj fOBW0B/f1WJHuyYcKrpw1EWhsR4lFjM6uehmNC+ndA78zy5NPg15U6iBS0ArwZLN kSqbUd6VJy74zVs8CH/v6/cbjUhHguyYcO77/I7k9CMVV3rssgO2oV4GyOnfJGZg dLqN+mQGD3mZhhBhTZrqmuSK1BoPMgA89O7kbJB/x+l3f5XNuCmCxzK4ydgUsr11 kJ/gjrnc51/snAE61+qUZ7sxvGdJKqNdk19Xwrtjp7z2NIcJaNVT8qB41JJFrr4/ Woj0DvcYK1wrmPg8XSJ3 =Hogg -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: [PATCHv2 2/3] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-12 21:05, schrieb Martin Storsjo: > + entry = wine_rb_get(&priv->shaders, &type); > + if (entry) > { > - case COMPLEX_FIXUP_YUY2: > - shader = textype == GL_TEXTURE_RECTANGLE_ARB ? priv->yuy2_rect_shader : priv->yuy2_2d_shader; > ... > - break; > - > + struct arbfp_blit_desc *desc = WINE_RB_ENTRY_VALUE(entry, struct arbfp_blit_desc, entry); > + shader = desc->shader; > + } > + else > + { > + switch(fixup) > + { > case COMPLEX_FIXUP_P8: > - shader = textype == GL_TEXTURE_RECTANGLE_ARB ? priv->p8_rect_shader : priv->p8_2d_shader; > - if (!shader) shader = gen_p8_shader(priv, gl_info, textype); > ... > + } > } You'll have to execute upload_palette before running the p8 shader, not just when generating it. > struct arbfp_blit_priv { > - GLenum yuy2_rect_shader, yuy2_2d_shader; > - GLenum uyvy_rect_shader, uyvy_2d_shader; > - GLenum yv12_rect_shader, yv12_2d_shader; > - GLenum nv12_rect_shader, nv12_2d_shader; > - GLenum p8_rect_shader, p8_2d_shader; > + struct wine_rb_tree shaders; > GLuint palette_texture; > }; When you're resending the patch please take the opportunity to move the opening { to its own line. Otherwise the patch (and the first one) looks good to me. Thanks for your perseverance :-) . I'll run the test in patch 3 on my Windows machines and report back. I ran the earlier version it on the Radeon X1600 + Win7 box yesterday. It passed, NV12 was supported, I420 was not. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/JOCAAoJEN0/YqbEcdMwmCgP/2SeBnj9x5Nm3iWAQnqwEHs9 1ECpmmuCkbEcjOgxCrZEQWf7iv9RyrX3iEjyjqs5JJfpckOFEH51ydb+7JQpG/Q4 3+gLlXA1R5Qnku+Iz+gS6JW3aRSGIowlnbWTsggrqj71FzonFroy71z1NRsVmIQI f8SpgmtSVRSUoQ3b3K0Zc2zUb6+oaBsk55zRC8W37RejA73Alsc+C3vad+mFpMxQ xOtVkCyMqMGIxvb+llUygSMVf7oIT8AbAW0Yy6RMzS4FElG41HkCk1tTWI93v6b1 Aq064B6nZ7fkSqktwMpxdP8+xxQpuUUSWL4jA3ydq0UNoK7CrPQJlsP/ePtMBVkb 4yylQeVw+2Z2LbeDOJWbtLCQXVuJdvii1ULjlQciWSMvABmLy04pb8NqRAzvYfrL WL12mLfjKmA+9oylMbFll321vIXyoIyOBvSITLrEolAOUGU+xZu+pdIR8lVoyJpQ Djdu2zRmQnKIv3Q8zFQsdk201xKI9SqZScQHO68IwqqyNK5cyhIg91d7lFDlMFJx BihHAXW61O+fZfz1Q+SGWEztaFYYNZouBhFo0F7odjCHHGodNjVtLVJaa6N7fLHA rEek5LL+Uj2kzg4r+t3EnpSn+qhwZ3kOQYgyNqHlvY/m1MqvDRBp5Ln0RU0qtFHm rhaw1CZsViF5dlKEB72H =7Xyb -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: FOSDEM Videos - previews

by Marcus Meissner

Hi, I dropped the video guys at fosdem an email again. Its basically in their hands to reencode it again :( Ciao, Marcus On Wed, Feb 12, 2014 at 03:00:16PM -0800, Scott Ritchie wrote: > Are there currently watchable videos with working audio anywhere? > > On Thu, Feb 6, 2014 at 9:29 AM, Marcus Meissner <meissner(a)suse.de> wrote: > > Hi, > > > > The FOSDEM Video team is still processing our videos. > > > > But! Previews can be checked out at: > > > > http://video.fosdem.org/2014/previews/AW1120/2014-02-02/ > > > > > > They are basically in order of appearance. The filenames > > are UTC (so Bruessel - 1 hour). > > > > (timetable:) > > https://fosdem.org/2014/schedule/track/wine/ > > > > Notes: > > - We only got the master recording laptop around 9:10, > > so Alexandres keynote is mostly lost in time and space. > > > > I did not dare him to redo it for us ;) > > > > - I failed to select the +48V switch in fear of blowing > > up the microphone. > > > > So sound arrived at 42:20 in the Pipelight Talk after > > the audio angel helped us. > > > > Sound is only on the left side. > > > > - The presenter laptop->slave laptop firewire cable was broken, > > so it only started working for Rosannes talk. > > (Its also the reason her talk is cut into various pieces > > as we rebooted the machines inbetween.) > > > > - Talks after Rosannes are good. > > > > - As there were no BOF topics, the recording slot is empty. > > - We did not record the blame session. > > > > Ciao, Marcus > > > > >

Feb. 13, 2014

Re: Strange behavior from native OpenGL

by Roderick Colenbrander

Hi Ken, The problem you explain is indeed strange. I have never encountered this issue with opengl32 before. I tried to find a bug in the test, but didn't really see anything strange. If your theory about wglCreateContext being needed to 'heat things up' is true, maybe it has to do with ICD loading. Assuming you picked a pixel format, which requires the hw vendor's ICD, I believe wglCreateContext kicks of driver initialization unless it is done implicitly at an earlier stage (something happens for sure earlier for pixel format enumeration). Various ICD provided functions like the ICD version of wglGetProcAddress are loaded at time and I wouldn't be surprised if that is also when they hook up the ICD versions of MakeCurrent, CreateContext, SetPixelFormat, GetPixelFormat and others. Just a wild guess. Thanks, Roderick On Wed, Feb 12, 2014 at 6:46 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hi, > > I have been working on refining a d3d9 test patch I recently submitted < > http://source.winehq.org/patches/data/102263> and noticed a strange > behavior when running on a real Windows machine. I'm wondering if anybody > is familiar with it or can check my reasoning. > > The strange behavior is that a failed call to wglCreateContext() must be > done before SetPixelFormat() will work properly. The call to > wglCreateContext() has to fail because it can't succeed until > SetPixelFormat() has been done. And yet it still seems to be necessary. > > My test does the following sequence: > > CreateWindowA() > GetDC() > ChoosePixelFormat() > SetPixelFormat() > GetPixelFormat() > > This seems fairly simple, straightforward, and commonplace. Although > everything through the SetPixelFormat() indicates success, the > GetPixelFormat() call still returns 0. This causes the test to be skipped. > This happened on the testbot, but I assumed that was caused by the VM's > display driver. However, when I got the chance to try on a real Windows > machine, it happened there, too. > > I looked around to see if the same sort of thing is done elsewhere in > Wine. It's done in the opengl32 tests in test_setpixelformat() < > http://source.winehq.org/source/dlls/opengl32/tests/opengl.c#L254> and it > works there, both on the testbot and the Windows machine. > > So, then I figured it must be working in those tests because of stuff that > is done beforehand. I disabled most of the opengl32 tests other than > test_setpixelformat(). That was testbot job < > https://newtestbot.winehq.org/JobDetails.pl?Key=4751> and it still passed > on the testbot and real Windows. > > I then disabled the expected-to-fail call to wglCreateContext() that is > done in the test main entry function (START_TEST(opengl)). Once that is > disabled, test_setpixelformat() starts failing in the same way as my d3d9 > test. That is testbot job < > https://newtestbot.winehq.org/JobDetails.pl?Key=4752>. > > So, can it really be that a failed call to wglCreateContext() is necessary > before SetPixelFormat() will work properly? > > One thing that I haven't had the chance to test yet is whether a > wglCreateContext() call _after_ SetPixelFormat() will cause a subsequent > GetPixelFormat() to return the right format. That is, perhaps > SetPixelFormat() has worked and the pixel format is remembered, but it's > only "realized" once wglCreateContext() is called. And GetPixelFormat() > only returns realized pixel formats. > > Also, it's possible that it's sufficient to call any opengl32 function and > not wglCreateContext() specifically. (ChoosePixelFormat(), > SetPixelFormat(), and GetPixelFormat() are gdi32 functions.) > > In any case, that would mean that my d3d9 test will have to link with > opengl32 and call one of its functions. > > -Ken > > > >

Feb. 13, 2014

Re: dpnet: Improve Error checking in Get/Set SP (try 3)

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://newtestbot.winehq.org/JobDetails.pl?Key=4854 Your paranoid android. === w8 (32 bit address) === Timeout

Feb. 12, 2014

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2)

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://newtestbot.winehq.org/JobDetails.pl?Key=4853 Your paranoid android. === w8 (32 bit internet) === internet.c:203: Test failed: Got wrong error code 0 internet.c:690: Test failed: sz wrong, got 16, expected 14 or 30 internet.c:701: Test failed: cookie data wrong internet.c:1073: Test failed: GetLastError() = 0

Feb. 12, 2014

Re: [PATCH 3/3] ws2_32: Add an interactive test for interface change notifications (resend).

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://newtestbot.winehq.org/JobDetails.pl?Key=4848 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (b2c): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (654): unexpectedly at the OOB mark: 0

Feb. 12, 2014

Re: FOSDEM Videos - previews

by Scott Ritchie

Are there currently watchable videos with working audio anywhere? On Thu, Feb 6, 2014 at 9:29 AM, Marcus Meissner <meissner(a)suse.de> wrote: > Hi, > > The FOSDEM Video team is still processing our videos. > > But! Previews can be checked out at: > > http://video.fosdem.org/2014/previews/AW1120/2014-02-02/ > > > They are basically in order of appearance. The filenames > are UTC (so Bruessel - 1 hour). > > (timetable:) > https://fosdem.org/2014/schedule/track/wine/ > > Notes: > - We only got the master recording laptop around 9:10, > so Alexandres keynote is mostly lost in time and space. > > I did not dare him to redo it for us ;) > > - I failed to select the +48V switch in fear of blowing > up the microphone. > > So sound arrived at 42:20 in the Pipelight Talk after > the audio angel helped us. > > Sound is only on the left side. > > - The presenter laptop->slave laptop firewire cable was broken, > so it only started working for Rosannes talk. > (Its also the reason her talk is cut into various pieces > as we rebooted the machines inbetween.) > > - Talks after Rosannes are good. > > - As there were no BOF topics, the recording slot is empty. > - We did not record the blame session. > > Ciao, Marcus > >

Feb. 12, 2014

Re: [PATCH 1/3] ws2_32: Ask the server to process unsupported WSAIoctl operations (resend).

by Erich E. Hoover

On Wed, Feb 12, 2014 at 12:43 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > The returned size handling doesn't look right. Really sorry about that, that's my bad. I know at one point that I implemented that functionality but it looks like that code didn't survive a "git reset" :/ I'll resubmit with the appropriate fix here shortly. Best, Erich

Feb. 12, 2014

Re: d3d8/tests: Ignore broken CheckDeviceType() behavior on 64-bit Windows 8.

by Ken Thomases

On Feb 12, 2014, at 1:45 PM, Marvin wrote: > === w8 (32 bit device) === > device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. > device.c:3268: Test failed: Expected wndproc 0x4100c0, got 0x4100c0. Not related to my changes. -Ken

Feb. 12, 2014

Re: [PATCHv2 3/3] d3d9/tests: Add tests for different YUV texture layouts

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://newtestbot.winehq.org/JobDetails.pl?Key=4843 Your paranoid android. === w8 (32 bit visual) === visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xff7dff. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xb800ee. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xffe114. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x4affff. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0x4affff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0xb80000. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0xb80000. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xffe114. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x24ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x24ee. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xb800ee. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x4aff14. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x4aff14. visual.c:10628: Test failed: IDirect3DDevice9_StretchRect failed with 0x8876086c. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(0/4), pixel 80 60, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(0/4), pixel 240 60, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(0/4), pixel 400 60, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(0/4), pixel 560 60, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(1/4), pixel 80 180, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(1/4), pixel 240 180, expected 0xff7dff. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(1/4), pixel 400 180, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(1/4), pixel 560 180, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(2/4), pixel 80 300, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(2/4), pixel 240 300, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(2/4), pixel 400 300, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(2/4), pixel 560 300, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (0/4)/(3/4), pixel 80 420, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (1/4)/(3/4), pixel 240 420, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (2/4)/(3/4), pixel 400 420, expected 0x8800. visual.c:10641: Test failed: Format D3DFMT_YUY2: Got color 0 for pixel (3/4)/(3/4), pixel 560 420, expected 0x8800.

Feb. 12, 2014

Re: d3d8/tests: Ignore broken CheckDeviceType() behavior on 64-bit Windows 8.

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://newtestbot.winehq.org/JobDetails.pl?Key=4841 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3268: Test failed: Expected wndproc 0x4100c0, got 0x4100c0.

Feb. 12, 2014

Re: [PATCH 1/3] ws2_32: Ask the server to process unsupported WSAIoctl operations (resend).

by Alexandre Julliard

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > @@ -4101,11 +4125,29 @@ INT WINAPI WSAIoctl(SOCKET s, DWORD code, LPVOID in_buff, DWORD in_size, LPVOID > WSASetLastError(WSAEOPNOTSUPP); > return SOCKET_ERROR; > default: > - FIXME("unsupported WS_IOCTL cmd (%s)\n", debugstr_wsaioctl(code)); > status = WSAEOPNOTSUPP; > break; > } > > + if (status == WSAEOPNOTSUPP) > + { > + status = server_ioctl_sock(s, code, in_buff, in_size, out_buff, out_size, ret_size, > + overlapped, completion); > + if (status != WSAEOPNOTSUPP) > + { > + if (status == 0 || status == WSA_IO_PENDING) > + TRACE("-> %s request\n", debugstr_wsaioctl(code)); > + else > + ERR("-> %s request failed with status 0x%x\n", debugstr_wsaioctl(code), status); > + > + /* overlapped and completion operations will be handled by the server */ > + completion = NULL; > + overlapped = NULL; > + } > + else > + FIXME("unsupported WS_IOCTL cmd (%s)\n", debugstr_wsaioctl(code)); > + } The returned size handling doesn't look right. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2014

Re: ddraw/tests: Skip the primary palette tests if the 640x480x8 mode is not supported.

by Francois Gouget

On Wed, 12 Feb 2014, Henri Verbeet wrote: > On 12 February 2014 10:28, Francois Gouget <fgouget(a)codeweavers.com> wrote: > > hr = IDirectDraw_SetDisplayMode(ddraw, 640, 480, 8); > > + if (hr == E_NOTIMPL) > > + { > > + win_skip("8bpp display mode is not supported\n"); > > + DestroyWindow(window); > > + return; > > + } > Is this for the Win 8 testbot? Unsupported display modes should return > DDERR_UNSUPPORTED, and 640x480 at 8 bpp should pretty much always be > supported. Does changing display modes work at all on that VM? IIRC it > had more issues with changing display modes, and not just in the ddraw > tests. My Windows 8.1 laptop (Intel HD4000) also returns E_NOTIMPL for these tests (among other errors). Fixing this crash does reveal other errors. ddraw:ddraw1 start dlls/ddraw/tests/ddraw1.c - ddraw1.c:1329: Test failed: Expected color 0x000000ff for test 0, got 0x00ff0000. ddraw1.c:1329: Test failed: Expected color 0x000000ff for test 1, got 0x00ff0000. ddraw1.c:3949: Test failed: Got unexpected color 0x000000ff. ddraw1.c:3982: Test failed: Got unexpected color 0x000000ff. ddraw1.c:3995: Test failed: Got unexpected color 0x00ff0000. ddraw1.c:4081: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:4106: Test failed: Failed to set palette, hr 0x88760091. ddraw1.c:4108: Test failed: Got unexpected refcount 1. ddraw1.c:4112: Test failed: Got unexpected palette caps 0x44. ddraw1.c:4116: Test failed: Failed to set palette, hr 0x8876023c. ddraw1.c:4125: Test failed: Failed to set palette, hr 0x88760091. ddraw1.c:4127: Test failed: Got unexpected refcount 1. ddraw1.c:4130: Test failed: Failed to get palette, hr 0x8876023c. ddraw1.c:4131: Test failed: Got unexpected palette 00000000, expected 006542E8. ddraw1.c:4131: this is the last test seen before the exception ddraw1: unhandled exception c0000005 at 00410079 ddraw:ddraw1 done (-1073741819) in 29s ddraw:ddraw2 start dlls/ddraw/tests/ddraw2.c - ddraw2.c:1583: Test failed: Expected color 0x000000ff for test 0, got 0x00ff0000. ddraw2.c:1583: Test failed: Expected color 0x000000ff for test 1, got 0x00ff0000. ddraw2.c:4630: Test failed: Got unexpected color 0x000000ff. ddraw2.c:4663: Test failed: Got unexpected color 0x000000ff. ddraw2.c:4676: Test failed: Got unexpected color 0x00ff0000. ddraw2.c:5178: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:5203: Test failed: Failed to set palette, hr 0x88760091. ddraw2.c:5205: Test failed: Got unexpected refcount 1. ddraw2.c:5209: Test failed: Got unexpected palette caps 0x44. ddraw2.c:5213: Test failed: Failed to set palette, hr 0x8876023c. ddraw2.c:5222: Test failed: Failed to set palette, hr 0x88760091. ddraw2.c:5224: Test failed: Got unexpected refcount 1. ddraw2.c:5227: Test failed: Failed to get palette, hr 0x8876023c. ddraw2.c:5228: Test failed: Got unexpected palette 00000000, expected 0092BF68. ddraw2.c:5228: this is the last test seen before the exception ddraw2: unhandled exception c0000005 at 0041EA0D ddraw:ddraw2 done (-1073741819) in 35s ddraw:ddraw4 start dlls/ddraw/tests/ddraw4.c - ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 400,60, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 560,60, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 400,180, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 560,180, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 80,300, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 240,300, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 400,300, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 560,300, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 80,420, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 240,420, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 400,420, got 0x00ff0000. ddraw4.c:1216: Test failed: Expected color 0x0000ff00 at 560,420, got 0x00ff0000. ddraw4.c:1721: Test failed: Expected color 0x000000ff for test 0, got 0x00ff0000. ddraw4.c:1721: Test failed: Expected color 0x000000ff for test 1, got 0x00ff0000. ddraw4.c:5233: Test failed: Got unexpected color 0x000000ff. ddraw4.c:5266: Test failed: Got unexpected color 0x000000ff. ddraw4.c:5279: Test failed: Got unexpected color 0x00ff0000. ddraw4.c:5774: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:5799: Test failed: Failed to set palette, hr 0x88760091. ddraw4.c:5801: Test failed: Got unexpected refcount 1. ddraw4.c:5805: Test failed: Got unexpected palette caps 0x44. ddraw4.c:5809: Test failed: Failed to set palette, hr 0x8876023c. ddraw4.c:5818: Test failed: Failed to set palette, hr 0x88760091. ddraw4.c:5820: Test failed: Got unexpected refcount 1. ddraw4.c:5823: Test failed: Failed to get palette, hr 0x8876023c. ddraw4.c:5824: Test failed: Got unexpected palette 00000000, expected 008ED930. ddraw4.c:5824: this is the last test seen before the exception ddraw4: unhandled exception c0000005 at 00445764 ddraw:ddraw4 done (-1073741819) in 34s -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

Feb. 12, 2014

Re: [PATCH 5/6] wined3d: Add support for I420 textures

by Martin Storsjö

On Wed, 12 Feb 2014, Henri Verbeet wrote: > On 12 February 2014 16:50, Martin Storsjö <martin(a)martin.st> wrote: >> I can easily change the above mentioned test app to use I420, which works >> both on the physical windows machine and in wine with this patch, but I >> can't name any other app off-hand which would use this format. So if you >> prefer to hold off adding support for this format until there's a concrete >> need, I can drop this one. >> > Just for what it's worth, I420 appears to be unsupported on my Win 7 > test machine with AMD GPU. Right - FWIW the machine where it was supported was a Samsung Np940x3g-k03se with Windows 8.1. Anyway, I guess that's another reason to drop this patch for now until there's some actual need for it. // Martin

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-02-11 12:14, schrieb Martin Storsjo: >> + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL); >> + ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr); > Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code. Indeed, I changed the texture size later yesterday (and removed the hardcoded numbers by making the width/height a local variable); will check that capability. > There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this. Yeah, it's probably not worth worrying about that case. >> + memset(&lr, 0, sizeof(lr)); >> + hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0); >> + ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr); > There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds. Ok - this was an artifact from the existing yuv_color test FWIW. >> + /* Draw the top left quarter of the screen with color1, the rest with color2 */ >> + for (y = 0; y < 8; y++) >> + { >> + for (x = 0; x < 8; x += 2) >> + { >> + DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2; >> + BYTE Y = (color >> 16) & 0xff; > It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on. I guess it would make things a little bit more difficult when the output is filtered. As long as we calculate how to hit the center of the pixels correctly I guess it should work, but I went the easy route and just draw the top-left quarter of the screen in one color and the rest in another, and sample at four points near the corners of each quadrant. Handling the individual two different Y values in UYVY/YUY2 is already tested in the yuv_color test anyway, and for the other pixel formats there isn't really any distinction between first/second Y samples. I'll fix up the other style issues you pointed out and resend the set later today then. // Martin

Feb. 12, 2014

Re: [PATCH 5/6] wined3d: Add support for I420 textures

by Henri Verbeet

On 12 February 2014 16:50, Martin Storsjö <martin(a)martin.st> wrote: > I can easily change the above mentioned test app to use I420, which works > both on the physical windows machine and in wine with this patch, but I > can't name any other app off-hand which would use this format. So if you > prefer to hold off adding support for this format until there's a concrete > need, I can drop this one. > Just for what it's worth, I420 appears to be unsupported on my Win 7 test machine with AMD GPU.

Feb. 12, 2014

Re: [PATCH 5/6] wined3d: Add support for I420 textures

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > Am 2014-02-11 12:14, schrieb Martin Storsjo: >> I420 is similar to YV12, but the chroma planes are swapped. > Do you have an application that uses this? Just making sure we're not > adding dead code here. Actually I don't. I first ran into this area with the OpenH264 test decoding application, which currently uses NV12 textures. Once I started adding support for that to wine, I also tested what other common YUV pixel formats actual hardware supports (I tested on a friend's physical windows machine), which wine doesn't, and found that the real windows machine also supported I420 but not e.g. NV21, in addition to YV12, UYVY and YUY2 which already were supported. I can easily change the above mentioned test app to use I420, which works both on the physical windows machine and in wine with this patch, but I can't name any other app off-hand which would use this format. So if you prefer to hold off adding support for this format until there's a concrete need, I can drop this one. // Martin

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 12:14, schrieb Martin Storsjo: > + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL); > + ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr); Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code. There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this. > + memset(&lr, 0, sizeof(lr)); > + hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0); > + ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr); There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds. > + switch (format) > + { > + case D3DFMT_YV12: v_buf = chroma_buf; u_buf = chroma_buf + 4 * lr.Pitch/2; break; > + case D3DFMT_I420: u_buf = chroma_buf; v_buf = chroma_buf + 4 * lr.Pitch/2; break; > + default: break; > + } The switch causes a warning here because YV12 and I420 are not part of the D3DFORMAT enum. Please use an if to make the compiler happy. Set v_buf and u_buf to NULL in case of other formats - this should avoid the warning that they may be uninitialized. (Although I think the compiler is broken here. It should see that they're not used for formats that are not YV12 and I420.) > + /* Draw the top left quarter of the screen with color1, the rest with color2 */ > + for (y = 0; y < 8; y++) > + { > + for (x = 0; x < 8; x += 2) > + { > + DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2; > + BYTE Y = (color >> 16) & 0xff; It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on. > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0); No need to clear the Z buffer. > + ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with 0x%08x\n", hr); Please use %#x instead of 0x%08x and add interpunctuation at the end of the ok message. Another set of unwritten style rules :-\ . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+5B8AAoJEN0/YqbEcdMwgLUP/19EoAQNiOg0JTdAHco28fTm zfSqZtMTv7JJAtznqt5EilK2gb33/oiyMXZcotg6YevJWRFrVQQw9K3b+JepxY4O l8ZBas9GGEAoTppb4W03w7Ngzr5J4yBBSXpVoEQDnmztywzZqcpaQc4y1/ukkkgg lN7HIPP3tychxk3IBiQtgVQ/U+xC6BmEgWdNClDBBpMnGkKbLERLjxpkOPi7fs1f FPOCW7P18BDLANw/FMipEqDsm+K/EOdVFBU4wcIWB7BOavZzwGRaKDFdifhwq2VR CBvm3uT6drct5put/JF/RIfnY5Za7GOIi5Ks4P0Gwt/e6xQ3WK+LrsEAASottF0O IUskCxGIKB/P7CsxtwGjTg9gDOm35W+4g0QiMvBoJk8dO2eggPXdNdmAR+5ZI/ez wxZzAl9m8VnXe0xeUSMha44n7F3EJ8Bz7F/Sixc6v8G6pmVdJNK9LM8+ZqD4muWQ cnZNKWLMeWaufb3KEVno0F2SUFhGb7q/FHBCInaz9EKOG5yMEEzNbHYMh3v/oJ9s IWXJgavdbIfUbj1YGulasKqlNzHzKnL+V2oMaqT+rGxypAcVentxIbV/bFseN091 b6oc8bL9KIKEHpWtPKqXYJ3wZBb2dKbcFhmd2VDNrWQSOTI5ZeU5xUnfsXeIthqo ntdGlkDSfAJlSMvzZOyh =m68B -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 5/6] wined3d: Add support for I420 textures

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 12:14, schrieb Martin Storsjo: > I420 is similar to YV12, but the chroma planes are swapped. Do you have an application that uses this? Just making sure we're not adding dead code here. Otherwise this looks good, but patch 3 needs fixes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4lrAAoJEN0/YqbEcdMwDjUP/1mawzD6WIoBsR/eFxSDu2SZ yE4AHd/HaUkYwYan6CjiYAV8uf3ikUIGHQhvyF79jKikRWUCGHRoQTL8xwx6wcXm fCIQjPuuwpizEpdGjD+mZHWMgg+RtgbYrJbSX8pWtRfcRQsVxtB8Q5tXyVtZGwWr vBtmeQUlaIBlSH8hG5ZC0UGsljP/hwV/LayeYmAKFRTccX/PFKTM1cua5AznPrxQ noEW9kYxpilWDPwvNWsic7e6FCYTHxMGZblVC5FSMxSq/66CAYUakD1iRc4xomw7 9jk0UQ308LKTzw7m86HfvnuqvIHprhZcn1IHwDWAmGxsQD+e+4uJ8XBwAKA575Sm RUQMDZdXzsxmBkZIYGDs7WNI03v6rEsGaM3KoHuurfhmc7XaCjzla0W3Y0yLgN4P 9+7WHzBZ8CyYDBHsNKNkFpXEwQuSzAbzr+nt8/8RhrwHyIa2RX26xCe91+6MYKkc trwK1inGiB3CBvzEha/YQuGzeyzTp8oV6yhGnGpf5tPJlRtzxc8IpHmWXCdwrk6z 3AAxUliwm4cYTPgrY2zAXHc/0rTULQ+3GCUb3pWGgdKCDzmyWsPaZ5TY0XmBGvIH R9JrC39ku/Md33+oWCKF4tpwzJ1go6eWnbBu/mPKStpoTaIi708H/vrTCmL/dHCp aYOYafddUXk5NKEcS91m =dZNW -----END PGP SIGNATURE-----

Feb. 12, 2014

Strange behavior from native OpenGL

by Ken Thomases

Hi, I have been working on refining a d3d9 test patch I recently submitted <http://source.winehq.org/patches/data/102263> and noticed a strange behavior when running on a real Windows machine. I'm wondering if anybody is familiar with it or can check my reasoning. The strange behavior is that a failed call to wglCreateContext() must be done before SetPixelFormat() will work properly. The call to wglCreateContext() has to fail because it can't succeed until SetPixelFormat() has been done. And yet it still seems to be necessary. My test does the following sequence: CreateWindowA() GetDC() ChoosePixelFormat() SetPixelFormat() GetPixelFormat() This seems fairly simple, straightforward, and commonplace. Although everything through the SetPixelFormat() indicates success, the GetPixelFormat() call still returns 0. This causes the test to be skipped. This happened on the testbot, but I assumed that was caused by the VM's display driver. However, when I got the chance to try on a real Windows machine, it happened there, too. I looked around to see if the same sort of thing is done elsewhere in Wine. It's done in the opengl32 tests in test_setpixelformat() <http://source.winehq.org/source/dlls/opengl32/tests/opengl.c#L254> and it works there, both on the testbot and the Windows machine. So, then I figured it must be working in those tests because of stuff that is done beforehand. I disabled most of the opengl32 tests other than test_setpixelformat(). That was testbot job <https://newtestbot.winehq.org/JobDetails.pl?Key=4751> and it still passed on the testbot and real Windows. I then disabled the expected-to-fail call to wglCreateContext() that is done in the test main entry function (START_TEST(opengl)). Once that is disabled, test_setpixelformat() starts failing in the same way as my d3d9 test. That is testbot job <https://newtestbot.winehq.org/JobDetails.pl?Key=4752>. So, can it really be that a failed call to wglCreateContext() is necessary before SetPixelFormat() will work properly? One thing that I haven't had the chance to test yet is whether a wglCreateContext() call _after_ SetPixelFormat() will cause a subsequent GetPixelFormat() to return the right format. That is, perhaps SetPixelFormat() has worked and the pixel format is remembered, but it's only "realized" once wglCreateContext() is called. And GetPixelFormat() only returns realized pixel formats. Also, it's possible that it's sufficient to call any opengl32 function and not wglCreateContext() specifically. (ChoosePixelFormat(), SetPixelFormat(), and GetPixelFormat() are gdi32 functions.) In any case, that would mean that my d3d9 test will have to link with opengl32 and call one of its functions. -Ken

Feb. 12, 2014

Re: [PATCH 4/6] wined3d: Fix the YV12 illustration

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 12:14, schrieb Martin Storsjo: > The comment in the description further above is correct, that the > chroma planes are ordered V, then U, while the illustration had > them swapped. This patch looks correct to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4czAAoJEN0/YqbEcdMwKx8P/1J1flCobX1Z3XHptyIlEuyC gVt1OwxjQ2ayx5WwTtO8wlY//h+167HE4Ip7KFxk3QR21PKO/kvmhImmjVr2oUdm t8ZDh3q3158qSu1USNvKfTzLaBpXbXQNs10XIgvj2olHw80+CW0ZodPONAls94dU YHVAmYataxvTMkM/EXooBVJkJdF0qy80pkAcQLpN+wwpw+xZXwXq0901bm2u2LJn XuN9UDS9lViR2NRSNUkHhJKNKJiy72U6RXnKsjao83IES27zFKCpaJx8UeyvRCQY ZGCREFf4Xw9ge+Bi2tA5zfCeClVVZ5ds2gSbTvGmy7DAcjYCG4z7iYwWaUOWduH/ OGW9ASPdqvRTELjqB40x1hvtdhhFFjC2PI+UbS1ltiIpgHUQn2FZcG9qsOh1QaDt ddtyOc1cKazeE4iFFdDfNy9cJTg8n0bKAEFAfj/tUsKJjoDfbOyF0xeEsECs6MVt ayaEWUduLTD/hHq7kA/U8vzGmucJ7Ng7XvypLu3vKbH76f63e4nuUWfc8K2VpAXK SRoLvhePgmUkXkus+Y3l3ttAvN/y+HhKZiNvFIxQKUfZ07mg4gqhM1DzwO0/9Gdt byo+Nu0bK9arSyJUCi7Ah+fcBvJUCAvt47xQ1AnUvv2/2sOUfWcPxSERX4WLFPRG /RSNua7b9MRvibHxXC1G =rFkd -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH v2 1/6] wined3d: Add support for NV12 textures

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again! I have some more format nitpicks below. As far as the big picture is concerned there is also a software conversion path in dlls/wined3d/surface.c. Search the file for d3dfmt_converter_desc and you should find the right place. You don't have to submit a patch for that unless you know an application that needs it though; I'm just making you aware of it. Am 2014-02-11 12:14, schrieb Martin Storsjo: > + switch(textype) You're missing a space here. As far as I can see the other places in this patch are correct, but it doesn't hurt to double-check with grep or something. (I really hope the testbot can one day take care of this...) > + case GL_TEXTURE_2D: tex = "2D"; break; Please make this case GL_TEXTURE_2D: tex = "2D"; break; etc > + * When reading from rectangle textures, keep in mind that > the input y coordinates + * go from 0 to d3d_height, whereas > the opengl texture height is 1.5 * d3d_height + */ Comment closing should go next to the last line of text. Also add proper interpunctuation at the last sentence of a comment. This applies to a few more places in this patch, and most likely the other patches. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4aPAAoJEN0/YqbEcdMwCXMQAIPeaYbrI+zC2zf6KlOdOCbe yDSbSvRS4vZWkukemQCb6jr2qFCjqoCJMHj1GpfWxlBxJ1+rOWyTdc+YG2DDzCqk YE3K8PgOaID7BnopA/Ri0gYiwRz7K2WBpMWMwgeVnjTFOUWJ8tYt1z4VmCHXgEEi JDphv1q9IDzCW/s3Pu68VtDrE4rsG/KLietRPTCgakdjX1oLvlKn1Fg5D7q78y87 szJg2SRaYOVWSXIK2D+s+A5Tvjr9gffSsDE6fgFgxeFyHsViGyq6QDJEBxCO+f+A UZ1FhidcogIt/sqSphg7lCyEUw49WojlXSXhLpdofwjrR/4griYgp21h6Y8UhtqG LzPUVGBfScvb208bIhL+LvCukQ00WnTI4LJA6khjL9AlCnrzh4nrhVo6RQDrL1A3 6V5gJLd1ZT4DepQc2XQLC0FupgYWafIJAzCcpZIpvQRjzH4MqJgeJC9m6alRzyWr TkN+Jo6yKRk2t+x7LOzee+mMPAfIT2OcHoIlG60Z8ZxK3Apu6k7/RPoqi1BWdJZZ gHA1CZLUDC+UXhPhr2pxNy4AQnD2EbIBp5GPKNHHvoqJJzXvbHPBx5TgOOaEyLnH idubGx+GLf3zXEaK+ujbMg8Ae/poGh841gBVbMLDqZguSkuTsVGpt8hjCZgWq+5d u177zpoEIMhOFIK17nSY =IHTQ -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-12 15:05, schrieb Martin Storsjö: > Anyway, I'll resend my patchset with the last fixes from > yesterday. Before you do I'll have a closer look at the stuff I didn't look at yesterday. It shouldn't take long... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4K8AAoJEN0/YqbEcdMw7VwP/R4pK5DjZ6Edi4kuwU4+PFty r8y6bsNih1pdedxpU4hMFsWRSqv1ZTlpth7vQ48tQIsDaBaw7kI509g94twmAhiB XFwQxIuefiZdd0BiHt/kS9354vZ3ftpCcrjI51DRERyTHl0EPnTMtKNRpLNPeDg2 W2k/oFJpOjqDTqucqeqdj7r52ORaIXy29DqJhfRoho0rQNLFOoGAgSsB48ZggWqo PhGQZPQKFuCMXCdjsLrMv9nq2eIMgS4j+wy5BJISGjqZzVWjzEZ4uweCeb1GO8BL aQwbUmNPxwQD+C5ElIYSX1dhpailinplr0wCITn0MkDHdGXwWP/Z9G8o2Iv3zFRF 9iBIU1xGJkg7gkK1jI2oyONb/v+qJtUqAf4Pys4zoTUxEzTE7Jpuytm/u6PQOVW8 3X4rEK56YQrzWrlP9vNRwWj1BixUiEfGawL28qjBa66xWpLvZxROK0lckA72Si6X XU7LwGGNFh6YkKCSvZHli3/RGTjfKaYF0asCiUqlfyAHuXhtNYe2pth5cEf+S1zR xH/m0xMBP97me3HgxMYbCcPTCueZVdr4o7sje1kRzmaM1+2t8NKSuKzbzLdqlio+ yxBBAnmvuFzXF7ZyNLGQZ7RFkvl1XB5vAFzhFkcfdz2Q6cUNikLv8hSEbnRPZLpI n+zzBnN4VvZa7FfsXldK =EPpG -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-12 15:05, schrieb Martin Storsjö: > I didn't really test my test properly on windows yet - how hard is > it on a scale to compile and run them there? It's not all that hard. You have 3 options: Install mingw on your linux system to cross-compile the tests with make crosstest. I've installed i686-w64-mingw32-gcc for 32 bit compiles and x86_64-pc-mingw32-gcc for 64 bit ones with Gentoo's tools. (I should probably switch the 64 bit one to mingw-w64 as well...) The other option is to install mingw and msys on Windows and compile it there. That's a bit trickier. The third option is to create an account at testbot.winehq.org. It'll allow you to upload patches and give you a cross-compiled .exe. Actually, there's a fourth option: I have a hacky visual studio build system for the d3d parts of Wine. Tell me if you're interested and I'll write more instructions. You'll need msvc 2013 and it will most likely not work out of the box. > I only tested it briefly (by ripping out the relevant parts from > visual.c and compiling that as a standalone C file without the wine > test framework) on windows so far, on a VMware VM with XP, and the > direct3d driver there doesn't support either NV12, YV12 nor I420, > only UYVY/YUY2 (this is actually my original reason for trying > anything of this in wine). Ok, I'll run your tests on my Windows boxes then. I've plenty of them for this purpose... > The D3D rendering did seem to filter the texture when stretching > though, but I chose sampling points within it that should resolve > to the right color despite that. That seems to be a common problem with YUV stretchrect. I'm using the same workaround in the YUY2 / UYVY tests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4HmAAoJEN0/YqbEcdMwSi4P/0hwyFkF298blerxDwl53km+ TIL82HBqlBV/JtOWDzIod+XnXUsEGDuz+mbRcDhmEbvEgEjtU0ziO+wT8MaQu14x YqfSLww1eURQGXcEpTOHmG8CVxbGrIu9CUF/DhfQEbAK34PQvGRUTt23R7DlWmII HzgXolMTGhIs387sqb7sTutECxsRVMAedhuO+eN4iaPKz9OFH+zoIUVeHiDn/2Kh 5hriL6L8f+y9tU7GUST0eiKbBPX74tooHeLKQtYh8rPkZQonXXVSIGMbzrYGGnaz hWkC9tZ122QhrqnJio3t5aPUWPWZ34Y/mxCTA0chmGOAw0bbDXLn+VRpFGHIIbX/ oWF9spjhyO3u0dBbMSfvEnQtU2vdp3cHu6TyQ2ObLiNHESdGq+t4HPo19hhmohOO cNiRqWDzfO5NizVDgyTyoHxq0IpVXWy/czaZ0KHI7fBlixj77/doQGj5+l70Lmxp KTnnzR1UpOoQnZL9YsnGy8VlzUU0gdMOHTnhZ7FIA+LI2VpeuPvRcCd/Awbxdyni SAIrnGDP2b14+M/Vxj092/VFNAQojUlyjfg7Y5lGkFs6tuhLUF+E9Hn7mPjAgYmo qLKZ/k3XwwBRzMEz1Wm5NVFEmmzKTjIXomNsdAy7uBiP27VW77JhKeb2HF5FmwBf H5jQwN86JTAdWTQe1VSX =8wrY -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-02-11 14:23, schrieb Martin Storsjö: >> Yes - now I extended the test to use a non-power-of-two texture >> size, and if I hack out the ARB_TEXTURE_NON_POWER_OF_TWO support >> (in wined3d/directx.c) the tests fail and crash. > Alright, I guess I should have a look at it. > > On which Windows systems(Windows version, GPU) did you test your test? > I know that there are plenty of differences in YUV handling, so I'd > like to run the tests on some of my Windows installations too. I didn't really test my test properly on windows yet - how hard is it on a scale to compile and run them there? I only tested it briefly (by ripping out the relevant parts from visual.c and compiling that as a standalone C file without the wine test framework) on windows so far, on a VMware VM with XP, and the direct3d driver there doesn't support either NV12, YV12 nor I420, only UYVY/YUY2 (this is actually my original reason for trying anything of this in wine). The D3D rendering did seem to filter the texture when stretching though, but I chose sampling points within it that should resolve to the right color despite that. So unfortunately I'm not sure how much more I can test it on actual windows... Anyway, I'll resend my patchset with the last fixes from yesterday. // Martin

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I sent two patches that should get rid of the texture_rectangle crashes. Indeed, things seem to work fine now, and my YUV layout tests do succeed with ARB_TEXTURE_NON_POWER_OF_TWO disabled. Thanks for the prompt fix! // Martin

Feb. 12, 2014

Re: msvcrt: Return error on invalid handle in _open_osfhandle (try4)

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://newtestbot.winehq.org/JobDetails.pl?Key=4819 Your paranoid android. === wxppro (32 bit file) === file.c:2202: Test failed: info->exflag = 1, expected 4

Feb. 12, 2014

Re: shell32/tests: Skip any test that needs the .shlexec association if we could not create it.

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://newtestbot.winehq.org/JobDetails.pl?Key=4818 Your paranoid android. === wxppro (32 bit shlexec) === shlexec.c:1211: Test failed: expected 1 args, got 4 shlexec.c:2283: Test failed: argcA expected 5, but got 4 === w2008s64 (32 bit shlexec) === shlexec.c:1564: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt6C3.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt6C3.tmp\test file.shlexec' shlexec.c:2660: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt6C3.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt6C3.tmp\test2.exe' shlexec.c:2673: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt6C3.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt6C3.tmp\test2.exe' shlexec.c:2685: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt6C3.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt6C3.tmp\test2.exe' === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1532: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1564: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1532: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1564: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\wt8C15.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\wt8C15.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2102: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt8C14.tmp\wt8C15.tmp" Exec") succeeded: rc=42 === w2008s64 (64 bit shlexec) === shlexec.c:1564: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt249F.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt249F.tmp\test file.shlexec' shlexec.c:2660: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt249F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt249F.tmp\test2.exe' shlexec.c:2673: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt249F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt249F.tmp\test2.exe' shlexec.c:2685: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt249F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt249F.tmp\test2.exe'

Feb. 12, 2014

Re: ole32/tests: Use wine_dbgstr_guid for printing GUIDs.

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://newtestbot.winehq.org/JobDetails.pl?Key=4817 Your paranoid android. === wxppro (32 bit marshal) === marshal.c:3054: Test failed: wait timed out marshal.c:3058: Test failed: CoCreateInstance failed with error 0x80040154 marshal: unhandled exception c0000005 at 0041C45C === w8 (32 bit marshal) === marshal.c:3315: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3332: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3370: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3388: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3352: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3315: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3332: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3370: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3388: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3352: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3315: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3332: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3370: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3388: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0xc04 instead of 0xb00 marshal.c:3352: Test failed: info->cbSize was -873875100 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0xc04 instead of 0xb00

Feb. 12, 2014

Re: [PATCH 5/5] d3d10core: Implement d3d10_depthstencil_view_GetDevice().

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://newtestbot.winehq.org/JobDetails.pl?Key=4815 Your paranoid android. === wvista (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. device.c:244: Test failed: Got unexpected refcount 4. device.c:248: Test failed: Got unexpected refcount 6. device.c:253: Test failed: Got unexpected refcount 7. device.c:298: Test failed: Got unexpected refcount 4. device.c:303: Test failed: Got unexpected refcount 5. === w2008s64 (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. device.c:244: Test failed: Got unexpected refcount 4. device.c:248: Test failed: Got unexpected refcount 6. device.c:253: Test failed: Got unexpected refcount 7. device.c:298: Test failed: Got unexpected refcount 4. device.c:303: Test failed: Got unexpected refcount 5. === w2008s64 (64 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. device.c:244: Test failed: Got unexpected refcount 4. device.c:248: Test failed: Got unexpected refcount 6. device.c:253: Test failed: Got unexpected refcount 7. device.c:298: Test failed: Got unexpected refcount 4. device.c:303: Test failed: Got unexpected refcount 5.

Feb. 12, 2014

Re: [PATCH 4/5] d3d10core: Implement d3d10_buffer_GetDevice().

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://newtestbot.winehq.org/JobDetails.pl?Key=4814 Your paranoid android. === wvista (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. device.c:288: Test failed: Got unexpected refcount 4. device.c:293: Test failed: Got unexpected refcount 5. === w2008s64 (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. device.c:288: Test failed: Got unexpected refcount 4. device.c:293: Test failed: Got unexpected refcount 5. === w2008s64 (64 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. device.c:288: Test failed: Got unexpected refcount 4. device.c:293: Test failed: Got unexpected refcount 5.

Feb. 12, 2014

Re: [PATCH 3/5] d3d10core: Implement d3d10_texture3d_GetDevice().

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://newtestbot.winehq.org/JobDetails.pl?Key=4813 Your paranoid android. === wvista (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. === w2008s64 (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5. === w2008s64 (64 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. device.c:165: Test failed: Got unexpected refcount 4. device.c:170: Test failed: Got unexpected refcount 5. device.c:184: Test failed: Got unexpected refcount 4. device.c:189: Test failed: Got unexpected refcount 5.

Feb. 12, 2014

Re: [PATCH 2/5] d3d10core: Implement d3d10_texture2d_GetDevice().

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://newtestbot.winehq.org/JobDetails.pl?Key=4812 Your paranoid android. === wvista (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. === w2008s64 (32 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5. === w2008s64 (64 bit device) === device.c:76: Test failed: Got unexpected refcount 4. device.c:81: Test failed: Got unexpected refcount 5. device.c:95: Test failed: Got unexpected refcount 4. device.c:100: Test failed: Got unexpected refcount 5.

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I sent two patches that should get rid of the texture_rectangle crashes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+1rLAAoJEN0/YqbEcdMwmt0P/A1mB/aCzixb9Anw9NNvOkyL Ued/hk5aKfzC7Fbx3VOGsd1+2UcI5EHUFRTRU0Hxa/GQiG96nxIRXnYxCFfJVPxH nS5iqpRTD4ej8V0LyioID11hbueTARhKYUBCztXDJkglys2hgso2nKmoyzSn+Ftt JvCP5tTCU5abdDSyTxo/ae//1ZnzbzZvEGJ+ZUKNv/vzwXd50vPoTdstip8VnFzQ 8gq405aZ6AzrihfDowthekvO4++81xfZYzpim4HTio1tBJw64OkUbGPWa2UjKoCD mkLbiUbzuCEm5hj/DUbPralzGOl6a6TYoK5xbarQAVetQOKKgtCtt/+4EVvbr2lT lWKVG6ZRmV31bSMzO+ynvr1zzIlQ04RsAZfpI4RHTG9lEfC3OFMKt8Hw57d84Cnw 3jWWroAgmUtxwO3HWWsTyk6EUe8l2oMjgdgjh3bleCiaRJ0xrL8R4otjJR0nQYCQ GLRm6INJgXxMVkRwH7xYz7wKQFavSvgKRkqr3fIgEZ/BwnIiIJJImT0/uO0YWfUX WCUU3nuGIPhJ0nWUx1XoshL4JKYJh1cPwYoFXIxEoFN0YpRUrlpjj5KHEYg4y17V iYCKSmUcLve8NM9/Unj9gK88t+tCCHolhqaYqnQVCDlaef20536TSQ4U8OplLn8c d73F1YfiLxC7/caJzHNa =dp9a -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: ddraw/tests: Skip the primary palette tests if the 640x480x8 mode is not supported.

by Henri Verbeet

On 12 February 2014 10:28, Francois Gouget <fgouget(a)codeweavers.com> wrote: > hr = IDirectDraw_SetDisplayMode(ddraw, 640, 480, 8); > + if (hr == E_NOTIMPL) > + { > + win_skip("8bpp display mode is not supported\n"); > + DestroyWindow(window); > + return; > + } Is this for the Win 8 testbot? Unsupported display modes should return DDERR_UNSUPPORTED, and 640x480 at 8 bpp should pretty much always be supported. Does changing display modes work at all on that VM? IIRC it had more issues with changing display modes, and not just in the ddraw tests.

Feb. 12, 2014

Re: [2/2] dpnet: Use registry for lookup in IDirectPlay8Peer, EnumServiceProviders

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -141,30 +175,56 @@ static HRESULT WINAPI IDirectPlay8PeerImpl_EnumServiceProviders(IDirectPlay8Peer > else > { > FIXME("Application requested a provider we don't handle (yet)\n"); > - *pcReturned = 0; > return DPNERR_DOESNOTEXIST; > } > > if(*pcbEnumData < req_size) > { > + RegCloseKey(key); > + > *pcbEnumData = req_size; > return DPNERR_BUFFERTOOSMALL; > } > > - pSPInfoBuffer->pwszName = (LPWSTR)(pSPInfoBuffer + 1); > - > if(!pguidServiceProvider) > { > - lstrcpyW(pSPInfoBuffer->pwszName, dp_providerW); > - pSPInfoBuffer->guid = CLSID_DP8SP_TCPIP; > + int offset = 1; > + int count = 0; > + LPWSTR infoend = ((LPWSTR)pSPInfoBuffer + (sizeof(DPN_SERVICE_PROVIDER_INFO) * (*pcReturned))); > + > + index = 0; > + nextKeyNameResult = RegEnumKeyW( key, index, provider, MAX_PATH); > + while(nextKeyNameResult == ERROR_SUCCESS) > + { > + DWORD dwBufLen = 350; > + WCHAR name[350]; > + > + res = RegGetValueW( key, provider, friendly, RRF_RT_REG_SZ, NULL, name, &dwBufLen); > + if(res == ERROR_SUCCESS) > + { > + pSPInfoBuffer[count].guid = CLSID_DP8SP_TCPIP; > + pSPInfoBuffer[count].pwszName = (LPWSTR)(infoend + offset); > + lstrcpyW(pSPInfoBuffer[count].pwszName, name); > + > + offset += dwBufLen/sizeof(WCHAR); > + > + count++; > + } > + > + index++; > + nextKeyNameResult = RegEnumKeyW( key, index, provider, MAX_PATH ); > + } The buffer sizes and pointers are pretty much all handled incorrectly. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2014