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

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.
by Henri Verbeet 16 Feb '14

16 Feb '14

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Unfortunately different implementations(Windows-NV and Mac-AMD tested) interpret some colors vastly > + * differently, so we need a max diff of 18. */ And actually, is there any chance the "vastly differently" here is because of using BT.601 vs. BT.709 coefficients, or not including the headroom/footroom scaling + offsets?

2 1

Questions about filename_tests in dlls/shell32/tests/shlexec.c
by Zhenbo Li 16 Feb '14

16 Feb '14

Hello, I checked wine test errors, and found some errors for dlls/shell32/tests/shlexec.c[1]. I wanted to fix bugs in 'static void test_filename(void)'. However, I can't understand the intention of previous code: All testcases are put into 'static filename_tests_t filename_tests[]', then they are tested via a while-loop. I think it is difficult to locate *which* testcase really fails. Is re-factoring such code encouraged? If so, I'm glad to do it. I really appreciate all finds of ideas. Thank you. [1]: http://test.winehq.org/data/aa22a3c4b2e772636163ea50e7245dba01fe7b34/win8_n… Zhenbo Li

3 2

Re: Assorted spelling fixes
by Marvin 16 Feb '14

16 Feb '14

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=4916 Your paranoid android. === w8 (32 bit midi) === midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM

1 0

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)
by Henri Verbeet 15 Feb '14

15 Feb '14

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > -static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx, int pf) > +static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx) This doesn't need "gl_info" either anymore now. It's also a bit questionable if context_restore_gl_context() has much of a purpose at all anymore, it's pretty much just a wglMakeCurrent() call, and has only two callers.

2 2

Converting source to unicode, bug 28189
by Hugh McMaster 15 Feb '14

15 Feb '14

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

2 4

Re: xmllite: Don't fail the whole parsing process because of unsupported 'xmlns' attribute.
by Nikolay Sivov 15 Feb '14

15 Feb '14

On 2/14/2014 11:23, Dmitry Timoshkov wrote: > This patch allows to successfully parse pretty complex XML task definitions. > > Please apply after other xmllite fixes. I think it's fine to relax a check here as you did if it really helps. Same applies to other patches. My main problem with all of that is that whole reader code needs to be revised and partially rewritten at some point (better sooner than later), to properly support chunked reads and corresponding state updates. Looking at it now I don't actually like the way I did it, it's not easily extensible and not very clean. Do you plan to add more code to xmllite itself or what we have is enough for taskschd so far?

2 1

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.
by Henri Verbeet 14 Feb '14

14 Feb '14

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - HRESULT color; > - DWORD ref_color_left, ref_color_right; > + DWORD ref_color_left, ref_color_right, color; > If you're cleaning it up anyway, you may as well make that a D3DCOLOR. > + static const struct > + { > + DWORD in; /* The input color. */ > + DWORD uyvy_left; /* "in" interpreted as uyvy and transformed to RGB, pixel 1/1. */ > + DWORD uyvy_right; /* "in" interpreted as uyvy and transformed to RGB, pixel 2/1. */ > + DWORD yuy2_left; /* "in" interpreted as yuy2 and transformed to RGB, pixel 1/1. */ > + DWORD yuy2_right; /* "in" interpreted as yuy2 and transformed to RGB, pixel 2/1. */ > + } > + test_data[] = > + { > + {0x00000000, 0x00008700, 0x00008700, 0x00008700, 0x00008700}, > + {0xff000000, 0x00008700, 0x004bff1c, 0x00b30000, 0x00b30000}, > + {0x00ff0000, 0x00b30000, 0x00b30000, 0x00008700, 0x004bff1c}, > + {0x0000ff00, 0x004bff1c, 0x00008700, 0x000030e1, 0x000030e1}, > + {0x000000ff, 0x000030e1, 0x000030e1, 0x004bff1c, 0x00008700}, > + {0xffff0000, 0x00b30000, 0x00ffd01c, 0x00b30000, 0x00ffd01c}, > + {0xff00ff00, 0x004bff1c, 0x004bff1c, 0x00b300e1, 0x00b300e1}, > + {0xff0000ff, 0x000030e1, 0x004bffff, 0x00ffd01c, 0x00b30000}, > + {0x00ffff00, 0x00ffd01c, 0x00b30000, 0x000030e1, 0x004bffff}, > + {0x00ff00ff, 0x00b300e1, 0x00b300e1, 0x004bff1c, 0x004bff1c}, > + {0x0000ffff, 0x004bffff, 0x000030e1, 0x004bffff, 0x000030e1}, > + {0xffffff00, 0x00ffd01c, 0x00ffd01c, 0x00b300e1, 0x00ff79ff}, > + {0xffff00ff, 0x00b300e1, 0x00ff79ff, 0x00ffd01c, 0x00ffd01c}, > + {0xffffffff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff}, > + {0x4cff4c54, 0x00ff0000, 0x00ff0000, 0x000b8b00, 0x00b6ffa3}, > + {0x00800080, 0x00000000, 0x00000000, 0x0000ff00, 0x0000ff00}, > + {0xff80ff80, 0x00ffffff, 0x00ffffff, 0x00ff00ff, 0x00ff00ff}, > + {0x1c6b1cff, 0x000000fd, 0x000000fd, 0x006dff45, 0x0000d500}, > }; ... > - for(fmt = 0; fmt < 2; fmt++) { > - if(fmt == 0) { > - format = D3DFMT_UYVY; > - fmt_string = "D3DFMT_UYVY"; > - } else { > + for (fmt = 0; fmt < 2; fmt++) > + { > + if (fmt) > + { > format = D3DFMT_YUY2; > fmt_string = "D3DFMT_YUY2"; > } > + else > + { > + format = D3DFMT_UYVY; > + fmt_string = "D3DFMT_UYVY"; > + } ... > + if (fmt) > + { > ref_color_left = test_data[i].yuy2_left; > ref_color_right = test_data[i].yuy2_right; > } > + else > + { > + ref_color_left = test_data[i].uyvy_left; > + ref_color_right = test_data[i].uyvy_right; > + } > There's probably a nicer way to do all that.

1 0

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.
by Henri Verbeet 14 Feb '14

14 Feb '14

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

1 0

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.
by Henri Verbeet 14 Feb '14

14 Feb '14

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

1 0

Re: [PATCH 5/5] d3dx9: Handle pixel formats larger than 32 bits in surface loading / filtering functions.
by Henri Verbeet 14 Feb '14

14 Feb '14

On 14 February 2014 15:53, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (format->bits[c]) > + { > + mask = format->bits[c] == 32 ? ~0U : (1 << format->bits[c]) - 1; You could probably also do that as "mask = ~0u >> (32 - format->bits[c]);", since you already need to check "format->bits[c]" for 0 anyway.

2 1