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

Re: [PATCH 1/4] d3drm: Add stubs for IDirect3DRMFrame interface. (v4)
by Henri Verbeet June 17, 2016

June 17, 2016

On 17 June 2016 at 09:38, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > v4: Replaced GetVisuals, GetParent and GetTransform with thunks to version 2. > > v3: Added version 1->3 thunks for only those frame1 methods that have tests (see test_Frame). The rest will be stubs returning E_NOTIMPL. Also avoid the use of QI in Add/DeleteChild. > Doesn't that potentially break currently working applications? And while having tests is great, I'm not sure I agree with the premise that it's better to return E_NOTIMPL than to forward to an implementation that may have subtle differences but probably doesn't in most cases. > +static HRESULT WINAPI d3drm_frame1_QueryInterface(IDirect3DRMFrame *iface, REFIID riid, void **out) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + return IDirect3DRMFrame3_QueryInterface(&frame->IDirect3DRMFrame3_iface, riid, out); > +} This may have come up before, but any reason you can't call d3drm_frame3_QueryInterface() directly here?

3 5

Re: [PATCH] msscript: Implement FindConnectionPoint()
by Jacek Caban June 17, 2016

June 17, 2016

Hi Nikolay, On 06/16/2016 09:20 PM, Nikolay Sivov wrote: > +struct ConnectionPoint { > + IConnectionPoint IConnectionPoint_iface; > + ScriptControl *control; > + IConnectionPointContainer *container; Do you need to store IConnectionPointContainer here if you also store ScriptControl? Other than that the patch looks good to me. Thanks, Jacek

1 0

Re: [PATCH 3/5] d3drm/tests: Add refcount tests for IDirect3DRMFrame*. (v2)
by Stefan Dösinger June 17, 2016

June 17, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-16 um 00:23 schrieb Aaryaman Vasishta: > This might be a stupid question, but by the full blown QI + > refcounting tests, did you mean what test_frame_qi does? Because > those tests are already present upstream. Yeah, this test is perfectly fine for testing frame refcount links. You can just drop patch 3/5. (I've re-CCed wine-devel) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYxntAAoJEN0/YqbEcdMw9HMP/0kwOc2M6z3bchxsxYJQAF77 ao8uYZvOjkz2Kzp3XGaRMuja2H55qpvNFe0JGmi3pHnGaNQ5SY2s4nqmYFjgUB3u +PNXAXGspalI/1Hx2dFuFYpjZ0FxUA3kaqQeyloBn3zjycb+XtRohQbyv0LOnrDb hRck+jyPpszjDbQruHBRh7Q1VnFMPQXjayfbrY6VhQnxvVKt2aY7mA/fmqRltfwF 9XKOMekT5zoNufjb1ll6+558Nl/+cek37sDr2d09WOO/hlfeovEKKqnYJfucV/bS ZNKN31JFx94KAFaG/JsIiLwS+lJq2bU92ZHWpkQc6CbcRcm8nOFMtZQ9EPh3iRqW ou2i00/UMBXwhoNMOq6yAI6FG6CvUyf7HKqEKhWyJHtaiJ85/ZPgtT+xqOvNSld8 9O54r1JbaDJ5SIQaDiIGc/XmyMot0hLjGMu5l9r/bIF+XTfsP8Bjge+hHe28yaL+ h7qwKWMes52DWxW1BHv6NTFRm1GAuSFaTz5QCyp1zNWegOqS05tmEWjISQ79871g urJg0XcEiKvftx7irWDUOM8gPAOKgSfxfFsVc0zMTJcFRUm6h5tFXld6nDYG7oMy KXU7guPKOdaW2KBM2mqYBUy6yXmAZ5fJXRRvl0Ai/fatvqoH+6RdNwVhEe1DL+BH 4zWH/+UP6vfFOXvAVHpk =hG2j -----END PGP SIGNATURE-----

2 1

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: [PATCH 5/5] mshtml: Added IHTMLButtonElement::form property implementation.
by Marvin June 16, 2016

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

1 0

Re: [PATCH 4/5] mshtml: Added IHTMLButtonElement::value property implementation.
by Marvin June 16, 2016

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

1 0

Re: [PATCH 3/5] mshtml: Added IHTMLButtonElement::get_type implementation.
by Marvin June 16, 2016

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

1 0

Re: [PATCH 2/5] mshtml: Added IElementSelector::querySelectorAll implementation.
by Marvin June 16, 2016

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

1 0

Re: user32/tests: Use wine_dbgstr_rect() to print RECTs.
by Marvin June 16, 2016

June 16, 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=23661 Your paranoid android. === w1064 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different === w864 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different === w1064 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:7437: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a === w1064 (32 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2 === w1064 (64 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2

2 1

Re: [PATCH] configure: Check for GnuTLS block size function
by Alexandre Julliard June 16, 2016

June 16, 2016

Michael Cronenworth <mike(a)cchtml.com> writes: > diff --git a/configure.ac b/configure.ac > index 7f234b2..6ae8dde 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1268,6 +1268,9 @@ then > WINE_CHECK_LIB_FUNCS(gnutls_hash,[$GNUTLS_LIBS],, > [WINE_NOTICE([libgnutls ${notice_platform}development files too old, no bcrypt hash support.])])])], > [GNUTLS_CFLAGS=""])]) > + WINE_PACKAGE_FLAGS(GNUTLS,[gnutls],,,, > + [WINE_CHECK_LIB_FUNCS(gnutls_cipher_get_block_size,[$GNUTLS_LIBS],, > + [WINE_NOTICE([libgnutls ${notice_platform}development files too old, no block size support.])])]) This won't have any effect, since you don't check the resulting define. In any case I don't think this needs a configure check, since we already have a fallback. You can simply declare the function pointer without using the MAKE_FUNCPTR macro. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH] tools: Use type BOOL where appropriate.
by Alexandre Julliard June 16, 2016

June 16, 2016

Hadrien Boizard <h.boizard(a)gmail.com> writes: > Signed-off-by: Hadrien Boizard <h.boizard(a)gmail.com> > --- > tools/wrc/parser.y | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) In general, tools don't use the Windows API, so BOOL is not necessarily appropriate either. Technically it's not wrong, but IMO it's not worth changing the code for it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Include system headers before winsock2.h in http.c.
by Alexandre Julliard June 16, 2016

June 16, 2016

Jacek Caban <jacek(a)codeweavers.com> writes: > Fixes compilation on NetBSD, where zlib.h doesn't include stdlib.h. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/wininet/http.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) This breaks the mingw build: In file included from ../../../wine/include/winsock2.h:47:0, from ../../../wine/dlls/wininet/http.c:42: ../../../wine/include/winsock.h:445:19: error: redefinition of ‘struct timeval’ ../../../wine/include/winsock.h:136:19: note: in definition of macro ‘WS’ In file included from /usr/share/mingw-w64/include/time.h:246:0, from ../../../wine/dlls/wininet/http.c:39: /usr/share/mingw-w64/include/_timeval.h:10:8: note: originally defined here Makefile:296: recipe for target 'http.o' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 04/10] d3dx9_30: Share the source with d3dx9_36
by Matteo Bruni June 15, 2016

June 15, 2016

2016-06-15 8:35 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > @@ -75,3 +75,21 @@ D3DX_CPU_OPTIMIZATION WINAPI D3DXCpuOptimizations(BOOL enable) > FIXME("%i - stub\n", enable); > return D3DX_NOT_OPTIMIZED; > } It's probably better to move the D3DXCpuOptimizations() implementation to d3dx9_36 in this patch so you can then drop the forwards from <= d3dx9_29.dll in the following patches.

1 0

Re: [PATCH 01/10] d3dx9_33: Share the source with d3dx9_36
by Matteo Bruni June 15, 2016

June 15, 2016

2016-06-15 8:35 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > -@ stdcall D3DXComputeNormalMap(ptr ptr ptr long long long) d3dx9_36.D3DXComputeNormalMap ... > +@ stub D3DXComputeNormalMap(ptr ptr ptr long long float) Nicely spotted (also for D3DXFrameFind), that should probably be applied to all the DLLs and separately from this patch though. I'm sending a patch for it. > +@ stdcall D3DXGetShaderConstantTableEx(ptr long ptr) This function shouldn't be exported by d3dx9_33.dll. WRT D3DXDebugMute() and D3DXGetDriverLevel(), I would move the implementation to util.c or some other file and avoid duplicating the code in every d3dx9_xx_main.c.

1 0

Re: [PATCH 3/5] d3drm/tests: Add refcount tests for IDirect3DRMFrame*. (v2)
by Stefan Dösinger June 15, 2016

June 15, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-15 um 10:35 schrieb Aaryaman Vasishta: > + ok(ref1 == ref2, "Expected ref1 == ref2, got ref1 = %u, ref2 = %u.\n", ref1, ref2); > + ok(ref2 == ref3, "Expected ref2 == ref3, got ref2 = %u, ref3 = %u.\n", ref2, ref3); > + ok(ref1 == ref3, "Expected ref1 == ref3, got ref1 = %u, ref3 = %u.\n", ref1, ref3); I think you can assume basic logic still applies to d3drm :-) . There's no need to test ref1 == ref3 after you made sure (ref1 == ref2 && ref2 == ref3) . More importantly though, patch 5 somewhat suggests that you're planning to have a full-blown QI and refcounting test for frames too. If that's the case there's no need to add this patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYcYrAAoJEN0/YqbEcdMwudEP/1BMGtCEhuN9i8BbphtECIuF otKTT8qBR1LFP0QocHWntJtCteJ69vq70dfxp764++wqt7UWuGrZhPdKG+6Qjb1u 9kBU6PppQNX4V0tybDgCMIEOv4HcY00FuCN4ahPu5bfBFOskXwOhzs2ne3bYHX1v iDR2NIATu2wwTkA/s/ttj5ZYuKflSl5EUC8wELFwy6IjonaICfuubvgZCVEDBc+R POeJbGbbvn/7v9Q+mfTLNDFvTdDANgTCFkIFmBxrPu2b4erFtRJQV47DVhaLGmZg BwOxV8AYnq7yEltiOkpWKgUtIC4q6U1pf7tW2uUm/4kPMM3+RviiFbX2fNKTFP6f 5rW/5xIP68ymv+Z4su24BbbMcYJPBXkHNkyk1bdARmXtTtzRQbSchdVCLCaOs81k Vmwbl7A4ZqqshTqv40DTRAQq5NWYFcvTbXdUkWZav9EtO9a0hs8PMO9GqG+RBgOu lGk9GrW/jvoWXx/knMtSuoHpkLnpPy4RuJefzVyw1NaawBfakTuUElD0/nnC2f+j 528Ft8FKM9wmJLf3v8fl4IB0vsnExkjOrbKRdWJAuvpxuZJp0rkSdXE0JrEEum44 BlgKzwWvFDl46BX/OC0pzvGlZ6417c/5JgaaPCXus9nGBPBaJx44d2QJWD/UELMS jN9KRUNfGyfcNYS4yVH1 =2nxr -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/5] d3drm: Add stubs for IDirect3DRMFrame interface. (v3)
by Stefan Dösinger June 15, 2016

June 15, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-15 um 10:35 schrieb Aaryaman Vasishta: > +static HRESULT WINAPI d3drm_frame1_GetVisuals(IDirect3DRMFrame *iface, IDirect3DRMVisualArray **visuals) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + struct d3drm_visual_array *array; > + > + TRACE("iface %p, visuals %p.\n", iface, visuals); > + > + if (!visuals) > + return D3DRMERR_BADVALUE; > + > + if (!(array = d3drm_visual_array_create(frame->nb_visuals, frame->visuals))) > + return E_OUTOFMEMORY; > + > + *visuals = &array->IDirect3DRMVisualArray_iface; > + > + return D3DRM_OK; > +} This is a reimplementation instead of a thunk. Intentional? The same applies to d3drm_frame1_GetTransform. > +static HRESULT WINAPI d3drm_frame1_GetSceneBackgroundDepth(IDirect3DRMFrame *iface, > + IDirectDrawSurface **surface) The indentation here is different. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYcT1AAoJEN0/YqbEcdMwUHcQAIAfKv2BAfasnwRACZsGBcK9 VAftr2zuIgmlMKtQaplsZuv2ZqcyUnydOgzuXQusFfBldeKeD1ukycLx/sONpuZI ggt7AbXcslw9T0wlprTnfl+1Pna/CSbRQWhVAjeB9dCCWblBslipsj9SLr3hTOwH ppQYvk+BtoXb7A+tvVI2ch/Q8HhwWh/Q9SvVg6tUV7gQLrPG0sj4NEjG50I7VN0c PjLgZHlT7JzVDxlGoefhTPXZdL+1muSIIuxVXho+oNx6qFqiyC0+7xxlJEVR2Eyo VBzdczdYd0UcLRb0GOqyJpRcGTpYE06zahKeDyODIXeorFB0NlYFqSTD2H32RVNU M2a+xKgFLqm4zu+cabfRIvFk9wGkIRykwfm8KUY4LyZCZmlQZ21nPCAIsuolRqV6 DrmQAParbMg/fAb6L9/uB0rb/CBPGIhm3mtv00TewBG8VG16uV4vLbvtoiIJJtD4 Z6iY6x948K+jjVVkhGDRfdEJn+nQRDTKIkgsRKic9S5x/nOEyfreVutjq4vULnGk l5hRAzyzOxjP/JTMHhvYtHYbLtqjgXPi3pwhjrfGMWLKAmeRPk3A2FdsUl9A1I3I INR8LmGAo3P7a1GZ21loc5A2iftn29vcAB0mDzcotczOEsinfx7Sc4oF5fIUDZla miBufY1gPaDENTTiRcz5 =hvk0 -----END PGP SIGNATURE-----

1 0

Re: ddraw/tests: A spelling fix for a d3d ok() message.
by Francois Gouget June 15, 2016

June 15, 2016

Anything wrong with this patch? On Sun, 29 May 2016, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > dlls/ddraw/tests/d3d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index d877020..0e9a43b 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -1155,7 +1155,7 @@ static void Direct3D1Test(void) > /* Interface consistency check. */ > hr = IDirect3DDevice_GetDirect3D(Direct3DDevice1, &Direct3D_alt); > ok(hr == D3D_OK, "IDirect3DDevice_GetDirect3D failed: %08x\n", hr); > - ok(Direct3D_alt == Direct3D1, "Direct3D1 struct pointer missmatch: %p != %p\n", Direct3D_alt, Direct3D1); > + ok(Direct3D_alt == Direct3D1, "Direct3D1 struct pointer mismatch: %p != %p\n", Direct3D_alt, Direct3D1); > IDirect3D_Release(Direct3D_alt); > > memset(&desc, 0, sizeof(desc)); > -- > 2.8.1 > > > > -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

3 4

Re: [PATCH 5/5] d3dx9: Turn an ERR into a WARN.
by Matteo Bruni June 15, 2016

June 15, 2016

2016-06-15 9:51 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Hello Matteo, > > I am afraid that if application passes effect data broken an > arbitrary way then probably almost every ERR and FIXME should be changed > to WARN (at least in my code, but probably in the rest of effect > framework either). E. g., we have FIXME on not yet supported relative > addressing, but it can also happen if the application passes broken > effect code. Or do you see any difference for this case with parameter > name? I do not yet, as actually preshader and effect are compiled > together, and it is no way to get such a situation (at least if there is > some feature in fxc compiler which I am not aware of) other than > modifying effect bytecode. > > Regards, > Paul. The general idea is that FIXME refers to something that isn't (completely / correctly) implemented in Wine, so e.g. FIXME is the right choice for relative addressing. ERR is the correct choice for "internal errors" in Wine (i.e. something that shouldn't happen unless there is a bug in Wine - the ERR("Unexpected register set %u.\n", ...) is a good example of that) and WARN should be used when the application can trigger the problematic condition by misusing the API or similar. Specifically WRT this patch I just happened to notice that ERR while looking through the code and it seems to me that WARN fits better. It's not a big deal either way.

1 0

Re: [PATCH] wined3d: Implement icb dcl support in GLSL.
by Józef Kucia June 15, 2016

June 15, 2016

This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable. Also, a test would be nice. On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 55affc1..def224c 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) > shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool); > > + if (reg_maps->icb) > + { > + shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n", > + prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4); > + for (i = 0; i < reg_maps->icb->element_count / 4; i++) { > + shader_glsl_append_imm_vec4(buffer, (float *)&reg_maps->icb->data[4 * i]); > + if (i != reg_maps->icb->element_count / 4 - 1) > + shader_addline(buffer, ","); > + shader_addline(buffer, "\n"); > + } > + shader_addline(buffer, ");\n"); > + } I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer. > + > for (i = 0; i < WINED3D_MAX_CBS; ++i) > { > if (reg_maps->cb_sizes[i]) > @@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, > /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, > /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL, > - /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL, > + /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, > /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop, > -- > 2.7.4 > > >

2 5

Re: [PATCH] wined3d: Properly handle immediate NaN and Inf in GLSL backend.
by Józef Kucia June 15, 2016

June 15, 2016

In my opinion, we do not want to solve the issue with immediate constant buffers this way. However, this patch might still be useful. Some games (Magicka 2) use shaders which contain NaN values in immediate constants. This patch represents a one way to solve the issue with NaN values in immediate constants. If we decide that we want to apply this change we should be more careful though. We probably want to use this for SM4+ shaders only, or use it only when GL_ARB_shader_bit_encoding is available. On a side note, "uintBitsToFloat" cannot be used as a constant expression (at least in GLSL 1.30), so to make this work with the immediate constant buffers patch you would have to drop "const". On Mon, Jun 13, 2016 at 9:30 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 36 +++++++++++++++++++++++++----------- > 1 file changed, 25 insertions(+), 11 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index def224c..fde4c5e 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -34,6 +34,8 @@ > > #include <limits.h> > #include <stdio.h> > +#include <stdint.h> > +#include <inttypes.h> We avoid C99 in Wine. unsigned int and %#xu should be good enough. > #ifdef HAVE_FLOAT_H > # include <float.h> > #endif > @@ -321,14 +323,26 @@ static const char *shader_glsl_get_version(const struct wined3d_gl_info *gl_info > return "#version 120"; > } > > +/* Allow raw NaN and Inf in GLSL code. */ > +void wined3d_glsl_ftoa(float value, char *s) The function should be static. > +{ > + if (!isfinite(value)) > + { > + /* We need a buffer of at least 28 characters. */ > + snprintf(s, 28, "uintBitsToFloat(%"PRIu32"u)", *(uint32_t *)&value); It seems that 29 bytes are needed at least (including the null character). > + } > + else > + wined3d_ftoa(value, s); > +} In wined3d, generally, if one block in if-else statement needs curly braces we use curly braces for all blocks in this statement. else { wined3d_ftoa(value, s); } > + > static void shader_glsl_append_imm_vec4(struct wined3d_string_buffer *buffer, const float *values) > { > - char str[4][17]; > + char str[4][28]; > > - wined3d_ftoa(values[0], str[0]); > - wined3d_ftoa(values[1], str[1]); > - wined3d_ftoa(values[2], str[2]); > - wined3d_ftoa(values[3], str[3]); > + wined3d_glsl_ftoa(values[0], str[0]); > + wined3d_glsl_ftoa(values[1], str[1]); > + wined3d_glsl_ftoa(values[2], str[2]); > + wined3d_glsl_ftoa(values[3], str[3]); > shader_addline(buffer, "vec4(%s, %s, %s, %s)", str[0], str[1], str[2], str[3]); > } > > @@ -2299,7 +2313,7 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > const struct wined3d_gl_info *gl_info = ins->ctx->gl_info; > const char *prefix = shader_glsl_get_prefix(version->type); > struct glsl_src_param rel_param0, rel_param1; > - char imm_str[4][17]; > + char imm_str[4][28]; > > if (reg->idx[0].offset != ~0U && reg->idx[0].rel_addr) > shader_glsl_add_src_param(ins, reg->idx[0].rel_addr, WINED3DSP_WRITEMASK_0, &rel_param0); > @@ -2513,7 +2527,7 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > switch (reg->data_type) > { > case WINED3D_DATA_FLOAT: > - wined3d_ftoa(*(const float *)reg->immconst_data, register_name); > + wined3d_glsl_ftoa(*(const float *)reg->immconst_data, register_name); > break; > case WINED3D_DATA_INT: > sprintf(register_name, "%#x", reg->immconst_data[0]); > @@ -2533,10 +2547,10 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > switch (reg->data_type) > { > case WINED3D_DATA_FLOAT: > - wined3d_ftoa(*(const float *)&reg->immconst_data[0], imm_str[0]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[1], imm_str[1]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[2], imm_str[2]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[3], imm_str[3]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[0], imm_str[0]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[1], imm_str[1]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[2], imm_str[2]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[3], imm_str[3]); > sprintf(register_name, "vec4(%s, %s, %s, %s)", > imm_str[0], imm_str[1], imm_str[2], imm_str[3]); It looks like shader_glsl_append_imm_vec4() could be called there instead.

4 8

Re: [PATCH] wined3d: Correct memory size for Geforece 9600 GT (resend)
by Henri Verbeet June 15, 2016

June 15, 2016

On 15 June 2016 at 09:48, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/wined3d/directx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > This isn't necessarily wrong, but why is this needed/more correct?

2 2

Fwd: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
by DavidL June 15, 2016

June 15, 2016

Sorry, keep hitting reply instead of reply-all to make sure the list-serve has a copy. ---------- Forwarded message ---------- From: DavidL <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 12:05 AM Subject: Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping To: Ken Thomases <ken(a)codeweavers.com> As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be. On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote: > > > On Mon, Jun 13, 2016 at 2:46 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Is there reason to expect that these elements (sliders, dials, wheels) >> will be listed after the "proper" axes (x, y, z, etc.) in the children >> array? Since the proper axes are specific and these elements should only >> be mapped to unused axes, I think they should be enumerated in a separate >> pass after everything else has had a shot. Note that >> collect_joystick_elements() is recursive, so it's not right to do it in a >> separate loop within collect_joystick_elements(). Probably, you'll want to >> call it twice from open_joystick(), with a flag to indicate which mode it >> should operate in. > > > This where the Microsoft source documentation get *really* fuzzy. There > are all sorts of possible mappings in the rare case where there is both a > HID/Dinput Z-axis and a slider/dial/wheel. Microsoft gave 4-5 different > variations of how it could go and in some of these mappings, the slider > would take precedence over the reported HID Z-axis when mapping to the > Winmm Z-axis such that slider -> WinmmZ is correct and the HID Z-axis is > then ignored. So I decided to follow the Linux Winmm version and simply > have whichever element is listed by the joystick first, wins. If it is the > axis, it's the axis, if it is the slider, it's the slider. This actually is > one of the ways Microsoft says to decide proper HID mappings to Winmm (and > it seems like that for the elements within a joystick, the elements are > always reported in the same order such that a user shouldn't experience the > axes mappings changing each time they start up Wine/reconnect a device*). > There is no 1 correct mapping for all cases. I guess ideally we would have > a way of allowing the user to remap the joystick axes in the registry > (maybe that would work even now? I don't know - I've seen some emails on > that already in the wine-devel list serve but I don't know what the status > of that kind of capability is) but even Microsoft states on of their pages > that this is a pretty rare corner case. > > > OK, fine by me. > > > *Note: in my testing this is *not* the same for OS X (I guess macOS now) > reporting back devices - which human interface device is reported first > seems to be random in my testing when I had both a virtual and physical > joystick setup. Historically Winmm games would only take input from the > first reported device - under Mac-Wine, I've noticed the games seem to be > taking input from both my physical and virtual joysticks (sometimes > regardless of what the game was saying it was doing!). This has both good > and bad potential and is not necessarily behavior we should spend effort > trying to get rid of. Not sure how the Linux version behaves in this > situation in terms of joystick order and input from multiple sources. > > > It was taking input from both joysticks in the same run? At the same > time? If so, can you figure out how that's happening? It really > shouldn't, as near as I can see. > > Or was it just arbitrarily picking which was first and therefore active > for any given run? If this, then it's < > https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less. > > -Ken > >

2 4

Re: [v2 02/10] msvcirt: Implement ostream constructors/destructors
by Piotr Caban June 15, 2016

June 15, 2016

On 06/14/16 19:01, Iván Matellanes wrote: > On 14/06/16 16:20, Piotr Caban wrote: >> On 06/14/16 16:40, Iván Matellanes wrote: >>> /* ??_Dostream@@QAEXXZ */ >>> @@ -2287,23 +2341,48 @@ ostream* __thiscall ostream_assign(ostream >>> *this, const ostream *rhs) >>> DEFINE_THISCALL_WRAPPER(ostream_vbase_dtor, 4) >>> void __thiscall ostream_vbase_dtor(ostream *this) >>> { >>> - FIXME("(%p) stub\n", this); >>> + ios *base = ostream_to_ios(this); >>> + >>> + TRACE("(%p)\n", this); >>> + >>> + ostream_dtor(base); >>> + ios_dtor(base); >>> } >> The base should be computed using ostream_get_ios while calling ios_dtor: >> TRACE("(%p)\n", this); >> ostream_dtor(ostream_to_ios(this)); >> ios_dtor(ostream_get_ios(this)); > Do you mind explaining why is that required? I can't see the reason ostream_vbase_dtor can be used to destroy object that has virtual base in any position pointer by vbtable. ostream_get_ios computes it using object's vbtable. You can easily see it by overwriting ostream->vbtable with garbage, the application will crash then on Windows. On the other hand ostream_dtor is a virtual function that assumes "this" is at fixed offset from "base" that is passed to it. It's done this way because it has no access to vbtable. It's why you need to use ostream_to_ios in this case. There's no real need to call ostream_dtor here because it's an empty function (I don't know if it should be called here or if ostream_vbase_dtor should only destroy the vbase). Thanks, Piotr

2 2

Re: [PATCH] riched20: Remove duplicated condition and duplicated test
by Huw Davies June 15, 2016

June 15, 2016

On Tue, Jun 14, 2016 at 08:56:41PM +0300, Nikolay Sivov wrote: > diff --git a/dlls/riched20/richole.c b/dlls/riched20/richole.c > index 1013e67..a2f23c9 100644 > --- a/dlls/riched20/richole.c > +++ b/dlls/riched20/richole.c > @@ -1976,7 +1976,7 @@ static HRESULT range_Collapse(LONG bStart, LONG *start, LONG *end) > if (*end == *start) > return S_FALSE; > > - if (bStart == tomEnd || bStart == tomFalse) > + if (bStart == tomEnd) > *start = *end; > else > *end = *start; > > diff --git a/dlls/riched20/tests/richole.c b/dlls/riched20/tests/richole.c > index 6da3ce3..33043fd 100644 > --- a/dlls/riched20/tests/richole.c > +++ b/dlls/riched20/tests/richole.c > @@ -1361,18 +1361,6 @@ static void test_ITextRange_Collapse(void) > first = 4, lim = 8; > hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > ok(hres == S_OK, "got 0x%08x\n", hres); > - hres = ITextRange_Collapse(txtRge, tomTrue); > - ok(hres == S_OK, "ITextRange_Collapse\n"); > - hres = ITextRange_GetStart(txtRge, &start); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(start == 4, "got wrong start value: %d\n", start); > - hres = ITextRange_GetEnd(txtRge, &end); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(end == 4, "got wrong end value: %d\n", end); > - ITextRange_Release(txtRge); > - > - hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > - ok(hres == S_OK, "got 0x%08x\n", hres); > hres = ITextRange_Collapse(txtRge, tomStart); > ok(hres == S_OK, "ITextRange_Collapse\n"); > hres = ITextRange_GetStart(txtRge, &start); > @@ -1385,18 +1373,6 @@ static void test_ITextRange_Collapse(void) > > hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > ok(hres == S_OK, "got 0x%08x\n", hres); > - hres = ITextRange_Collapse(txtRge, tomFalse); > - ok(hres == S_OK, "ITextRange_Collapse\n"); > - hres = ITextRange_GetStart(txtRge, &start); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(start == 8, "got wrong start value: %d\n", start); > - hres = ITextRange_GetEnd(txtRge, &end); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(end == 8, "got wrong end value: %d\n", end); > - ITextRange_Release(txtRge); > - > - hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > - ok(hres == S_OK, "got 0x%08x\n", hres); > hres = ITextRange_Collapse(txtRge, tomEnd); > ok(hres == S_OK, "ITextRange_Collapse\n"); > hres = ITextRange_GetStart(txtRge, &start); I don't think we should remove the extra tests, especially as tomTrue != tomStart and it's documentented to work with either. Leaving the tomFalse tests in is fine too. Huw.

2 1

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Sebastian Lackner June 15, 2016

June 15, 2016

On 14.06.2016 09:09, Marcus Meissner wrote: > From: Austin English <austinenglish(a)gmail.com> > > https://bugs.winehq.org/show_bug.cgi?id=18745 > > Report 2MB minimum page size on x86 32bit and 64bit on Linux. > > This assumes that all x86 processors and the 64/32bit emulation mode > have hugetable support and it is always enabled. > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > Signed-off-by: Austin English <austinenglish(a)gmail.com> As pointed out on IRC, the order of the sign-offs is wrong here. Your own signoff should always be the last because you have to take responsibility when you send a patch. > --- > dlls/kernel32/cpu.c | 15 +++++++++++++++ > dlls/kernel32/kernel32.spec | 2 +- > dlls/kernel32/tests/process.c | 16 ++++++++++++++++ > 3 files changed, 32 insertions(+), 1 deletion(-) > > diff --git a/dlls/kernel32/cpu.c b/dlls/kernel32/cpu.c > index f48fcf0..f8b2c3d 100644 > --- a/dlls/kernel32/cpu.c > +++ b/dlls/kernel32/cpu.c > @@ -291,3 +291,18 @@ err: > } > return TRUE; > } > + > +/*********************************************************************** > + * GetLargePageMinimum (KERNEL32.@) > + */ > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux I do not see any need for that #ifdef linux. Its more architecture specific than linux specific. Dmitry already mentioned the same concern on the mailing list. > +#if defined(__i386___) || defined(__x86_64__) > + /* Linux x86 hugepages are minimum 2 MB */ > + return 2*1024*1024; > +#endif > +#endif > + FIXME("stub: not implemented on your platform/architecture.\n"); > + return 0; > +} > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index ec7155b6e..0fc4dcb 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -696,7 +696,7 @@ > @ stdcall GetHandleInformation(long ptr) > @ stub -i386 GetLSCallbackTarget > @ stub -i386 GetLSCallbackTemplate > -# @ stub GetLargePageMinimum > +@ stdcall GetLargePageMinimum() > @ stdcall GetLargestConsoleWindowSize(long) > @ stdcall GetLastError() > @ stub GetLinguistLangSize > diff --git a/dlls/kernel32/tests/process.c b/dlls/kernel32/tests/process.c > index 61dcdc2..e9acfd3 100644 > --- a/dlls/kernel32/tests/process.c > +++ b/dlls/kernel32/tests/process.c > @@ -88,6 +88,7 @@ static BOOL (WINAPI *pProcess32Next)(HANDLE, PROCESSENTRY32*); > static BOOL (WINAPI *pThread32First)(HANDLE, THREADENTRY32*); > static BOOL (WINAPI *pThread32Next)(HANDLE, THREADENTRY32*); > static BOOL (WINAPI *pGetLogicalProcessorInformationEx)(LOGICAL_PROCESSOR_RELATIONSHIP,SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX*,DWORD*); > +static SIZE_T (WINAPI *pGetLargePageMinimum)(void); > > /* ############################### */ > static char base[MAX_PATH]; > @@ -252,6 +253,7 @@ static BOOL init(void) > pThread32First = (void *)GetProcAddress(hkernel32, "Thread32First"); > pThread32Next = (void *)GetProcAddress(hkernel32, "Thread32Next"); > pGetLogicalProcessorInformationEx = (void *)GetProcAddress(hkernel32, "GetLogicalProcessorInformationEx"); > + pGetLargePageMinimum = (void *)GetProcAddress(hkernel32, "GetLargePageMinimum"); > > return TRUE; > } > @@ -3138,6 +3140,19 @@ static void test_GetLogicalProcessorInformationEx(void) > HeapFree(GetProcessHeap(), 0, info); > } > > +static void test_largepages(void) > +{ > + SIZE_T size; > + > + if (!pGetLargePageMinimum) { > + skip("No GetLargePageMinimum support.\n"); > + return; > + } > + size = pGetLargePageMinimum(); > + > + ok((size == 0) || (size == 2*1024*1024) || (size == 4*1024*1024), "GetLargePageMinimum reports %ld size\n", size); > +} > + > START_TEST(process) > { > HANDLE job; > @@ -3210,6 +3225,7 @@ START_TEST(process) > test_GetNumaProcessorNode(); > test_session_info(); > test_GetLogicalProcessorInformationEx(); > + test_largepages(); > > /* things that can be tested: > * lookup: check the way program to be executed is searched >

3 3