October 2015 - Wine-devel - list.winehq.org

Ignored WineTest report
by Francois Gouget 05 Oct '15

05 Oct '15

My FreeBSD 7.0 VM sent the following report: http://fgouget.free.fr/tmp/winebot-fg-freebsd70-vm.report However that report was ignored and I have no idea why. The report is under 1.5MB and has only 44 failures. So why is it being ignored? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

2 5

Re: [PATCH 6/7] wined3d: Avoid reading uninitialized texcoord varyings in FFP replacement fragment shaders.
by Henri Verbeet 05 Oct '15

05 Oct '15

On 2 October 2015 at 14:54, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - unsigned char padding; > + unsigned char pointsprite : 1; > + unsigned char padding : 7; > + unsigned int inited_texcoords; > }; Did you perhaps mean something like "initialized_texcoords" or "texcoords_initialized"?

2 2

Re: [PATCH 1/7] wined3d: Avoid the deprecated syntax for SM3 varyings on core profile.
by Henri Verbeet 05 Oct '15

05 Oct '15

On 2 October 2015 at 14:54, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void PRINTF_ATTR(4, 5) declare_in_varying(const struct wined3d_gl_info *gl_info, > + struct wined3d_string_buffer *buffer, BOOL flat, const char *format, ...) It's not a huge issue, but generally speaking things are more readable on the caller side when you use a flag or enum instead of a BOOL. I.e., "declare_in_varying(..., TRUE, ...);" vs. e.g. "declare_in_varying(..., WINED3D_GLSL_INTERPOLATE_FLAT, ...);".

1 0

Re: [PATCH 5/9] d3d11: Implement {d3d10, d3d11}_geometry_shader_GetDevice().
by Henri Verbeet 05 Oct '15

05 Oct '15

For what it's worth, the original reason geometry shaders and input layouts don't have a GetDevice() implementation was that it was a bit harder to add test coverage for them than for the rest of the interfaces. It's probably easy enough now, so please add some geometry shader coverage to test_create_shader(). You can probably use the shader from test_clear_state().

1 0

Re: crypt32/tests: Delete WineTest registry key when tests are complete
by Marvin 05 Oct '15

05 Oct '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=17004 Your paranoid android. === w864 (64 bit store) === store.c:2603: Test failed: CertAddCertificateContextToStore failed store.c:2604: Test failed: Unexpected cert3 store: unhandled exception c0000005 at 000000000044DAD6

2 1

Re: [PATCH 1/5] ddraw/tests: Don't skip d3d1-2 tests if DirectDrawCreateEx isn't present
by Marvin 05 Oct '15

05 Oct '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=17003 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2334: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2518: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2665: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [2/2] widl: Fix generation of a typelib for winhttp.
by Huw Davies 05 Oct '15

05 Oct '15

On 2 Oct 2015, at 03:25, Dmitry Timoshkov wrote: > diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c > index 26600e4..7973113 100644 > --- a/tools/widl/write_msft.c > +++ b/tools/widl/write_msft.c > @@ -974,8 +974,7 @@ static int encode_type( > { > int typeinfo_offset; > > - /* typedef'd types without public attribute aren't included in the typelib */ > - while (type->typelib_idx < 0 && type_is_alias(type) && !is_attr(type->attrs, ATTR_PUBLIC)) > + while (type->typelib_idx < 0 && type_is_alias(type)) > type = type_alias_get_aliasee(type); > > chat("encode_type: VT_USERDEFINED - type %p name = %s real type %d idx %d\n", type, > @@ -1836,7 +1835,7 @@ static msft_typeinfo_t *create_msft_typeinfo(msft_typelib_t *typelib, enum type_ > MSFT_TypeInfoBase *typeinfo; > MSFT_GuidEntry guidentry; > > - chat("create_msft_typeinfo: name %s kind %d\n", name, kind); > + chat("create_msft_typeinfo: name %s kind %d, index %d\n", name, kind, typelib->typelib_header.nrtypeinfos); > > msft_typeinfo = xmalloc(sizeof(*msft_typeinfo)); > memset( msft_typeinfo, 0, sizeof(*msft_typeinfo) ); > @@ -2307,9 +2306,7 @@ static void add_entry(msft_typelib_t *typelib, const statement_t *stmt) > { > const type_list_t *type_entry = stmt->u.type_list; > for (; type_entry; type_entry = type_entry->next) { > - /* if the type is public then add the typedef, otherwise attempt > - * to add the aliased type */ > - if (is_attr(type_entry->type->attrs, ATTR_PUBLIC)) > + if (type_get_type(type_entry->type) == TYPE_BASIC) > add_typedef_typeinfo(typelib, type_entry->type); > else > add_type_typeinfo(typelib, type_alias_get_aliasee(type_entry->type)); Doesn't this essentially make [public] a nop? That seems wrong. The WinHttpRequestOption enum has a [uuid] attribute, so that probably has something to do with it. Huw.

3 8

Re: [PATCH 5/5] ddraw: Enumerate the correct Direct3D devices in the correct order
by Marvin 04 Oct '15

04 Oct '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=16988 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2428: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2428: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2428: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2428: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2612: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2759: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2759: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2759: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2759: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 4/5] ddraw: Accept all 3 versions of D3DFINDDEVICERESULT
by Marvin 04 Oct '15

04 Oct '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=16987 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2367: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2367: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2367: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2367: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2551: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2698: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2698: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2698: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2698: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 3/5] ddraw/tests: Restore strings modified by D3D7EnumLifetimeTest
by Marvin 04 Oct '15

04 Oct '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=16986 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2360: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2544: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2691: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0