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

Re: [v4 4/4] winejoystick.drv/joystick_osx.c: adds sim page element controls
by Ken Thomases June 15, 2016

June 15, 2016

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Adds support for input features defined by HID Simulation page: Rudder > (Rz), Throttle (Z), Steering (X), Accelerator (Y), Brake (Rz). > +static int axis_for_usage_Sim(int usage) > +{ > + switch (usage) > + { > + case kHIDUsage_Sim_Rudder: return AXIS_RZ; > + case kHIDUsage_Sim_Throttle: return AXIS_Z; > + case kHIDUsage_Sim_Steering: return AXIS_X; > + case kHIDUsage_Sim_Accelerator: return AXIS_Y; > + case kHIDUsage_Sim_Brake: return AXIS_RZ; > + } Is it intentional that Rudder and Brake both map to the same axis? Later, when enumerating elements, which comes first and thus "wins" the collision (if they ever appear on the same device) is arbitrary based on enumeration order. That OK? > @@ -404,66 +418,100 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll > break; > } > case kIOHIDElementTypeInput_Axis: > - { > - TRACE("kIOHIDElementTypeInput_Axis; ignoring\n"); > - break; > - } > case kIOHIDElementTypeInput_Misc: It seems that treating kIOHIDElementTypeInput_Axis the same as kIOHIDElementTypeInput_Misc is a separate issue from adding support for the Sim page inputs. Or is there an interrelationship that I'm not aware of? Is it the case that both Axis and Misc elements can be present with either GD or Sim usage pages? Some of the debug logging statements have been changed to say "kIOHIDElementTypeInput_Axis/Misc" while others have been left as "kIOHIDElementTypeInput_Misc". Is that indicative of something or just an oversight? > @@ -614,7 +662,7 @@ LRESULT driver_joyGetDevCaps(DWORD_PTR device_id, JOYCAPSW* caps, DWORD size) > { > int i; > > - /* complete 95 structure */ > + /* complete Win95 structure */ This is an unrelated change. -Ken

2 3

Fwd: [v5 5/5] winejoystick.drv/joystick_osx.c: ignore feature elements
by DavidL June 15, 2016

June 15, 2016

I made the changes to the patches we talked about and added the patch below. All it does is ignore "feature"-type elements which aren't meant for end user consumption, suppressing the FIXME message in Trace logs for those elements. Since these element types are un-handled by Winmm, I don't think a FIXME message is necessary for them. However, if you feel we should keep the fixme messages in place, I'm fine with that too. Cheers, David ---------- Forwarded message ---------- From: David Lawrie <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 8:33 PM Subject: [v5 5/5] winejoystick.drv/joystick_osx.c: ignore feature elements To: wine-patches <wine-patches(a)winehq.org> Cc: David Lawrie <david.dljunk(a)gmail.com> "Describes input and output elements not intended for consumption by the end user." Ignore, as otherwise, comes up as a FIXME in Trace logs. Source: https://developer.apple.com/library/mac/documentation/IOKit/Reference/ IOHIDKeys_iokit_header_reference/#//apple_ref/c/tdef/IOHIDElementType Tested on OS X 10.10.5. Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> --- dlls/winejoystick.drv/joystick_osx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/winejoystick.drv/joystick_osx.c b/dlls/winejoystick.drv/joystick_osx.c index ad82dd7..12ccff7 100644 --- a/dlls/winejoystick.drv/joystick_osx.c +++ b/dlls/winejoystick.drv/joystick_osx.c @@ -514,6 +514,9 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll } break; } + case kIOHIDElementTypeFeature: + /* Describes input and output elements not intended for consumption by the end user. Ignoring. */ + break; default: FIXME("Unhandled type %i\n",type); break; -- 1.7.12.4 (Apple Git-37)

1 0

Re: [v4 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping
by Ken Thomases June 15, 2016

June 15, 2016

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Ry now maps to U, Rx now maps to V. Windows defines Winmm U as Dinput Ry > and V as Dinput Rx. Original joystick_osx.c mapping was other way > around. This is also a bug in the Linux Winmm joystick version (not > fixed with this patch). > > Sources: > https://msdn.microsoft.com/en-us/library/windows/hardware/ff538340(v=vs.85)… > https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85)… > > Tested on OS X 10.10.5. > > Tested on Red Baron 3D, X-wing vs Tie Fighter, X-wing Alliance, > Independence War deluxe w/ Logitech Extreme 3D pro and ControllerMate > virtual joystick with 5/6 axes. I originally wrote this code, but I think I was largely basing it on the Linux code without having a strong handle on the behavior of the R* axes. Your testing is probably the most thorough that's been done for the Mac code, although I would expect the Linux code to have been tested pretty well. Maybe the Linux code is correct and it's only the comments about what the joystick device is providing that are wrong. So, the code changes appear to properly implement the logic you've described above, but I don't know if that's correct. The cited MSDN pages are not terribly clear. That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead. -Ken

2 3

Re: d3dx10_43: Add D3DX10FilterTexture stub
by Matteo Bruni June 14, 2016

June 14, 2016

2016-06-13 17:02 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: Can you please also add the D3DX10_FILTER_FLAG type declaration to d3dx10tex.h? > + FIXME("texture %p, src_level %u, filter %u stub!\n", texture, src_level, filter); filter is a flags bitmask, please trace it with %#x or similar.

1 0

Re: [PATCH] d3dx9_33: Share the source with d3dx9_36
by Matteo Bruni June 14, 2016

June 14, 2016

2016-06-10 10:33 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=21817 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3dx9_33/Makefile.in | 22 +- > dlls/d3dx9_33/d3dx9_33.spec | 667 +++++++++++++++++++++--------------------- > dlls/d3dx9_33/d3dx9_33_main.c | 19 ++ > tools/make_specfiles | 1 - > 4 files changed, 373 insertions(+), 336 deletions(-) > > diff --git a/dlls/d3dx9_33/Makefile.in b/dlls/d3dx9_33/Makefile.in > index 0934eab..1106d11 100644 > --- a/dlls/d3dx9_33/Makefile.in > +++ b/dlls/d3dx9_33/Makefile.in > @@ -1,7 +1,25 @@ > MODULE = d3dx9_33.dll > -IMPORTS = d3d9 > +IMPORTS = d3d9 d3dcompiler dxguid d3dxof ole32 gdi32 user32 wined3d You don't want to import wined3d here. It looks good otherwise, at a quick glance. Do you mind also writing similar patches for the other d3dx9_xx and d3dcompiler_xx DLLs?

1 0

Re: [PATCH 2/4] ucrtbase: Forward _calloc_base to MSVCRT_calloc.
by Nikolay Sivov June 14, 2016

June 14, 2016

On 14.06.2016 21:28, Alex Henrie wrote: > Cc: Piotr Caban <piotr(a)codeweavers.com> > > For https://bugs.winehq.org/show_bug.cgi?id=40796 > > The Windows 10 SDK helpfully explains that calloc simply wraps > _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not > defined. Since Wine will not be implementing _calloc_dbg because it is > only available in debug builds of the C runtime library, we can make > _calloc_base wrap calloc instead. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- > dlls/ucrtbase/ucrtbase.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > index 18ca9d4..85b2b83 100644 > --- a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > +++ b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > @@ -7,7 +7,7 @@ > @ cdecl _aligned_realloc(ptr long long) ucrtbase._aligned_realloc > @ stub _aligned_recalloc > @ cdecl _callnewh(long) ucrtbase._callnewh > -@ stub _calloc_base > +@ cdecl _calloc_base(long long) ucrtbase._calloc_base > @ cdecl _expand(ptr long) ucrtbase._expand > @ stub _free_base > @ cdecl _get_heap_handle() ucrtbase._get_heap_handle > diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec > index 690072b..365674b 100644 > --- a/dlls/ucrtbase/ucrtbase.spec > +++ b/dlls/ucrtbase/ucrtbase.spec > @@ -211,7 +211,7 @@ > @ cdecl _c_exit() MSVCRT__c_exit > @ cdecl _cabs(long) MSVCRT__cabs > @ cdecl _callnewh(long) > -@ stub _calloc_base > +@ cdecl _calloc_base(long long) MSVCRT_calloc > @ cdecl _cexit() MSVCRT__cexit > @ cdecl _cgets(ptr) > @ stub _cgets_s > Correct me if I'm wrong, but as I remember those exports are only used when you mix some of native dlls from vcrun2015 with some of builtins. Like when application imports from api-ms-* one, which is actually installed with vcrun2015 redist. What I mean is that such mixed environment exposes such glue exports that normally are not used directly, that could potentially qualify as implementation details. I'll be happy to be wrong about that.

3 3

Re: [PATCH 2/4] ucrtbase: Forward _calloc_base to MSVCRT_calloc.
by Sebastian Lackner June 14, 2016

June 14, 2016

On 14.06.2016 20:28, Alex Henrie wrote: > Cc: Piotr Caban <piotr(a)codeweavers.com> > > For https://bugs.winehq.org/show_bug.cgi?id=40796 > > The Windows 10 SDK helpfully explains that calloc simply wraps > _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not > defined. Since Wine will not be implementing _calloc_dbg because it is > only available in debug builds of the C runtime library, we can make > _calloc_base wrap calloc instead. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- > dlls/ucrtbase/ucrtbase.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Martin Storsjo tried the same approach already, and it was rejected. If I remember correctly separate wrapper functions were preferred in this case.

2 1

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP.
by Henri Verbeet June 14, 2016

June 14, 2016

On 12 June 2016 at 22:21, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > +static HRESULT WINAPI is_warp_cb(GUID *guid, char *description, char *name, > + D3DDEVICEDESC *hal_desc, D3DDEVICEDESC *hel_desc, void *ctx) > +{ > + BOOL *is_warp = ctx; > + if (IsEqualGUID(guid, &IID_IDirect3DHALDevice)) > + { > + *is_warp = !!(hal_desc->dwDevCaps & D3DDEVCAPS_TEXTURESYSTEMMEMORY); > + return DDENUMRET_CANCEL; > + } > + return DDENUMRET_OK; > +} > + > static void test_p8_blit(void) > { > IDirectDrawSurface *src, *dst, *dst_p8; > DDSURFACEDESC surface_desc; > IDirectDraw *ddraw; > + IDirect3D *d3d; > IDirectDrawPalette *palette, *palette2; > ULONG refcount; > HWND window; > @@ -5305,6 +5318,7 @@ static void test_p8_blit(void) > PALETTEENTRY palette_entries[256]; > unsigned int x; > DDBLTFX fx; > + BOOL is_warp = FALSE; > static const BYTE src_data[] = {0x10, 0x1, 0x2, 0x3, 0x4, 0x5, 0xff, 0x80}; > static const BYTE src_data2[] = {0x10, 0x5, 0x4, 0x3, 0x2, 0x1, 0xff, 0x80}; > static const BYTE expected_p8[] = {0x10, 0x1, 0x4, 0x3, 0x4, 0x5, 0xff, 0x80}; > @@ -5322,6 +5336,16 @@ static void test_p8_blit(void) > hr = IDirectDraw_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); > ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > > + /* Locking a P8 surface crashes on WARP if a d3d device has been created. So we > + * need to find the caps via enumeration. */ > + hr = IDirectDraw_QueryInterface(ddraw, &IID_IDirect3D, (void **)&d3d); > + if (SUCCEEDED(hr)) > + { > + hr = IDirect3D_EnumDevices(d3d, is_warp_cb, &is_warp); > + ok(SUCCEEDED(hr), "Failed to enumerate devices, hr %#x.\n", hr); > + IDirect3D_Release(d3d); > + } Can't you just use ddraw4/7's GetDeviceIdentifier()?

2 1

Re: [PATCH] msvcrt/tests: Add tests for mbstowcs and wcstombs with a negative count.
by Piotr Caban June 14, 2016

June 14, 2016

Hi Alex, On 06/12/16 22:07, Alex Henrie wrote: > + ret = mbstowcs(wOut, mSimple, -1); > +todo_wine > + ok(ret == -1 || broken(ret == 4) /* xp */, "mbstowcs returned %i instead of -1\n", ret); This will cause compilation warning: ../../../../wine_src/dlls/msvcrt/tests/string.c:1863:5: warning: format '%i' expects argument of type 'int', but argument 3 has type 'size_t' [-Wformat=] ok(ret == -1 || broken(ret == 4) /* xp */, "mbstowcs returned %i instead of -1\n", ret); I'm also not sure if Windows XP behavior should be marked as broken. For me newer systems behavior is broken (doesn't handle strings longer then INT_MAX). Do you have an application that depends on it? Thanks, Piotr

2 4

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

June 14, 2016

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)); Thanks, Piotr

1 0