July 2015 - Wine-Devel - list.winehq.org

Re: [1/7] msvcirt: Implement ios locking control (try 2)
by Marvin July 8, 2015

July 8, 2015

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

1 0

Re: [1/4] msvcirt: Implement ios locking control
by Piotr Caban July 8, 2015

July 8, 2015

Hi Iván, On 07/07/15 21:00, Iván Matellanes wrote: > + /* locking */ > + ios_obj.do_lock = 1; > + p_ios_clrlock(&ios_obj); > + ok(ios_obj.do_lock == 1, "expected 1 got %d\n", ios_obj.do_lock); > + ios_obj.do_lock = 0; > + p_ios_clrlock(&ios_obj); > + ok(ios_obj.do_lock == 1, "expected 1 got %d\n", ios_obj.do_lock); > + p_ios_setlock(&ios_obj); > + ok(ios_obj.do_lock == 0, "expected 0 got %d\n", ios_obj.do_lock); > + ios_obj.do_lock = -1; > + p_ios_setlock(&ios_obj); > + ok(ios_obj.do_lock == -2, "expected -2 got %d\n", ios_obj.do_lock); Please add a test that shows what happens with this->sb->do_lock value when ios_setlock and ios_clrlock are called (it should also be updated). Thanks, Piotr

2 1

Re: [2/2] server: Add fallback to desktop keystate in get_key_state wineserver call.
by Marvin July 8, 2015

July 8, 2015

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=15142 Your paranoid android. === wvistau64 (64 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

1 0

Re: [PATCH 4/5] wined3d: Add a setting for the maximum OpenGL version to use.
by Henri Verbeet July 8, 2015

July 8, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > if (context_debug_output_enabled(gl_info)) > + ctx_flags = WGL_CONTEXT_DEBUG_BIT_ARB; > + ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_MAJOR_VERSION_ARB; > + ctx_attribs[ctx_attrib_idx++] = gl_info->selected_gl_version >> 16; > + ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_MINOR_VERSION_ARB; > + ctx_attribs[ctx_attrib_idx++] = gl_info->selected_gl_version & 0xffff; > + if (gl_info->selected_gl_version >= MAKEDWORD_VERSION(3, 2)) > + ctx_flags |= WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB; > + if (ctx_flags) > { > ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_FLAGS_ARB; > - ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_DEBUG_BIT_ARB; > + ctx_attribs[ctx_attrib_idx++] = ctx_flags; > } > ctx_attribs[ctx_attrib_idx] = 0; > > if (!(ctx = gl_info->p_wglCreateContextAttribsARB(hdc, share_ctx, ctx_attribs))) > { > - ERR("Failed to create a WGL context.\n"); > - context_release(ret); > - goto out; > + if (ctx_flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB) > + { > + ctx_attribs[ctx_attrib_idx - 1] &= ~WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB; > + if (!(ctx = gl_info->p_wglCreateContextAttribsARB(hdc, share_ctx, ctx_attribs))) > + { > + ERR("Failed to create a WGL context.\n"); > + context_release(ret); > + goto out; > + } > + } > } > } I think this is starting to become complex enough that we'd probably benefit from a helper function to be able to share some of this with wined3d_adapter_init(). > + glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &context_profile); > + if (glGetError() != GL_NO_ERROR) > + context_profile = 0; Should this perhaps just check for gl_info->p_wglCreateContextAttribsARB instead of eating errors? > + for (i = 0; i < ARRAY_SIZE(supported_gl_versions); ++i) > + { > + if (supported_gl_versions[i] <= wined3d_settings.max_gl_version) > + { > + if (supported_gl_versions[i] != wined3d_settings.max_gl_version) > + ERR_(winediag)("Requested GL version %u.%u which is unsupported, trying version %u.%u instead.\n", > + wined3d_settings.max_gl_version >> 16, wined3d_settings.max_gl_version & 0xffff, > + supported_gl_versions[i] >> 16, supported_gl_versions[i] & 0xffff); > + break; > + } > + } > + if (i == ARRAY_SIZE(supported_gl_versions)) > + { > + ERR_(winediag)("Requested invalid GL version %u.%u.\n", > + wined3d_settings.max_gl_version >> 16, wined3d_settings.max_gl_version & 0xffff); > + i = ARRAY_SIZE(supported_gl_versions) - 1; > + } This is a bit different than what I had in mind. I think max_gl_version should just be a maximum, and e.g. specifying 4.4 should just result in 3.2 at the moment. I think the winediag message should just happen if the registry setting is set, regardless of its actual value. (Except possibly if it's equal to the default value.) I.e. we also want to know if someone sets e.g. 3.2 while the default is currently 1.0 when reporting a bug. > + if (!get_config_key(hkey, appkey, "MaxGLVersion", buffer, size)) > + { > + unsigned int major, minor; > + > + if (sscanf(buffer, "%u.%u", &major, &minor) == 2) > + wined3d_settings.max_gl_version = MAKEDWORD_VERSION(major, minor); > + else > + ERR_(winediag)("Couldn't parse the requested maximum OpenGL version.\n"); > + } I'd make this a DWORD, if nothing else for consistency with MaxShaderModelVS etc. Perhaps "MaxVersionGL" would also more consistent for the naming, I'm not sure.

2 6

Re: [1/2] user32/tests: Add tests for calling GetKeyState from thread without message queue.
by Sebastian Lackner July 8, 2015

July 8, 2015

On 08.07.2015 13:31, Sebastian Lackner wrote: > For https://bugs.winehq.org/show_bug.cgi?id=27238 > > The test is marked as broken on VMs > Win2003, but manually testing confirms > that it still works the same way on Windows 7. There must be a difference > between simulated keyboard input and real keyboard input. > > NOTE: SendInput doesn't make a difference. > > --- > dlls/user32/tests/input.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > The test failures on wvistau64 are not caused by my patch. Seems to be "just another random issue". ;) All tests passed on a second attempt: https://newtestbot.winehq.org/JobDetails.pl?Key=15143

1 0

Re: [1/2] user32/tests: Add tests for calling GetKeyState from thread without message queue.
by Marvin July 8, 2015

July 8, 2015

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=15141 Your paranoid android. === wvistau64 (32 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

1 0

Re: [PATCH 3/4] wined3d: Clip blits from / to the front buffer to the GL drawable.
by Henri Verbeet July 8, 2015

July 8, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -void surface_translate_drawable_coords(const struct wined3d_surface *surface, HWND window, RECT *rect) > +BOOL surface_clip_drawable_coords(const struct wined3d_surface *surface, HWND window, > + RECT *screen_rect, RECT *other) Can we please call these "src_rect" and "dst_rect" instead of "screen_rect" and "other"? It probably wouldn't hurt to mention "blt" somewhere in the function name either. > + ClientToScreen(window, &offset); ... > - ScreenToClient(window, &offset); > - OffsetRect(rect, offset.x, offset.y); > + /* Finally, translate the screen coordinate rectangle to client coordinates. */ > + OffsetRect(screen_rect, -offset.x, -offset.y); That change seems pretty pointless. > +BOOL wined3d_clip_blit(const RECT *clip_rect, RECT *clipped, RECT *other) "src_rect", "dst_rect".

2 2

Re: kernel32/tests: Attempt to avoid timeouts by increasing the baud rate.
by Marvin July 8, 2015

July 8, 2015

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=15126 Your paranoid android. === w2000pro (32 bit comm) === comm.c:1552: test_AbortWaitCts timeout 500 handle 00000368 comm.c:1519: Changing CommMask on the fly for handle 00000368 after timeout 500 === w2008s64 (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 000000BC comm.c:1519: Changing CommMask on the fly for handle 000000BC after timeout 500

2 1

#include <hidclass.h>
by Aric Stewart July 8, 2015

July 8, 2015

Hi, So when my patch for include/ddk/hidport.h got included Alexandre add this line to the top: #include <hidclass.h> The problem is that my hidclass.sys work stopped building for me. In file included from ../../../wine-git/dlls/hidclass.sys/hid.h:27: ../../../wine-git/include/ddk/hidport.h:22:10: error: 'hidclass.h' file not found with <angled> include; use "quotes" instead #include <hidclass.h> ^~~~~~~~~~~~ "hidclass.h" 1 error generated. Is this a problem with my build setup or something else? hidclass.h is located in include/ddk/hidclass.h thanks, -aric

2 1

Re: [PATCH 1/5] wined3d: Use the correct texture coordinates in swapchain_blit() in the non-glBlitFramebuffer, NP2 case.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c > index 146f5d6..141abc2 100644 > --- a/dlls/wined3d/swapchain.c > +++ b/dlls/wined3d/swapchain.c > @@ -280,21 +280,21 @@ HRESULT CDECL wined3d_swapchain_get_gamma_ramp(const struct wined3d_swapchain *s > > /* A GL context is provided by the caller */ > static void swapchain_blit(const struct wined3d_swapchain *swapchain, > - struct wined3d_context *context, const RECT *src_rect, const RECT *dst_rect) > + struct wined3d_context *context, unsigned int src_w, unsigned int src_h, > + const RECT *src_rect, const RECT *dst_rect) > { > struct wined3d_surface *backbuffer = surface_from_resource( > wined3d_texture_get_sub_resource(swapchain->back_buffers[0], 0)); > - UINT src_w = src_rect->right - src_rect->left; > - UINT src_h = src_rect->bottom - src_rect->top; > GLenum gl_filter; > const struct wined3d_gl_info *gl_info = context->gl_info; > RECT win_rect; > UINT win_h; > > - TRACE("swapchain %p, context %p, src_rect %s, dst_rect %s.\n", > - swapchain, context, wine_dbgstr_rect(src_rect), wine_dbgstr_rect(dst_rect)); > + TRACE("swapchain %p, context %p, src_w %u, src_h %u, src_rect %s, dst_rect %s.\n", > + swapchain, context, src_w, src_h, wine_dbgstr_rect(src_rect), wine_dbgstr_rect(dst_rect)); > > - if (src_w == dst_rect->right - dst_rect->left && src_h == dst_rect->bottom - dst_rect->top) > + if (src_rect->right - src_rect->left == dst_rect->right - dst_rect->left > + && src_rect->bottom - src_rect->top == dst_rect->bottom - dst_rect->top) > gl_filter = GL_NEAREST; > else > gl_filter = GL_LINEAR; > @@ -528,7 +528,7 @@ static void swapchain_gl_present(struct wined3d_swapchain *swapchain, const RECT > if (swapchain->desc.swap_effect == WINED3D_SWAP_EFFECT_FLIP && !once++) > FIXME("WINED3D_SWAP_EFFECT_FLIP not implemented.\n"); > > - swapchain_blit(swapchain, context, &src_rect, &dst_rect); > + swapchain_blit(swapchain, context, back_buffer->pow2Width, back_buffer->pow2Height, &src_rect, &dst_rect); > } > > if (swapchain->num_contexts > 1) I may be missing something subtle here, but wouldn't it be better to just replace src_w/wrc_h with backbuffer->pow2Width/backbuffer->powe2Height in the "if (backbuffer->container->flags & WINED3D_TEXTURE_NORMALIZED_COORDS)" block that scales the texture coordinates?

3 3