wine-devel November 2016

wine-devel@winehq.org

56 participants
194 discussions

Wineconf wrap up
by Jeremy White 24 Nov '16

24 Nov '16

Hi Folks, I thought I would take a minute to write a summary of the events of the weekend, and that start a thread where others could chime in. It was a great event; a traditional wineconf with cheer and conversations, and even sometimes productive meetings. Here were our working notes for the weekend: https://www.winehq.org/~jwhite/wineconf_2016.pdf The plan for next year is to have the Wine conference in Poland next fall. We are going to try to broaden our reach; inviting users and others to come to the conference as well. Aric is going to try to help coordinate that structural growth. Mechanically, we did decide that the Google hangout was not intrusive, so we will likely try to repeat that next year. (We would like it to not require us to manually accept each person, if possible). Many others volunteered to help in a variety of ways; I did not take rigorous notes of this during the conference, so hopefully others will step forward with that information (or we'll all shame them into remembering <evil grin>). It was a joy to see you all! Cheers, Jeremy p.s. For my part, one key part is that we are going to attempt to make one or two of the Debian Jessie systems hosted here at CodeWeavers run make test to successful completion. We are going to accept the fact that we have several timing dependent tests; so 'success' is going to be something like the following: make test -o make test -o make test -o make test In a similar vein, we are going to try to establish a 'diffing' logic for the winetest bot. So if there are n failures that happen routinely, and a new patch arrives, so long as only those same failures remain, the patch will be considered suitable. The advantage to that approach is that we can also apply it to platforms such as the Mac, where we are no where close to running green. Michael will help Francois with this once he is done with his travels. I agreed to lock Francois and the d3d guys in the server room until we saw progress on the make test front; I think that was the sum total of what I volunteered to do.

4 5

Re: Donat Enikeev : crypt32/tests: Fix chain tests failure with cs.standford.edu certificates.
by Huw Davies 24 Nov '16

24 Nov '16

> On 21 Nov 2016, at 21:28, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Module: wine > Branch: master > Commit: 8a4508cecc4a6e46da200c85aa7d62515041f6e2 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=8a4508cecc4a6e46da200c85a… > > Author: Donat Enikeev <donat(a)enikeev.net> > Date: Sat Nov 19 21:12:30 2016 +0300 > > crypt32/tests: Fix chain tests failure with cs.standford.edu certificates. > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> > > --- > > dlls/crypt32/tests/chain.c | 658 ++++++++++++++++++++++++--------------------- > 1 file changed, 352 insertions(+), 306 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=8a4508cecc4a6e46da200… Hi Donat, This has caused failures on some of Francois’ XP VMs. For example: http://test.winehq.org/data/8a4508cecc4a6e46da200c85aa7d62515041f6e2/xp_fg-… Could you take a look? Thanks, Huw.

6 12

Re: [PATCH] wincodecs: Trigger conversion to target format in WriteSource()
by Dmitry Timoshkov 23 Nov '16

23 Nov '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > - if (!IsEqualGUID(&src_format, format)) > - { > - /* FIXME: should use WICConvertBitmapSource to convert */ > - ERR("format %s unsupported\n", debugstr_guid(&src_format)); > - return E_FAIL; > + hr = IWICBitmapFrameEncode_SetPixelFormat(iface, &src_format); > + if (FAILED(hr)) return hr; > } Despite the removing a questionable FIXME this part of the code won't do what you think it does. Besides, since there is no a single todo_wine removed with this patch adding a bunch of tests for different encoders is needed to show that the automatic conversion is really supposed to happen, and that it doesn't depend on the implementation detail in some of the encoders. According to my testing not every encoder does this kind of thing, especially when a conversion needs a palette. -- Dmitry.

2 2

Re: [PATCH] wincodecs: Recognize FilterOption property in PNG encoder
by Vincent Povirk 23 Nov '16

23 Nov '16

We should either set this option when encoding, or print a fixme. I think setting it is easy enough.

1 0

Re: [PATCH] quartz: Use straight assignments instead of CopyRect().
by Michael Stefaniuc 23 Nov '16

23 Nov '16

On 11/22/2016 08:01 PM, Hadrien Boizard wrote: > Signed-off-by: Hadrien Boizard <h.boizard(a)gmail.com> > --- > dlls/quartz/videorenderer.c | 8 ++++---- > dlls/quartz/vmr9.c | 8 ++++---- > 2 files changed, 8 insertions(+), 8 deletions(-) > > > 0001-quartz-Use-straight-assignments-instead-of-CopyRect.patch > > > diff --git a/dlls/quartz/videorenderer.c b/dlls/quartz/videorenderer.c > index 61f08f5..6631ccd 100644 > --- a/dlls/quartz/videorenderer.c > +++ b/dlls/quartz/videorenderer.c > @@ -483,7 +483,7 @@ static const BaseWindowFuncTable renderer_BaseWindowFuncTable = { > static HRESULT WINAPI VideoRenderer_GetSourceRect(BaseControlVideo* iface, RECT *pSourceRect) > { > VideoRendererImpl *This = impl_from_BaseControlVideo(iface); > - CopyRect(pSourceRect,&This->SourceRect); > + *pSourceRect = This->SourceRect; NACK, this is not a no-op change. CopyRect() also checks for NULL rect pointers so it protects against NULL pSourceRect. With your change apps would crash if they do that. The proper fix is to add tests for NULL rects and return the proper error in those functions. Or at least add code like: if (!pSourceRect) return E_POINTER; No clue if Andrew Eikum is willing to accept that without tests. E_INVALIDARG would be also a plausible error code. bye michael

1 0

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.
by Dmitry Timoshkov 23 Nov '16

23 Nov '16

Huw Davies <huw(a)codeweavers.com> wrote: > + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); > + if (IsWindowUnicode(hwnd)) > + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); > + else > + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always return a unicode string regardless of wheather IsWindowUnicode() is broken or not, otherwise a lot of applications would misbehave in weird ways. This needs further investigation. -- Dmitry.

2 7

Re: [PATCH 09/10] kernel32/tests: Added more named pipe tests.
by Marvin 23 Nov '16

23 Nov '16

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=26858 Your paranoid android. === w864 (64 bit pipe) === pipe.c:2575: Test failed: FlushFileBuffers failed: 87 pipe.c:2575: Test failed: FlushFileBuffers failed: 87

1 0

Re: [PATCH] msvcrt: Add _lfind_s
by Piotr Caban 23 Nov '16

23 Nov '16

Hi, On 11/22/16 16:36, Daniel Lehman wrote: > dlls/msvcrt/misc.c | 26 +++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt/tests/misc.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++ Please also update other spec files. > + /* simple samples */ > + /* simple sample - not found */ Could you please also remove these comments? They are not very useful. Thank you, Piotr

1 0

Re: [08/23] wined3d: Allow viewport to be out-of-bounds if using offscreen target.
by Andrew Wesie 23 Nov '16

23 Nov '16

Assuming that viewport_test in d3d9/tests/visual.c is wrong only when render_offscreen is true, is there anyway to fix that test? Or should viewport_test be removed? The reason for the patch is that Overwatch renders to a 2D texture some UI elements. If the viewport is not what is expected, then the output is wrong (e.g. the UI elements are the wrong size or drawn at the wrong place on the texture). -Andrew On Sun, Nov 13, 2016 at 12:35 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/state.c | 42 ++++++++++++++++++++++-------------------- > 1 file changed, 22 insertions(+), 20 deletions(-) > > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index cd3763c..ed20e325 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -4617,26 +4617,6 @@ static void viewport_miscpart(struct > wined3d_context *context, const struct wine > struct wined3d_viewport vp = state->viewport; > unsigned int width, height; > > - if (target) > - { > - if (vp.width > target->width) > - vp.width = target->width; > - if (vp.height > target->height) > - vp.height = target->height; > - > - wined3d_rendertarget_view_get_drawable_size(target, context, > &width, &height); > - } > - else if (depth_stencil) > - { > - width = depth_stencil->width; > - height = depth_stencil->height; > - } > - else > - { > - FIXME("No attachments draw calls not supported.\n"); > - return; > - } > - > gl_info->gl_ops.gl.p_glDepthRange(vp.min_z, vp.max_z); > checkGLcall("glDepthRange"); > /* Note: GL requires lower left, DirectX supplies upper left. This is > @@ -4644,7 +4624,29 @@ static void viewport_miscpart(struct > wined3d_context *context, const struct wine > if (context->render_offscreen) > gl_info->gl_ops.gl.p_glViewport(vp.x, vp.y, vp.width, vp.height); > else > + { > + if (target) > + { > + if (vp.width > target->width) > + vp.width = target->width; > + if (vp.height > target->height) > + vp.height = target->height; > + > + wined3d_rendertarget_view_get_drawable_size(target, context, > &width, &height); > + } > + else if (depth_stencil) > + { > + width = depth_stencil->width; > + height = depth_stencil->height; > + } > + else > + { > + FIXME("No attachments draw calls not supported.\n"); > + return; > + } > + > gl_info->gl_ops.gl.p_glViewport(vp.x, (height - (vp.y + > vp.height)), vp.width, vp.height); > + } > checkGLcall("glViewport"); > } > > -- > 2.7.4 > >

2 3

Re: [v2 1/3] wined3d: Implement return instruction.
by Józef Kucia 23 Nov '16

23 Nov '16

On Fri, Nov 18, 2016 at 6:46 AM, Andrew Wesie <awesie(a)gmail.com> wrote: > --- a/dlls/wined3d/shader.c > +++ b/dlls/wined3d/shader.c > @@ -2028,6 +2028,7 @@ void shader_generate_main(const struct wined3d_shader *shader, struct wined3d_st > struct wined3d_shader_tex_mx tex_mx; > struct wined3d_shader_context ctx; > const DWORD *ptr = byte_code; > + enum WINED3D_SHADER_INSTRUCTION_HANDLER last_opcode = WINED3DSIH_TABLE_SIZE; > > /* Initialize current parsing state. */ > tex_mx.current_row = 0; > @@ -2062,6 +2063,16 @@ void shader_generate_main(const struct wined3d_shader *shader, struct wined3d_st > > /* Call appropriate function for output target */ > device->shader_backend->shader_handle_instruction(&ins); > + last_opcode = ins.handler_idx; > + } > + > + if (last_opcode != WINED3DSIH_RET) > + { > + /* Force a return instruction at the end of function body. */ > + memset(&ins, 0, sizeof(ins)); > + ins.ctx = &ctx; > + ins.handler_idx = WINED3DSIH_RET; > + device->shader_backend->shader_handle_instruction(&ins); > } > } Would it make sense to always generate a shader epilogue for shader model <= 3, and handle the RET instruction in a special way for shader model >= 4?

2 3

← Newer
1
2
3
4
5
6
7
8
9
...
20
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2016