November 2016 - Wine-Devel - list.winehq.org

Re: [v2 2/3] d3d10core/tests: Add test for nointerpolation support.
by Józef Kucia Nov. 21, 2016

Nov. 21, 2016

On Sun, Nov 20, 2016 at 6:36 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > + struct VertexOut We generally do not use PascalCase. Please use snake_case. > + 0x43425844, 0x27846ba6, 0xd14f79cc, 0xc27a566f, 0xe83b028c, 0x00000001, 0x00000240, 0x00000005, > + 0x00000034, 0x0000008c, 0x000000c0, 0x00000114, 0x000001c4, 0x46454452, 0x00000050, 0x00000000, > + 0x00000000, 0x00000000, 0x0000001c, 0xfffe0400, 0x00000100, 0x0000001c, 0x7263694d, 0x666f736f, > + 0x52282074, 0x4c482029, 0x53204c53, 0x65646168, 0x6f432072, 0x6c69706d, 0x36207265, 0x392e332e, > + 0x2e303036, 0x38333631, 0xabab0034, 0x4e475349, 0x0000002c, 0x00000001, 0x00000008, 0x00000020, > + 0x00000000, 0x00000000, 0x00000003, 0x00000000, 0x00000f0f, 0x49534f50, 0x4e4f4954, 0xababab00, > + 0x4e47534f, 0x0000004c, 0x00000002, 0x00000008, 0x00000038, 0x00000000, 0x00000001, 0x00000003, > + 0x00000000, 0x0000000f, 0x00000044, 0x00000000, 0x00000000, 0x00000003, 0x00000001, 0x0000000f, > + 0x505f5653, 0x5449534f, 0x004e4f49, 0x4f4c4f43, 0xabab0052, 0x52444853, 0x000000a8, 0x00010040, > + 0x0000002a, 0x0300005f, 0x001010f2, 0x00000000, 0x04000067, 0x001020f2, 0x00000000, 0x00000001, > + 0x03000065, 0x001020f2, 0x00000001, 0x02000068, 0x00000001, 0x05000036, 0x001020f2, 0x00000000, > + 0x00101e46, 0x00000000, 0x07000031, 0x00100012, 0x00000000, 0x0010100a, 0x00000000, 0x00004001, > + 0x00000000, 0x0f000037, 0x001020f2, 0x00000001, 0x00100006, 0x00000000, 0x00004002, 0x00000000, > + 0x00000000, 0x3f800000, 0x3f800000, 0x00004002, 0x3f800000, 0x00000000, 0x00000000, 0x3f800000, > + 0x0100003e, 0x54415453, 0x00000074, 0x00000004, 0x00000001, 0x00000000, 0x00000003, 0x00000001, > + 0x00000000, 0x00000000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, > + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000001, 0x00000001, > + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 In order to make the shader bytecode a little bit smaller, the shader code should be compiled with /Qstrip_debug and /Qstrip_reflect options. This applies to other patches as well, but please do not resend before Henri's comments. > + static const struct vec2 quad[] = > + { > + { -1.0f, -1.0f }, > + { -1.0f, 1.0f }, > + { 1.0f, -1.0f }, > + { 1.0f, 1.0f }, > + }; Float literals are usually aligned.

1 0

Re: [v2 1/3] wined3d: Add support for flat interpolation in shaders.
by Józef Kucia Nov. 21, 2016

Nov. 21, 2016

This is still broken in the same way as the first version: fixme:d3d_shader:print_glsl_info_log error: interpolation modifier mismatch for varying parameter (named ps_link1) between shader stages On Sun, Nov 20, 2016 at 6:36 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/glsl_shader.c | 47 ++++++++++++++++++++++++++++++------------ > dlls/wined3d/shader.c | 7 +++++++ > dlls/wined3d/wined3d_private.h | 1 + > 3 files changed, 42 insertions(+), 13 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 9e9c83b..5df1827 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -2162,7 +2162,14 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > UINT in_count = min(vec4_varyings(version->major, gl_info), shader->limits->packed_input); > > if (ps_args->vp_mode == vertexshader) > - declare_in_varying(gl_info, buffer, FALSE, "vec4 %s_link[%u];\n", prefix, in_count); > + { > + unsigned int j; > + for (j = 0; j < in_count; j++) > + { > + declare_in_varying(gl_info, buffer, shader->u.ps.input_reg_flags[j] == WINED3DSIM_CONSTANT, > + "vec4 %s_link%u;\n", prefix, j); > + } > + } We should add a FIXME() message for other unsupported interpolation modes. We do not want to hide that those are still not implemented. Currently, we have a FIXME() for the dcl_input_ps instruction. > + else if (ins.handler_idx == WINED3DSIH_DCL_INPUT_PS) > + { > + unsigned int reg_idx = ins.declaration.dst.reg.idx[0].offset; > + reg_maps->input_registers |= 1u << reg_idx; > + /* We can assume we are in the pixel shader */ > + shader->u.ps.input_reg_flags[reg_idx] = ins.flags; > + } We tend to check the shader type and print a FIXME() message in similar cases instead of adding a comment. See WINED3DSIH_DCL_INPUT_PRIMITIVE, WINED3DSIH_DCL_OUTPUT_TOPOLOGY and WINED3DSIH_DCL_VERTICES_OUT. > /* Pixel shader input semantics */ > DWORD input_reg_map[MAX_REG_INPUT]; > BOOL input_reg_used[MAX_REG_INPUT]; > + enum wined3d_shader_interpolation_mode input_reg_flags[MAX_REG_INPUT]; I think we could use better name for this variable, e.g. "input_reg_interpolation_mode" or "interpolation_mode".

1 0

Re: [v2 1/4] wined3d: Implement buffer shader resource views.
by Józef Kucia Nov. 21, 2016

Nov. 21, 2016

I've also submitted a patch series for buffer shader views a while back [1]. My series seems to have better tests. The "lod" parameter handling is probably solved in a nicer way as well. On Sun, Nov 20, 2016 at 6:16 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > + case GL_TEXTURE_BUFFER: > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_BUFFER, 0); > + checkGLcall("glBindTexture"); > + break; I suppose that a dummy texture is generally required in order to get correct results for unbound shader views. > + {"GL_ARB_texture_buffer_range", ARB_TEXTURE_BUFFER_RANGE }, This extension has to be also added to the "core_extensions" table. > +static void wined3d_shader_resource_view_create_buffer_view(struct wined3d_shader_resource_view *view, > + const struct wined3d_shader_resource_view_desc *desc, struct wined3d_buffer *buffer, > + const struct wined3d_format *view_format) > +{ > + const struct wined3d_gl_info *gl_info; > + struct wined3d_context *context; > + > + context = context_acquire(buffer->resource.device, NULL); > + gl_info = context->gl_info; > + > + wined3d_buffer_load_location(buffer, context, WINED3D_LOCATION_BUFFER); > + > + gl_info->gl_ops.gl.p_glGenTextures(1, &view->object); > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_BUFFER, view->object); > + > + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object, > + desc->u.buffer.start_idx * view_format->byte_count, desc->u.buffer.count * view_format->byte_count)); It would be nice to check if ARB_texture_buffer_range is supported and fallback to ARB_texture_buffer_object. This might be especially useful for macOS. > + checkGLcall("Create buffer view"); > + > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_BUFFER, 0); > + context_release(context); > +} This might invalidate shader resource bindings. There is no need to unbind the texture buffer, but you need to call "context_invalidate_state(context, STATE_SHADER_RESOURCE_BINDING);". [1] - https://www.winehq.org/pipermail/wine-patches/2016-March/148496.html

1 0

FOSDEM stand
by Marcus Meissner Nov. 19, 2016

Nov. 19, 2016

Hi, (In follow up to the more conference/tradeshow presence topic of Wineconf.) I checked the FOSDEM website and the deadline for stands (small tables) was October 31st, so passed. Ciao, Marcus

1 0

Re: [v2] ntdll: Fix and test exception codes on x86-64.
by Marvin Nov. 18, 2016

Nov. 18, 2016

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=26726 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:594: Test failed: 42: Unexpected eip 0x340000/0x340001 exception: unhandled exception 80000004 at 00340000 exception.c:594: Test failed: 42: Unexpected eip 0x77baed97/0x340001 === w7u (32 bit exception) === exception.c:594: Test failed: 42: Unexpected eip 0x710000/0x710001 exception: unhandled exception 80000004 at 00710000 exception.c:594: Test failed: 42: Unexpected eip 0x77cde34f/0x710001 === w1064 (32 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died) === wvistau64 (64 bit exception) === exception.c:2227: Test failed: 36: Unexpected eip 0x260000/0x260001 exception: unhandled exception 80000004 at 0000000000260000 === w1064 (64 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died)

1 0

Re: [PATCH] dwrite: Make it clear that wine_dbgstr_longlong() output is in hex
by Ken Thomases Nov. 18, 2016

Nov. 18, 2016

If its output is hex, shouldn't wine_dbgstr_longlong() add the "0x" itself? -Ken > On Nov 16, 2016, at 10:57 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dwrite/font.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/dlls/dwrite/font.c b/dlls/dwrite/font.c > index 7672aa6..2e1eab0 100644 > --- a/dlls/dwrite/font.c > +++ b/dlls/dwrite/font.c > @@ -4373,11 +4373,12 @@ static ULONG WINAPI localfontfilestream_Release(IDWriteFontFileStream *iface) > return ref; > } > > -static HRESULT WINAPI localfontfilestream_ReadFileFragment(IDWriteFontFileStream *iface, void const **fragment_start, UINT64 offset, UINT64 fragment_size, void **fragment_context) > +static HRESULT WINAPI localfontfilestream_ReadFileFragment(IDWriteFontFileStream *iface, void const **fragment_start, > + UINT64 offset, UINT64 fragment_size, void **fragment_context) > { > struct dwrite_localfontfilestream *This = impl_from_IDWriteFontFileStream(iface); > > - TRACE_(dwrite_file)("(%p)->(%p, %s, %s, %p)\n",This, fragment_start, > + TRACE_(dwrite_file)("(%p)->(%p, 0x%s, 0x%s, %p)\n", This, fragment_start, > wine_dbgstr_longlong(offset), wine_dbgstr_longlong(fragment_size), fragment_context); > > *fragment_context = NULL; > @@ -5744,7 +5745,7 @@ static HRESULT WINAPI fontfacereference_EnqueueFileFragmentDownloadRequest(IDWri > { > struct dwrite_fontfacereference *This = impl_from_IDWriteFontFaceReference(iface); > > - FIXME("(%p)->(%s %s): stub\n", This, wine_dbgstr_longlong(offset), wine_dbgstr_longlong(size)); > + FIXME("(%p)->(0x%s 0x%s): stub\n", This, wine_dbgstr_longlong(offset), wine_dbgstr_longlong(size)); > > return E_NOTIMPL; > } > -- > 2.10.2 > > >

2 1

x86 User-Mode Instruction Prevention and winehq
by Neri, Ricardo Nov. 18, 2016

Nov. 18, 2016

Hi All, I am working on implementing support for a new feature in the Linux kernel named User-Mode Instruction Prevention that will be present in upcoming Intel processors. In a nutshell, if this feature is present and enabled, a general protection fault will happen if any of the following instructions is executed with CPL > 0. * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register The goal of this feature is to prevent user space applications to read the resources mentioned above. For instance, a user-space application could easily read the descriptor tables and use that to instrument an attack. I am aware that maybe wine (or applications using wine) might want to use some of these instructions. For instance, wine might want to use the sgdt instruction to emulate the VxD driver model. Currently the proposed implementation is as follows: If running in protected mode, always propagate the GP fault to the user space via a sigsegv. If running in vm86 mode, trap the GP fault within the kernel and give the userspace fake values for the aforementioned resources (most likely zeros). Also, UMIP will be able to be disabled via a kernel command-line parameter at boot. I would like to inquire about the current use of these instructions and whether it would be catastrophic for wine to lose access to them. Your feedback will be greatly appreciated. You can see the original patch post here [1]. http://www.spinics.net/lists/kernel/msg2377725.html Thanks and BR, Ricardo

2 6

Re: [PATCH v2] msvcrt: Implement nearbyint and nearbyintf
by Piotr Caban Nov. 18, 2016

Nov. 18, 2016

Hi, it looks like your patch got corrupted by your mail client. Here are some hints about sending patches: https://wiki.winehq.org/Submitting_Patches#Sending_the_patch if you have any questions please let me know. Thanks, Piotr On 18/11/16 00:45, Stefan Silviu wrote: > It now has a fallback if the functions are missing. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41695 > > Signed-off-by: Stefan Silviu <sylviu44(a)gmail.com> > --- > configure | 2 ++ > configure.ac | 2 ++ > .../api-ms-win-crt-math-l1-1-0.spec | 4 ++-- > dlls/msvcrt/math.c | 24 ++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 ++ > dlls/ucrtbase/ucrtbase.spec | 4 ++-- > include/msvcrt/math.h | 3 +++ > 7 files changed, 37 insertions(+), 4 deletions(-) > > diff --git a/configure b/configure > index f91d64d..d347956 100755 > --- a/configure > +++ b/configure > @@ -17121,6 +17121,8 @@ for ac_func in \ > lrintf \ > lround \ > lroundf \ > + nearbyint \ > + nearbyintf \ > powl \ > remainder \ > remainderf \ > diff --git a/configure.ac b/configure.ac > index 2489ac0..9c03fc8 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2554,6 +2554,8 @@ AC_CHECK_FUNCS(\ > lrintf \ > lround \ > lroundf \ > + nearbyint \ > + nearbyintf \ > powl \ > remainder \ > remainderf \ > diff --git a/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > b/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > index f886b97..b781276 100644 > --- a/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > +++ b/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > @@ -291,8 +291,8 @@ > @ stub nan > @ stub nanf > @ stub nanl > -@ stub nearbyint > -@ stub nearbyintf > +@ cdecl nearbyint(double) ucrtbase.nearbyint > +@ cdecl nearbyintf(float) ucrtbase.nearbyintf > @ stub nearbyintl > @ cdecl nextafter(double double) ucrtbase.nextafter > @ cdecl nextafterf(float float) ucrtbase.nextafterf > diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index e87151a..32c32b0 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -1354,6 +1354,30 @@ double CDECL MSVCRT__yn(int order, double num) > } > > /********************************************************************* > + * _nearbyint (MSVCRT.@) > + */ > +double CDECL MSVCRT_nearbyint(double num) > +{ > + #ifdef HAVE_NEARBYINT > + return nearbyint(num); > + #else > + return num >= 0 ? floor(num + 0.5) : ceil(num - 0.5); > + #endif > +} > + > +/********************************************************************* > + * _nearbyintf (MSVCRT.@) > + */ > +float CDECL MSVCRT_nearbyintf(float num) > +{ > + #ifdef HAVE_NEARBYINTF > + return nearbyintf(num); > + #else > + return MSVCRT_nearbyint(num); > + #endif > +} > + > +/********************************************************************* > * _nextafter (MSVCRT.@) > */ > double CDECL MSVCRT__nextafter(double num, double next) > diff --git a/dlls/msvcrt/msvcrt.spec b/dlls/msvcrt/msvcrt.spec > index 0c1d4ad..d44e880 100644 > --- a/dlls/msvcrt/msvcrt.spec > +++ b/dlls/msvcrt/msvcrt.spec > @@ -837,6 +837,8 @@ > @ cdecl _msize(ptr) > # stub -arch=win32 _msize_debug(ptr long) > # stub -arch=win64 _msize_dbg(ptr long) > +@ cdecl nearbyint(double) MSVCRT_nearbyint > +@ cdecl nearbyintf(float) MSVCRT_nearbyintf > @ cdecl _nextafter(double double) MSVCRT__nextafter > @ cdecl -arch=arm,x86_64 _nextafterf(float float) MSVCRT__nextafterf > @ cdecl _onexit(ptr) MSVCRT__onexit > diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec > index 2aa0563..111de2e 100644 > --- a/dlls/ucrtbase/ucrtbase.spec > +++ b/dlls/ucrtbase/ucrtbase.spec > @@ -2432,8 +2432,8 @@ > @ stub nan > @ stub nanf > @ stub nanl > -@ stub nearbyint > -@ stub nearbyintf > +@ cdecl nearbyint(double) MSVCRT_nearbyint > +@ cdecl nearbyintf(float) MSVCRT_nearbyintf > @ stub nearbyintl > @ cdecl nextafter(double double) MSVCRT__nextafter > @ cdecl nextafterf(float float) MSVCRT__nextafterf > diff --git a/include/msvcrt/math.h b/include/msvcrt/math.h > index c76fe0d..5b42b4d 100644 > --- a/include/msvcrt/math.h > +++ b/include/msvcrt/math.h > @@ -148,6 +148,9 @@ float __cdecl fmodf(float, float); > > #define ldexpf(x,y) ((float)ldexp((double)(x),(y))) > > +double __cdecl nearbyint(double); > +float __cdecl nearbyintf(float); > + > float __cdecl _hypotf(float, float); > > int __cdecl _matherr(struct _exception*);

1 0

Re: [PATCH 2/2] winegstreamer: Make some strings static constants.
by Andrew Eikum Nov. 18, 2016

Nov. 18, 2016

This adds a bunch of warnings for me: main.c:69:9: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] { { wNull, main.c:273:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] argv[0] = argv0; ^ main.c:274:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] argv[1] = argv1; Andrew On Thu, Nov 17, 2016 at 08:46:38AM -0700, Alex Henrie wrote: > Cc: Andrew Eikum <aeikum(a)codeweavers.com> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/winegstreamer/main.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/winegstreamer/main.c b/dlls/winegstreamer/main.c > index 2bb69f4..6c49572 100644 > --- a/dlls/winegstreamer/main.c > +++ b/dlls/winegstreamer/main.c > @@ -52,7 +52,7 @@ static const WCHAR wGstreamer_Mp3[] = > static const WCHAR wGstreamer_AudioConvert[] = > {'G','S','t','r','e','a','m','e','r',' ','A','u','d','i','o','C','o','n','v','e','r','t',' ','f','i','l','t','e','r',0}; > > -static WCHAR wNull[] = {'\0'}; > +static const WCHAR wNull[] = {'\0'}; > > static const AMOVIESETUP_MEDIATYPE amfMTstream[] = > { { &MEDIATYPE_Stream, &WINESUBTYPE_Gstreamer }, > @@ -262,8 +262,8 @@ DWORD Gstreamer_init(void) > static int inited; > > if (!inited) { > - char argv0[] = "wine"; > - char argv1[] = "--gst-disable-registry-fork"; > + static const char argv0[] = "wine"; > + static const char argv1[] = "--gst-disable-registry-fork"; > char **argv = HeapAlloc(GetProcessHeap(), 0, sizeof(char *)*3); > int argc = 2; > GError *err = NULL; > -- > 2.10.2 >

2 1

Re: winex11: Always use the Virtual Core Pointer for raw events
by Henri Verbeet Nov. 18, 2016

Nov. 18, 2016

On 12 November 2016 at 17:14, Carlos Garnacho <carlosg(a)gnome.org> wrote: > Second, in the unlikely case that Wine managed to detect a master > pointer other than the VCP (this requires user intervention, creating > a second pointer/keyboard pair and assigning HW devices to it) This > second pointer would be unaffected by the core X calls performed by > Wine (eg. grabs,cursor). This could eg. result in Wine grabbing/confining > one pointer, while listening to raw events from another, which is > otherwise unaffected by the grab. > I'm not sure that's necessarily wrong, but using XIGrabDevice(), XIWarpPointer(), etc. would probably be enough to fix that. > The Virtual Core Pointer is a given, it always has ID=2, it's created > by default, it can't be removed, it's the one getting HW devices attached > to by default, and it will be the device implicitly used by the other > X core calls. It's the device Wine wants to listen to despite its initial > state. > That probably works in practice, but I can't think of anything in the protocol spec that guarantees the VCP has id 2. Did I miss something there? How about XIGetClientPointer(), would that do the right thing? > The main purpose of this patch is fixing master device detection over > Xwayland, which is affected by the relative axes check. Xwayland will > most usually emit pointer events as coming from a device with absolute > axes, only switching to emitting relative motion when a very specific > set of conditions are met (thought out for gaming basically). But most > usually these conditions don't apply yet when XI2 is enabled, so the > VCP is skipped and it ends up with xi2_core_pointer=0, thus ignoring > the relative motion that is later sent. > > But again, this is not Xwayland specific, it could happen as well with > the right conditions on traditional X servers. > Wouldn't the correct way to handle this kind of thing be to respond to XI_DeviceChanged and XI_HierarchyChanged events?

2 3