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

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger 05 Jul '15

05 Jul '15

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Re: [4/7] ntdll/tests: Add basic tests for threadpool wait objects.
by Marvin 05 Jul '15

05 Jul '15

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=15039 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:734: Test failed: WaitForSingleObject returned 258

2 1

Re: ole32: Accept STG_E_UNIMPLEMENTEDFUNCTION when ILockBytes implementation doesn't support locking.
by Nikolay Sivov 04 Jul '15

04 Jul '15

On 03.07.2015 10:27, Dmitry Timoshkov wrote: > Some custom implementations return it instead of STG_E_INVALIDFUNCTION. > --- > dlls/ole32/storage32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ole32/storage32.c b/dlls/ole32/storage32.c > index 220e17e..aa53758 100644 > --- a/dlls/ole32/storage32.c > +++ b/dlls/ole32/storage32.c > @@ -5015,7 +5015,7 @@ static HRESULT StorageImpl_GrabLocks(StorageImpl *This, DWORD openFlags) > hr = StorageImpl_LockRegionSync(This, offset, cb, LOCK_ONLYONCE); > > /* If the ILockBytes doesn't support locking that's ok. */ > - if (hr == STG_E_INVALIDFUNCTION) return S_OK; > + if (hr == STG_E_INVALIDFUNCTION || hr == STG_E_UNIMPLEMENTEDFUNCTION) return S_OK; > else if (FAILED(hr)) return hr; > > hr = S_OK; > It looks like StorageImpl_LockRegionSync should be fixed instead to filter some error codes. Could you add a test with external ILockBytes implementation that does that?

3 7

Re: [PATCH 5/6]: msvcp110: Add tr2_sys__Lstat implementation and test.(resend)
by Piotr Caban 04 Jul '15

04 Jul '15

On 07/03/15 06:00, YongHaoHu wrote: > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PBDAAH(a)Z */ > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PEBDAEAH(a)Z */ > +file_type tr2_sys__Lstat(char const* path, int *err_code) > +{ > + DWORD attr; > + TRACE("(%s %p)\n", debugstr_a(path), err_code); > + if(!path) { > + *err_code = ERROR_INVALID_PARAMETER; > + return status_unknown; > + } > + > + attr = GetFileAttributesA(path); > + if(attr == INVALID_FILE_ATTRIBUTES) > + return stat_set_error(err_code); > + if(attr & FILE_ATTRIBUTE_REPARSE_POINT) > + FIXME("reparse point is not supported yet\n"); > + > + *err_code = ERROR_SUCCESS; > + return (attr & FILE_ATTRIBUTE_DIRECTORY)?directory_file:regular_file; > +} What's the reason for not calling tr2_sys__Stat function here? Thanks, Piotr

2 3

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte 03 Jul '15

03 Jul '15

I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:> Other devices then mouse&keyboard produce undocumented blobs of bytes;> to interpret them, functions from the hid.dll are used. Currently they> are unimplemented stubs in WINE as well as not the problem I am solving.> There is a recent article about this subject - Using the Raw Input API> to Process Joystick Input -> http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Also, could one create an adaptation from some joystick input libraries (evdev/x11) and make it conform to the API in the CodeProject example, making modifications similar to Henri Verbeet's and have built-in support for this? (Henri Verbeet's rawinput contributions: http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) I see that Wine already has support for joysticks in some other fashion (the gamepad I'm working with shows up in the `wine control` Game Controller testing interface), and I bet it's a good idea to leverage that adaptation (those adaptations...) than to start adding my own. Any direction here would be appreciated. I think I understand the separation between the wineserver (mainly server/queue.c) and the dlls (dlls/user32/*), but I see that there are other "dlls" that don't use (or don't appear to use, given my probably incorrect understanding) wineserver for their adaptation, and instead talk directly with the Linux libs to do their work (I'm assuming). Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

1 0

Re: [PATCH 1/2] d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger 03 Jul '15

03 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-01 um 01:03 schrieb Aaryaman Vasishta: > +static ULONG WINAPI d3drm_device1_AddRef(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + ULONG refcount = InterlockedIncrement(&device->ref); > + > + TRACE("%p increasing refcount to %u.\n", iface, refcount); > + > + return refcount; > +} > + > +static ULONG WINAPI d3drm_device1_Release(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + > + return IDirect3DRMDevice2_Release(&device->IDirect3DRMDevice2_iface); > +} Why are you forwarding Release to d3drmdevice2 but not Addref? I think we should look again at moving the IUnknown methods to Device3, so we don't thunk to the middle child and stay consistent with the other methods. Please send an extra patch before this one that migrates the code to device3. I remember we already looked at this. If this failed in some spectacular way please remind me :-) . Is there a logic behind which method forwards to device3 and which just returns E_NOTIMPL? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVk+jzAAoJEN0/YqbEcdMwL/MP/jmYjvhWcVOosMP2FyKVaezA c4SqCONBE+xPvhmC97IfPXZ8wJQUjH0tt5CjZN2JZTY0yw50bEM4JHDfC1pPjF3O IX4qKllp0UeAeNCNKu64a8rxYT2kLRwLp7zs+GO7YygwimKy9DAMxUCW5+IP4DiB bsO1wTcSWlCHQ8c4ikUou6aIY/npJ+UqVS8DNGl5m1cLw6oUdzZMvcurSooH2LUv 1oq4XC1DQe/wx3Ob826xY8w/2v6CM0JDAgAT1dGqxIWDS5DNzsKj9P8oKEso/C8c thpZdsIvgQLEkfmKgN6wRh9h03aAMVHbXoSmGVihaapSspF7299DYrDyoiQvYxEq k+SgAMqHAtAzfXkQto9n0f8FjiLEJzbFu9WMoKLJmjdk7hpH8CXPsoioA/o8xNDA 8dB9LxITlJuK5oEUczGhdrnN144Ml8AkZbs+DBcvTdHvaOaY7urL2sZ6/QuvGtAY IGGeUnPW2VBMGpg1YlSn9OmziBibrjKOVtXHVmbwYQhZhXOcfzgMT+QBBV2eQ/pQ 0tmDnUk93+ungNnc4slfLZo+uZ8/8kvPRMv8fYPcQjkcXOIRCobup4bqx3vrQVWT zOx05HKBDQihZAxZuHynFaNqA5E1QbhbPac0BsOSLk8r4zSKx58BgNLBYWz51oe6 NN959TJY84womG8/lfFc =jkwG -----END PGP SIGNATURE-----

2 1

Re: [2/2] shell32/tests: Destroy shell view windows.
by Nikolay Sivov 03 Jul '15

03 Jul '15

On 02.07.2015 13:36, Thomas Faber wrote: > When calling IShellView::CreateViewWindow, the window itself takes > references to the shell view and related objects (e.g. for a drop > target). This means just calling IShellView::Release is not enough to > properly clean up, the window needs to be destroyed as well. > Could you please also add a test that shows window is still being alive after IShellView was released? It could be a separate patch.

2 1

Re: [PATCH 4/6]: msvcp110: Add tr2_sys__Stat implementation and test.(try 2)
by Piotr Caban 03 Jul '15

03 Jul '15

On 07/03/15 05:59, YongHaoHu wrote: > +static file_type stat_set_error(int *err_code) > +{ > + file_type ret; > + > + switch(GetLastError()) { > + case ERROR_FILE_NOT_FOUND: > + case ERROR_BAD_NETPATH: > + case ERROR_INVALID_NAME: > + case ERROR_BAD_PATHNAME: > + case ERROR_PATH_NOT_FOUND: > + ret = file_not_found; > + *err_code = ERROR_SUCCESS; > + break; > + case ERROR_SUCCESS: > + ret = regular_file; > + *err_code = ERROR_SUCCESS; > + break; Why are you handling ERROR_SUCCESS here? stat_set_error function is only called in case of error. Are you planning to reuse this function somewhere else? If not it might be part of tr2_sys__Stat function. Thanks, Piotr

1 0

Re: [PATCH 2/6]: msvcp110: Add tr2_sys__Rename implementation and test. (try 2)
by Piotr Caban 03 Jul '15

03 Jul '15

On 07/03/15 05:56, YongHaoHu wrote: > + if(MoveFileExA(old_path, new_path, MOVEFILE_REPLACE_EXISTING|MOVEFILE_COPY_ALLOWED)) According to my testing MOVEFILE_REPLACE_EXISTING flag should not be used here. Thanks, Piotr

1 0

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.(try 2)
by YongHaoHu 03 Jul '15

03 Jul '15

Hi, all. Found a mistake of tr2_sys__Copy_file, please ignore this patch. Thank you. On 15/7/3 上午11:55, YongHaoHu wrote: > try2 : > Add is_todo in test. > Delete useless SetLastError. > > --- > dlls/msvcp110/msvcp110.spec | 4 +-- > dlls/msvcp120/msvcp120.spec | 4 +-- > dlls/msvcp120/tests/msvcp120.c | 59 > +++++++++++++++++++++++++++++++++++++ > dlls/msvcp120_app/msvcp120_app.spec | 4 +-- > dlls/msvcp90/ios.c | 10 +++++++ > 5 files changed, 75 insertions(+), 6 deletions(-) > >

1 0