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

Bored waiting for Wine 1.8?
by Jeremy White 15 Dec '15

15 Dec '15

Have I just got the thing for you! We are *this* close to having what I consider a rational set of Windows VMs running the tests cleanly: https://www.winehq.org/~jwhite/latest.html (As a reminder, that just scrapes all the testbot vms, excludes win2k, win8 and win10, and reports any ones that are not consistently green). We have a record low of 12 failures. Woohoo! I want to remind Andrew, Francois, Jacek, Aric, Bruno, Hans, Stefan and Jacek that they agreed to work on items on this list... And for anyone looking for a new failure, we have two: http://test.winehq.org/data/ca9001d6bda3084ab9bc80baa7d6e5533252c797/win7_n… http://test.winehq.org/data/e69d9ec3c4e8829c5c18cea7d8348171d51dcd76/vista_… Act now, bugs are going fast! <grin> Cheers, Jeremy

1 0

d3d software cursor test
by Stefan Dösinger 15 Dec '15

15 Dec '15

Hi, I've written a test for d3d9 software cursors, but I'll need some help testing it on Windows. The behavior on Windows 10 is different from the one I remember from Windows 7. It doesn't affect the visual appearance of the cursor, but it does change how the test can verify the output. Please give the attached test a try on Windows. I am without my test machines right now (except for one with Win10 on it), so my abilities are somewhat limited at the moment. What I am interested in is the trace() line it writes at the end. It says if the test could read back the cursor with GetDC and/or GetFrontBufferData. Thanks, Stefan

3 3

Re: [PATCH 3/5] wined3d: Add a real implementation of wined3d_check_device_multisample_type().
by Henri Verbeet 15 Dec '15

15 Dec '15

On 14 December 2015 at 23:37, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 70857c9..f798f1d 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -185,6 +185,7 @@ void wined3d_rb_free(void *ptr) DECLSPEC_HIDDEN; > #define MAX_SAMPLER_OBJECTS 16 > #define MAX_SHADER_RESOURCE_VIEWS 128 > #define MAX_VERTEX_BLENDS 4 > +#define MAX_MULTISAMPLE_TYPES 8 > > struct min_lookup > { > @@ -3242,6 +3243,8 @@ struct wined3d_format > GLint glFormat; > GLint glType; > UINT conv_byte_count; > + GLint multisample_types_count; > + GLint multisample_types[MAX_MULTISAMPLE_TYPES]; I guess this is easy when initializing the data, but it seems a bit wasteful. Wouldn't it be nicer to store this as a 32-bit mask? It would be nice to have some basic tests for d3d10 and d3d11 as well. (See also ID3D11Device::CheckMultisampleQualityLevels())

1 0

Re: [PATCH 5/5] d3d8/tests: Port test_checkdevicemultisampletype() to d3d8.
by Marvin 14 Dec '15

14 Dec '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=18979 Your paranoid android. === w1064 (32 bit device) === device.c:2659: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2664: Test failed: The focus window is active. device.c:2672: Test failed: Got unexpected hr 0x88760869. device.c:2678: Test failed: Got unexpect screen size 800x600. device.c:2693: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2702: Test failed: Got unexpect screen size 800x600. device.c:2715: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2723: Test failed: Got unexpect width 640. device.c:2724: Test failed: Got unexpect height 480.

1 0

Re: ddraw/tests: Rename mips to mipmaps
by Henri Verbeet 14 Dec '15

14 Dec '15

On 13 December 2015 at 22:33, André Hentschel <nerv(a)dawncrow.de> wrote: > GCC for mips defines mips to 1, thus this file won't build with a mips compiler without this patch > I think -std=c90 should help with that, although there may be some instances of e.g. "inline" and "typeof" we'd need to fix. Still, I like "mipmaps" better than "mips", even though it's supposed to be called "mipmap_count".

1 0

Re: ddraw/tests: Rename mips to mipmaps
by Marvin 13 Dec '15

13 Dec '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=18975 Your paranoid android. === w1064 (32 bit dsurface) === dsurface.c:296: Test failed: Destination data after blitting is not correct dsurface.c:330: Test failed: Destination data after blitting is not correct dsurface.c:509: Test failed: Surface data after srckey blit does not match dsurface.c:534: Test failed: Surface data after src override key blit does not match dsurface.c:588: Test failed: Surface data after dest key blit does not match dsurface.c:614: Test failed: Surface data after dest key override blit does not match dsurface.c:676: Test failed: Surface data with src key and dest key blit does not match

1 0

Re: [PATCH] Support -march in winegcc and winebuild
by André Hentschel 13 Dec '15

13 Dec '15

Am 13.12.2015 um 19:17 schrieb Stephen Kitt: > Since -mcpu is already supported, it seems to make sense to also support > -march. Having -march simplifies building for ARM platforms... > > Signed-off-by: Stephen Kitt <steve(a)sk2.org> > --- > tools/winebuild/build.h | 1 + > tools/winebuild/main.c | 2 ++ > tools/winebuild/utils.c | 1 + > tools/winegcc/winegcc.c | 2 +- > 4 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/tools/winebuild/build.h b/tools/winebuild/build.h > index 4a71eed..e32e7a9 100644 > --- a/tools/winebuild/build.h > +++ b/tools/winebuild/build.h > @@ -362,6 +362,7 @@ extern struct strarray *cc_command; > extern struct strarray *ld_command; > extern struct strarray *nm_command; > extern char *cpu_option; > +extern char *arch_option; > extern int thumb_mode; > > #endif /* __WINE_BUILD_H */ > diff --git a/tools/winebuild/main.c b/tools/winebuild/main.c > index d1717c0..08c8c2c 100644 > --- a/tools/winebuild/main.c > +++ b/tools/winebuild/main.c > @@ -89,6 +89,7 @@ struct strarray *cc_command = NULL; > struct strarray *ld_command = NULL; > struct strarray *nm_command = NULL; > char *cpu_option = NULL; > +char *arch_option = NULL; > > #ifdef __thumb__ > int thumb_mode = 1; > @@ -408,6 +409,7 @@ static char **parse_options( int argc, char **argv, DLLSPEC *spec ) > else if (!strcmp( optarg, "arm" )) thumb_mode = 0; > else if (!strcmp( optarg, "thumb" )) thumb_mode = 1; > else if (!strncmp( optarg, "cpu=", 4 )) cpu_option = xstrdup( optarg + 4 ); > + else if (!strncmp( optarg, "arch=", 5 )) arch_option = xstrdup( optarg + 5 ); > else fatal_error( "Unknown -m option '%s'\n", optarg ); > break; > case 'M': > diff --git a/tools/winebuild/utils.c b/tools/winebuild/utils.c > index 83eb803..4860a19 100644 > --- a/tools/winebuild/utils.c > +++ b/tools/winebuild/utils.c > @@ -388,6 +388,7 @@ struct strarray *get_as_command(void) > if (force_pointer_size) > strarray_add_one( args, (force_pointer_size == 8) ? "-m64" : "-m32" ); > if (cpu_option) strarray_add_one( args, strmake("-mcpu=%s", cpu_option) ); > + if (arch_option) strarray_add_one( args, strmake("-march=%s", arch_option) ); > return args; > } > > diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c > index c07243b..1326afe 100644 > --- a/tools/winegcc/winegcc.c > +++ b/tools/winegcc/winegcc.c > @@ -1525,7 +1525,7 @@ int main(int argc, char **argv) > strarray_add(opts.winebuild_args, argv[i]); > raw_linker_arg = 1; > } > - else if (strncmp("-mcpu=", argv[i], 6) == 0) > + else if (strncmp("-mcpu=", argv[i], 6) == 0 || strncmp("-march=", argv[i], 7) == 0) > strarray_add(opts.winebuild_args, argv[i]); > break; > case 'n': > Hi, please first change winebuild to support it, make the subject something like "[1/2] winebuild: Add support for -march" and please update tools/winebuild/winebuild.man.in In the second patch make use of that new feature in winegcc Otherwise it looks good, maybe mention why this is needed for Debian/armel

2 1

Re: [PATCH 1/2] d3dx9_36/tests: Add D3DXSaveSurfaceToFileInMemory D3DXIFF_DDS tests (try 4)
by Matteo Bruni 11 Dec '15

11 Dec '15

2015-12-11 10:59 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > The DDS_CAPS_TEXTURE | DDSCAPS_ALPHA caps check was to address testbot failures > http://testbot.winehq.org/JobDetails.pl?Key=18888 Yes, I understand that. What I meant is that I don't get the header->caps == DDS_CAPS_TEXTURE case ever, except on Wine, so the check should be simply: todo_wine ok(header->caps == (DDS_CAPS_TEXTURE | DDSCAPS_ALPHA), "Got unexpected caps %x.\n", header->caps); Unless you can actually get that one to fail on Windows. If that's the case I'd like to know where does it fail for you.

2 7

Random err:winediag:nulldrv_CreateWindow errors related to windows and explorer
by Bruno Jesus 10 Dec '15

10 Dec '15

I believe that since code freeze started (or maybe 1.7.55) a random behavior was introduced related to these 2 messages: err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow The explorer process failed to start. Sometimes together there is also: err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 I'm not seeing this alone. at November 23 there was a mention to it in bug https://bugs.winehq.org/show_bug.cgi?id=39384 and also in December 1 there was a mention at bug https://bugs.winehq.org/show_bug.cgi?id=39057 The issue seems to manifest more when the computer is heavily loaded (cpu/ram). I believe a regression test to be very hard since the issue is random, sorry. Is anyone else affected by this? I'm still affected with today's git. Best wishes, Bruno

5 8

Re: [PATCH] wined3d: Set WINED3D_BUFFER_DOUBLEBUFFER for managed buffers as well.
by Stefan Dösinger 10 Dec '15

10 Dec '15

> Am 08.12.2015 um 20:42 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>: > > - if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING) > + if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING || pool == WINED3D_POOL_MANAGED) This also helps bugs like 29878, or the Crysis bug that was I think incorrectly closed. However, the reason why I've never made this seemingly obvious change is that you'll get other applications that crash due to VM exhaustion now. So I'm afraid you'll just trade one kind of breakage for another. The proper fix is probably somewhere in GL_ARB_buffer_storage, but that is too complicated for 1.8. One app that needed direct mapping of managed buffers to run properly was Half Life 2. I think the game changed since then and sets the LAA flag, but there are other games with the same problem.

3 4