May 2017 - Wine-Devel - list.winehq.org

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 8, 2017

May 8, 2017

>> 1) So question is - if winecfg shows up. Is that supported? Is it enough, >> when that _big_ "WARNING:" will be resolved (disappears), is such wine >> package supported? Most of them would be easy to overcome, except >> XInput2 + libOSMesa which needs IMHO deeper dependencies. > >If winecfg runs, that should be good enough. Optional packages can be >backported if necessary. > OK, then I will concentrate on min kernel version :)

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 8, 2017

May 8, 2017

> >None of those are needed by winecfg. They would be needed by some >applications, though. > I'm aware of it. But the idea is elsewhere... There are two approaches: 1. i will strictly find the lowest kernel on which i'm able to run winecfg but probably not much more... 2. i will find minimum requirements like pcap-v1.8.1 etc. so, that we can get rid of those generic: "configure: libpulse development files not found or __too__ __old__" but user will be given exact version (for Linux and those who care about other OS can do the same). Let's face it - most of programs says for example something like min supported OS: Win7 and higher) Isn't that "Bug 42478 - Undeclared O_CLOEXEC use in qcap DLL" about this? Quick googling sugest "O_CLOEXEC (Since Linux 2.6.23)". With commit dfd22fb294c6ce9c3daba311f96ca3b4933d265c shouldn't be min requirements bumped to linux-2.6.23 ?? Sure there is https://github.com/wine-compholio/wine-staging/blob/master/patches/qcap-O_C… Then two users having wine-2.7, but with totally different behavior, which is definitely harder to support... Maybe that's OK and then wine probably doesn't need nothing like minimum requirements. If we don't play on min requirements = it's normal, that some parts of wine do not work. Why there are two kinds of warning? a) configure: libmpg123 development files not found (or too old), mp3 codec won't be supported. b) configure: WARNING: libgnutls development files not found, no schannel support.

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 8, 2017

May 8, 2017

>> >> Isn't commit https://source.winehq.org/git/wine.git/commitdiff/9f06a197c8c156acf21d8d809… >> about this? > >For that specific issue, yes. But it would be interesting to find out if >there are other issues that we aren't aware of, and whether they would >be worth trying to fix. Plan was: Debian 3.0 Woody i386 ===================== * Released 2002-07-19 * kernel v2.2.20, v2.4.6 kernel is also included Debian 3.1 Sarge i386 ===================== * Released 2005-06-06 * Linux kernel v2.4.27, v2.6.8 Debian 4.0 Etch i386 ==================== * Released 2007-04-08 * Linux kernel v2.6.18 After getting these, i started with Etch and wine-2.7. I installed all needed & available *-dev packages. Nevertheless i got: configure: XInput2 headers not found, the XInput 2 extension won't be supported. configure: libOSMesa development files not found (or too old), OpenGL rendering in bitmaps won't be supported. configure: OpenCL development files not found, OpenCL won't be supported. configure: pcap development files not found, wpcap won't be supported. configure: liblcms2 development files not found, Color Management won't be supported. configure: libpulse development files not found or too old, Pulse won't be supported. configure: gstreamer-1.0 base plugins development files not found, gstreamer support disabled configure: OSS sound system found but too old (OSSv4 needed), OSS won't be supported. configure: libudev development files not found, plug and play won't be supported. configure: libmpg123 development files not found (or too old), mp3 codec won't be supported. configure: libopenal development files not found (or too old), OpenAL won't be supported configure: openal-soft development files not found (or too old), XAudio2 won't be supported configure: WARNING: libgnutls development files not found, no schannel support. configure: Finished. Do 'make' to compile Wine. 1) So question is - if winecfg shows up. Is that supported? Is it enough, when that _big_ "WARNING:" will be resolved (disappears), is such wine package supported? Most of them would be easy to overcome, except XInput2 + libOSMesa which needs IMHO deeper dependencies. Anyway, configure suggest "do make". In that case compilation fails with: gcc -c -o v4l.o ../../../wine_git_src/dlls/qcap/v4l.c -I. -I../../../wine_git_src/dlls/qcap \ -I../../include -I../../../wine_git_src/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings \ -Wpointer-arith -gdwarf-2 -fno-omit-frame-pointer ../../../wine_git_src/dlls/qcap/v4l.c: In function ‘qcap_driver_init’: ../../../wine_git_src/dlls/qcap/v4l.c:802: error: ‘O_CLOEXEC’ undeclared (first use in this function) ../../../wine_git_src/dlls/qcap/v4l.c:802: error: (Each undeclared identifier is reported only once ../../../wine_git_src/dlls/qcap/v4l.c:802: error: for each function it appears in.) make[1]: *** [v4l.o] Error 1 make[1]: Leaving directory `/build/wine_git_bin_32/dlls/qcap' 2) And this also happens with "./configure --without-v4l" so probably real bug? 3) That "libpcap0.8-dev" isn't that old. So i looked closer and it appears, that it fails because of missing "port.h". IMHO that comes from kernel headers as i have it in v4.9, but not in v2.6.18. So minimum is not 2.3.31, but 2.6.18+ / 3.x ? or where that port.h appeared for the first time ?? ... configure:6945: checking pcap/pcap.h usability configure:6945: gcc -c -g -O0 conftest.c >&5 configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking pcap/pcap.h presence configure:6945: gcc -E conftest.c configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking for pcap/pcap.h configure:6945: result: yes configure:6945: checking poll.h usability configure:6945: gcc -c -g -O0 conftest.c >&5 configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking poll.h presence configure:6945: gcc -E conftest.c configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking for poll.h configure:6945: result: yes configure:6945: checking port.h usability configure:6945: gcc -c -g -O0 conftest.c >&5 conftest.c:93:18: error: port.h: No such file or directory Before taking any other steps, i'll try to wait for feedback on 1), 2) and 3) Regards, W.

3 2

Re: [v5 PATCH 1/4] mfplat: Implement MFTRegister
by Alexandre Julliard May 8, 2017

May 8, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + if (cinput && input_types) > + { > + size = cinput * sizeof(MFT_REGISTER_TYPE_INFO); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + memcpy(types, input_types, size); > + > + ret = RegSetValueExW(hclsid, inputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; Again, why do you need a copy? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/9] winemac.drv: EnumDisplayDevices placeholder implementation
by Ken Thomases May 8, 2017

May 8, 2017

Hi, Thanks for taking this up again… On Apr 24, 2017, at 3:48 PM, Donat Enikeev <donat(a)enikeev.net> wrote: > > Based on Ken Thomases <ken(a)codeweavers.com> staging patches > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > --- > dlls/winemac.drv/display.c | 51 +++++++++++++++++++++++++++++++++++++++ > dlls/winemac.drv/winemac.drv.spec | 1 + > 2 files changed, 52 insertions(+) This doesn't build: display.c:1007:13: error: use of undeclared identifier 'monitors' if (monitors[iDevNum].dwFlags & MONITORINFOF_PRIMARY) ^ display.c:1010:80: error: use of undeclared identifier 'monitors' memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice)); ^ display.c:1010:45: error: use of undeclared identifier 'monitors' memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice)); ^ Is this patch written on the assumption that some other staging patches have already been applied? Beyond that, can you explain the rationale of moving the implementation of EnumDisplayDevices to the drivers? My patches implemented it in user32 based on EnumDisplayMonitors() and GetMonitorInfoW(). It may be somewhat clunky, but has the advantage that it ensures all three functions return mutually consistent results. Since you appear to have dropped my patches which caused GetMonitorInfoW() to return unique names for the displays, they are no longer consistent. GetMonitorInfoW() always uses "\\.\DISPLAY1" for all monitors while this implementation of EnumDisplayDevices() attempts to use "\\.\DISPLAY2", etc., for secondary and subsequent monitors. For what it's worth, my original patches were rejected because Alexandre wanted the tracking and management of displays and display modes centralized in the explorer process[1]. I have my reservations about that approach, mind you. ;) [1] https://www.winehq.org/pipermail/wine-devel/2014-March/103680.html Issues with other patches in the series: Patch 1: \ No newline at end of file Patches 1 and 2 ought to come after 3. In the current order, they introduce dead code. -Ken

2 3

Outreachy: Rosanne DiMesio accepted for AppDB Improvements
by Austin English May 8, 2017

May 8, 2017

Howdy all, Please welcome me in congratulating Roseanne on being accepted for Outreachy. She will be working on improving the AppDB (which greatly needs it), and is being mentored by Jeremy Newman. Congrats Rosanne! -- -Austin GPG: 14FB D7EA A041 937B

4 3

Re: [PATCH 2/6] wined3d: Disable EXT_TEXTURE_LOD_BIAS on core profile.
by Henri Verbeet May 8, 2017

May 8, 2017

On 7 May 2017 at 20:32, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > glTexEnvf(..., GL_TEXTURE_LOD_BIAS, ...) is not available in core profile. > Just disable the extension for now. > Is the extension advertised on core profiles then?

2 3

Re: [PATCH 4/6] wined3d: Disable YUV formats when fixups are not supported.
by Henri Verbeet May 8, 2017

May 8, 2017

On 7 May 2017 at 20:32, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -5192,8 +5193,19 @@ static BOOL wined3d_check_surface_capability(const struct wined3d_format *format > > if (format->glInternal) > { > - TRACE("[OK]\n"); > - return TRUE; > + switch (format->id) > + { > + case WINED3DFMT_YUY2: > + case WINED3DFMT_UYVY: > + case WINED3DFMT_YV12: > + case WINED3DFMT_NV12: > + TRACE("%s\n", gl_info->supported[ARB_FRAGMENT_PROGRAM] > + ? "[OK]" : "[FAILED] - No YUV fixups support."); > + return gl_info->supported[ARB_FRAGMENT_PROGRAM]; > + default: > + TRACE("[OK]\n"); > + return TRUE; > + } Generally speaking, we've been moving away from this kind of "list some formats somewhere" approach. If we really have to disable these formats, I'd argue apply_format_fixups() would be the correct place, since creating the surfaces should probably also fail then. There's also an argument that the CPU blitter should be able to handle these though.

1 0

Re: [PATCH 3/6] wined3d: Disable ARB program extensions on core profile.
by Henri Verbeet May 8, 2017

May 8, 2017

On 7 May 2017 at 20:32, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > None of the ARBfp shader backend, fragment pipe replacement or blitter > are currently in working condition in core profiles (nor they are > expected to be in the foreseeable future). > Sure, but you can just check for WINED3D_GL_LEGACY_CONTEXT in e.g. wined3d_arbfp_blitter_create(). (And arguably, the shader backend and fragment pipe cases can't even happen unless you took extra steps to break your setup.)

1 0

Re: [PATCH 4/6] wined3d: Disable YUV formats when fixups are not supported.
by Stefan Dösinger May 8, 2017

May 8, 2017

> Am 07.05.2017 um 20:32 schrieb Matteo Bruni <mbruni(a)codeweavers.com>: > > + switch (format->id) > + { > + case WINED3DFMT_YUY2: > + case WINED3DFMT_UYVY: > + case WINED3DFMT_YV12: > + case WINED3DFMT_NV12: > + TRACE("%s\n", gl_info->supported[ARB_FRAGMENT_PROGRAM] > + ? "[OK]" : "[FAILED] - No YUV fixups support."); > + return gl_info->supported[ARB_FRAGMENT_PROGRAM]; Once upon a time blitting YUY2 and UYVY via regular 3D draws worked with GL_APPLE_ycbcr_422, and afaics the necessary format definitions are still in place.

1 0

Re: [PATCH] msi: Add MsiGetPatchFileListA/W stubs.
by Hans Leidekker May 8, 2017

May 8, 2017

On Mon, 2017-05-08 at 00:47 +0300, Andrey Gusev wrote: > +UINT WINAPI MsiGetPatchFileListA(LPCSTR szProductCode, LPCSTR szPatchList, > + LPDWORD pcFiles, MSIHANDLE **pphFileRecords) > +{ > + FIXME("(%s, %s, %p, %p) stub!\n", debugstr_a(szProductCode), > + debugstr_a(szPatchList), pcFiles, pphFileRecords); > + return ERROR_SUCCESS; You should set the output parameters to sensible values, or return an error.

1 0

Re: [PATCH v2 5/6] wined3d: Fix specular lighting calculation.
by Marvin May 7, 2017

May 7, 2017

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=30826 Your paranoid android. === w1064 (32 bit visual) === visual.c:8016: Test failed: Got unexpected color 0x00008080 for quad 2 (different colors). === w1064 (64 bit visual) === visual.c:8016: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

1 0

Re: [PATCH] user32: Removed 16-bit windows position trunc in WINPOS_SetPlacement.
by Alexandre Julliard May 6, 2017

May 6, 2017

Kees Beets <kbeets68(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=38231 > > Replaced SetWindowPos in WINPOS_SetPlacement with an implementation that > does not truncate windows positions to 16-bit. Fixes a bug in Adobe > Lightroom under wine that is not present under windows (7, 8, 10), > while still running all win tests successfully. It's good that it doesn't break the other tests, but since we currently don't have tests for SetWindowPlacement, that's not very convincing. You'd want to add some tests at least for the truncation thing, and also probably some for the message sequences. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] msvcp90: Call invalid_parameter_handler on index out of range in basic_string::operator[]
by Piotr Caban May 5, 2017

May 5, 2017

On 05/05/17 19:01, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/msvcp90/string.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) Please ignore this patch for now. Thanks, Piotr

1 0

Re: [PATCH] wined3d: Add NVIDIA GTX 1080 Ti to the GPU list
by Henri Verbeet May 5, 2017

May 5, 2017

On 4 May 2017 at 22:53, Björn Bidar <theodorstormgrade(a)googlemail.com> wrote: DRIVER_NVIDIA_GEFORCE8, 8192}, > + {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX1080TI, "NVIDIA GeForce GTX 1080 Ti", DRIVER_NVIDIA_GEFORCE8, 11169}, That's an unusual amount of memory, should that be 11264?

1 0

Re: [PATCH 04/10] d3dx9/tests: Use compare_float() in test_D3DXSHEvalSphericalLight().
by Alexandre Julliard May 4, 2017

May 4, 2017

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/d3dx9_36/tests/math.c | 171 ++++++++++++++++++++++++--------------------- > 1 file changed, 92 insertions(+), 79 deletions(-) This one is failing here: ../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so math && touch math.ok math.c:3194: Test failed: Red: case 1, order 5: expected[20] = 5.29080920e-04, received 5.29033889e-04. math.c:3205: Test failed: Green: case 1, order 5: expected[20] = 8.09182529e-04, received 8.09110585e-04. math.c:3217: Test failed: Blue: case 1, order 5: expected[20] = 1.08928420e-03, received 1.08918734e-03. math.c:3194: Test failed: Red: case 1, order 6: expected[20] = 5.29080920e-04, received 5.29033889e-04. math.c:3205: Test failed: Green: case 1, order 6: expected[20] = 8.09182529e-04, received 8.09110585e-04. math.c:3217: Test failed: Blue: case 1, order 6: expected[20] = 1.08928420e-03, received 1.08918734e-03. math.c:3194: Test failed: Red: case 2, order 5: expected[20] = -7.14543217e-04, received -7.14479480e-04. math.c:3217: Test failed: Blue: case 2, order 5: expected[20] = -1.47111830e-03, received -1.47098722e-03. math.c:3194: Test failed: Red: case 2, order 6: expected[20] = -7.14543217e-04, received -7.14479480e-04. math.c:3217: Test failed: Blue: case 2, order 6: expected[20] = -1.47111830e-03, received -1.47098722e-03. Makefile:340: recipe for target 'math.ok' failed make[1]: *** [math.ok] Error 10 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v2 4/5] d3dx9: Do not set active pass if BeginPass() failed.
by Matteo Bruni May 4, 2017

May 4, 2017

2017-05-04 0:33 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > if (technique && pass < technique->pass_count && !effect->active_pass) > { > + HRESULT hr; > + > effect->active_pass = &technique->passes[pass]; > memset(effect->current_light, 0, sizeof(effect->current_light)); > memset(&effect->current_material, 0, sizeof(effect->current_material)); > - return d3dx9_apply_pass_states(effect, effect->active_pass, TRUE); > + hr = d3dx9_apply_pass_states(effect, effect->active_pass, TRUE); > + if (FAILED(hr)) > + effect->active_pass = NULL; > + return hr; > } Can't you just set active_pass only if d3dx9_apply_pass_states() succeeds, instead?

2 1

Re: dmusic/tests: Add some IDirectMusic_SetDirectSound() tests.
by Marvin May 4, 2017

May 4, 2017

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=30792 Your paranoid android. === wvistau64 (32 bit dmusic) === dmusic.c:143: Test failed: DirectSoundCreate failed: 88780078 00c4:dmusic: unhandled exception c0000005 at 73C598FB

1 0

Re: [PATCH 04/10] d3dx9/tests: Use compare_float() in test_D3DXSHEvalSphericalLight().
by Matteo Bruni May 4, 2017

May 4, 2017

2017-05-04 12:05 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > - ok(relative_error(expected, test[l].red_received[j]) < 0.0005f, > - "Red: case %u, order %u: expected[%u] = %f, received %f\n", l, order, j, expected, test[l].red_received[j]); > + equal = compare_float(expected, test[l].red_received[j], 512); > + ok(equal || (fabs(expected) < 1.0e-6f && fabs(test[l].red_received[j]) < 1.0e-6f), > + "Red: case %u, order %u: expected[%u] = %.8e, received %.8e.\n", > + l, order, j, expected, test[l].red_received[j]); I guess those are mostly to make our implementation pass the test. Did you have a look at it by any chance?

2 1

Re: [PATCH] d3dx9: Return shader functions in d3dx9_base_effect_get_pass_desc().
by Marvin May 4, 2017

May 4, 2017

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=30788 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [v4 PATCH 1/4] mfplat: Implement MFTRegister
by Alexandre Julliard May 4, 2017

May 4, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + if (cinput && input_types) > + { > + size = cinput * sizeof(MFT_REGISTER_TYPE_INFO); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + memcpy(types, input_types, size); > + > + ret = RegSetValueExW(hclsid, inputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); Why do you need to make a copy? > + if (coutput && output_types) > + { > + size = cinput * sizeof(MFT_REGISTER_TYPE_INFO); I'm guessing you want coutput here. -- Alexandre Julliard julliard(a)winehq.org

1 0

pulse/alsa option in wine cfg audio tab
by CARLOS RODRIGUEZ May 4, 2017

May 4, 2017

>Are there bugs reported for those?>Yeah has been reported sometime agohttps://bugs.winehq.org/show_bug.cgi?id=41147

1 0

Re: [v2 5/5] d3dx9: Match native out of bounds array selector index handling.
by Paul Gofman May 4, 2017

May 4, 2017

Sorry, please ignore this last patch in the series. I found it is not correct for some cases and I will come up with more tests and corrected version separately. On 05/04/2017 01:33 AM, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/effect.c | 25 ++++++++++++++++--------- > dlls/d3dx9_36/tests/effect.c | 17 ++++++----------- > 2 files changed, 22 insertions(+), 20 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 1ecd32e..a3511c8 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -1056,7 +1056,7 @@ static HRESULT d3dx9_base_effect_get_pass_desc(struct d3dx9_base_effect *base, > BOOL param_dirty; > > if (FAILED(hr = d3dx9_get_param_value_ptr(pass, &pass->states[i], &param_value, &param, > - TRUE, &param_dirty))) > + FALSE, &param_dirty))) > return hr; > > if (!param->object_id) > @@ -2647,7 +2647,9 @@ static HRESULT d3dx9_get_param_value_ptr(struct d3dx_pass *pass, struct d3dx_sta > FIXME("Preshader structure is null.\n"); > return D3DERR_INVALIDCALL; > } > - if (update_all || is_param_eval_input_dirty(param->param_eval)) > + /* According to the tests, native d3dx handles the case of array index evaluated to -1 > + * in a specific way. */ > + if (is_param_eval_input_dirty(param->param_eval) || state->index == 0xffffffffu) > { > if (FAILED(hr = d3dx_evaluate_parameter(param->param_eval, &array_idx_param, > &array_idx, update_all))) > @@ -2660,6 +2662,11 @@ static HRESULT d3dx9_get_param_value_ptr(struct d3dx_pass *pass, struct d3dx_sta > ref_param = param->referenced_param; > TRACE("Array index %u, stored array index %u, element_count %u.\n", array_idx, state->index, > ref_param->element_count); > + if (array_idx == 0xffffffffu) > + { > + WARN("Array index is -1, setting to 0.\n"); > + array_idx = 0; > + } > > if (array_idx >= ref_param->element_count) > { > @@ -2920,13 +2927,11 @@ static HRESULT d3dx9_apply_state(struct ID3DXEffectImpl *effect, struct d3dx_pas > if (FAILED(hr = d3dx9_get_param_value_ptr(pass, state, &param_value, &param, > update_all, &param_dirty))) > { > - if (hr == E_FAIL) > + if (!update_all && hr == E_FAIL) > { > - /* Native d3dx9 returns D3D_OK from BeginPass or Commit involving > + /* Native d3dx9 returns D3D_OK from Commit involving > * out of bounds array access and does not touch the affected > - * state, except for BeginPass when the out of bounds array index > - * depends on dirty parameters. The latter case is supposed to > - * return E_FAIL but is currently TODO. */ > + * state. */ > WARN("Returning D3D_OK on out of bounds array access.\n"); > return D3D_OK; > } > @@ -6101,6 +6106,7 @@ static HRESULT d3dx9_parse_resource(struct d3dx9_base_effect *base, const char * > if (FAILED(hr = d3dx9_copy_data(base, param->object_id, ptr))) > return hr; > hr = d3dx9_parse_array_selector(base, param); > + state->index = 0xffffffffu; > break; > > default: > @@ -6226,10 +6232,11 @@ static HRESULT d3dx9_parse_effect(struct d3dx9_base_effect *base, const char *da > > for (i = 0; i < base->parameter_count; ++i) > { > - if (FAILED(hr = d3dx_pool_sync_shared_parameter(base->pool, &base->parameters[i]))) > - goto err_out; > walk_parameter_tree(&base->parameters[i], param_set_top_level_param, > &base->parameters[i]); > + set_dirty(&base->parameters[i]); > + if (FAILED(hr = d3dx_pool_sync_shared_parameter(base->pool, &base->parameters[i]))) > + goto err_out; > } > return D3D_OK; > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 7f7487e..c6713af 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -4658,14 +4658,12 @@ static void test_effect_out_of_bounds_selector(IDirect3DDevice9 *device) > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > hr = effect->lpVtbl->BeginPass(effect, 1); > - todo_wine ok(hr == E_FAIL, "Got result %#x.\n", hr); > - if (SUCCEEDED(hr)) > - effect->lpVtbl->EndPass(effect); > + ok(hr == E_FAIL, "Got result %#x.\n", hr); > > hr = effect->lpVtbl->BeginPass(effect, 1); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > - test_effect_preshader_compare_shader(device, 2, TRUE); > + test_effect_preshader_compare_shader(device, 2, FALSE); > > hr = effect->lpVtbl->EndPass(effect); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > @@ -4678,9 +4676,7 @@ static void test_effect_out_of_bounds_selector(IDirect3DDevice9 *device) > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > hr = effect->lpVtbl->BeginPass(effect, 1); > - todo_wine ok(hr == E_FAIL, "Got result %#x.\n", hr); > - if (SUCCEEDED(hr)) > - hr = effect->lpVtbl->EndPass(effect); > + ok(hr == E_FAIL, "Got result %#x.\n", hr); > > hr = IDirect3DDevice9_GetVertexShader(device, &vshader); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > @@ -4689,7 +4685,7 @@ static void test_effect_out_of_bounds_selector(IDirect3DDevice9 *device) > hr = effect->lpVtbl->BeginPass(effect, 1); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > - test_effect_preshader_compare_shader(device, 2, TRUE); > + test_effect_preshader_compare_shader(device, 2, FALSE); > > hr = effect->lpVtbl->EndPass(effect); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > @@ -4701,7 +4697,7 @@ static void test_effect_out_of_bounds_selector(IDirect3DDevice9 *device) > hr = effect->lpVtbl->BeginPass(effect, 1); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > - test_effect_preshader_compare_shader(device, 0, TRUE); > + test_effect_preshader_compare_shader(device, 0, FALSE); > > hr = IDirect3DDevice9_SetVertexShader(device, NULL); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > @@ -6266,10 +6262,9 @@ static void test_effect_get_pass_desc(IDirect3DDevice9 *device) > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > hr = effect->lpVtbl->GetPassDesc(effect, pass, &desc); > - todo_wine > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > - test_effect_preshader_compare_shader_bytecode(desc.pVertexShaderFunction, 0, 0, TRUE); > + test_effect_preshader_compare_shader_bytecode(desc.pVertexShaderFunction, 0, 0, FALSE); > > fvect.z = 2.0f; > hr = effect->lpVtbl->SetVector(effect, "g_iVect", &fvect);

1 0

Re: [PATCH] comctl32/tests: Add tests for mouse right-click in a treeview control
by Alexandre Julliard May 4, 2017

May 4, 2017

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > From: Hugh McMaster <hugh.mcmaster(a)outlook.com> > > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/comctl32/tests/treeview.c | 77 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 77 insertions(+) This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M comctl32.dll -p comctl32_test.exe.so treeview && touch treeview.ok treeview.c:2653: Test failed: right click sequence: the msg sequence is not complete: expected 0000 - actual 000f treeview.c:2654: Test failed: parent right click sequence: the msg sequence is not complete: expected 0000 - actual 004e Makefile:968: recipe for target 'treeview.ok' failed make[1]: *** [treeview.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 4/4] d3dx9: Match native out of bounds array selector index handling.
by Marvin May 3, 2017

May 3, 2017

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=30756 Your paranoid android. === build (build) === Make failed

2 1