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

Re: Enabling/Disabling Joysticks from registry for the Mac

by DavidL

>From what you're saying, it seems like maybe the best approach would be for now to keep the joy.cpl code the way it is and have the Mac code imitate the Linux code so as not to break current functionality. However, I agree that when you guys implement the new HID support, a more systematic & robust method for this will probably be needed. Hopefully some of what we're doing/have done will be useful for you guys when developing the new HID code base! :) I'll try to get cracking on the registry support. Cheers, David On Sat, Jul 30, 2016 at 1:40 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hi, > > On Jul 30, 2016, at 2:15 AM, DavidL <david.dljunk(a)gmail.com> wrote: > > > > I was looking into how the Linux-dinput code and joy.cpl work and > comparing that to the macOS-dinput code. I have some questions about how > best to proceed: > > > > joy.cpl uses joy->instance.tszInstanceName to name the joysticks in the > control panel. In Linux-dinput code, they pass the > joystick_devices[id].name to both tszInstanceName and tszProductName In > the macOS-dinput code, they pass the name "Joystick #" where # is the index > in the joystick array to the instance name and the joystick's actual name > to the product name. When looking at the Microsoft guidelines for dinput, > it does indeed say that the instance name *can* be joystick + position in > the array, but doesn't specify that it *has* to be ( > https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_…) > Also, I've confirmed that in the Windows 10 joystick control panel the > joysticks are listed by their name, not by joystick number (and in my > memory of earlier Windows OSes it's the same). > > > > So, should I change the macOS-dinput code to set both tszInstanceName > and tszProductName to the product name (as in Linux) or should I change > joy.cpl to use tszProductName instead of tszInstanceName? This will also > make it easier in the registry to know which joystick is being > enabled/disabled. > > We need to distinguish between an object's internal identifier and what's > displayed in UI. > > It seems to me that joy.cpl and dinput ought to use the guidInstance field > to determine which devices are enabled or disabled. That would require > that the backends actually provide a guidInstance that's unique among > devices but stable across runs and attachment/detachment of devices. > Unfortunately, I'm not sure how practical that is. Some devices seem to > provide kIOHIDSerialNumberKey, but not all do. kIOHIDLocationIDKey is > stable so long as the USB topology doesn't change, but it can change, of > course. An experiment shows that the location ID changes if you just plug > the device into a different point in the topology (a USB port on the > computer vs. one on the keyboard, which is a hub). > > Also, if you change how this works, everybody's existing registry settings > will break. > > So, perhaps a decent compromise would be for joy.cpl to display both the > instance and the product name (e.g. "Joystick 1 - Logitech Extreme 3D Pro") > but record the instance name in the registry. On Linux, I guess that may > make the name looked doubled, if the instance and product names are the > same. > > On the Mac, we should probably change the instance name to something > that's really associated with the device. The index in the device array is > not stable. If you disconnect the first joystick, all other joysticks will > get renumbered in that scheme. Probably, the location ID is the closest we > have to a stable ID (which is why you've used it for sorting). It's just > too bad that it's an ugly number, whether formatted decimal or hexadecimal. > > Another approach would be for the Mac code to basically build a dynamic > database of every game controller it ever encounters, storing all of the > available stable identifying information about each, and assigning a > permanent identifier. So, location ID would not be used because it's not > truly stable, but vendor ID, product ID, manufacturer, product name, serial > number, version number, usage pairs, and maybe even the report descriptor > could be. As it enumerates devices, it would look through the database to > find one that matches all of the these available pieces of metadata. If it > does, it will reuse the previously-generated identifier. Otherwise, it > will generate a new identifier and add the device to the database. There > would have to be a check, in case there are two exactly identical devices > attached, to not use the same identifier for both. In practice, the > database should never grow very large since one system should never have > very many devices connected to it over its history. > > > > Further, while joy.cpl correctly is a dinput control panel, > enabling/disabling joystick should be for both dinput and winmm games - > e.g. X-wing vs Tie Fighter even has the joystick control panel in the > game's loader window*, but, once in the game, joystick control is handled > by winmm. I believe the joystick registry entry is under dinput, but the > winmm wine joystick driver should read that as well. > > > > Is it acceptable for wine joystick driver to read the dinput registry? > Or should two registry entries be created? or should a single general > joystick registry entry not under dinput or winmm control both? > > Well, the registry key is actually Wine-specific. It's got "DirectInput" > in the path, but we can play a little fast and lose with it. No Windows > app is sensitive to what's under that key, for example. I see no problem > with having winmm check it. > > There's work underway to implement proper HID support and then reimplement > lots of different APIs (dinput, winmm joystick, xinput, raw input) on top > of that. When that happens, a lot of this will probably have to change and > redundancy will hopefully be eliminated. (If it's going to break people's > settings, it may be a good time to switch to using guidInstance or the > equivalent, too.) > > -Ken > >

Aug. 3, 2016

Re: [PATCH 2/2] kernel32/tests/thread: Add tests for fiber-local storage.

by Marvin

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=24688 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

Aug. 2, 2016

Re: [PATCH 1/2 v2] kernel32/tests/loader: Add tests for fiber-local storage.

by Marvin

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=24687 Your paranoid android. === w1064 (32 bit loader) === loader.c:2980: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2981: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2980: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2981: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2980: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2981: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2988: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2989: Test failed: Test 3: Wrong callback count: 0 loader.c:2988: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2989: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784

Aug. 2, 2016

Re: [PATCH] d3dx10: Implement D3DX10CreateDeviceAndSwapChain

by Matteo Bruni

2016-08-02 9:48 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > + TRACE("adapter %p, driver_type %d, swrast %p, flags %#x, desc %p, swapchain %p, device %p\n", > + adapter, driver_type, swrast, flags, desc, swapchain, device); Missing period at the end of the trace message. > + if (SUCCEEDED(hr = D3D10CreateDeviceAndSwapChain1(adapter, driver_type, swrast, flags, D3D10_FEATURE_LEVEL_10_1, > + D3D10_1_SDK_VERSION, desc, swapchain, (ID3D10Device1 **)device))) > + return hr; > + > + if (SUCCEEDED(hr = D3D10CreateDeviceAndSwapChain1(adapter, driver_type, swrast, flags, D3D10_FEATURE_LEVEL_10_0, > + D3D10_1_SDK_VERSION, desc, swapchain, (ID3D10Device1 **)device))) > + return hr; > + > + return hr; > +} The second if is redundant, you're going to "return hr;" either way.

Aug. 2, 2016

Re: RFC: usp10/tests: Reserve for InClass a byte for every character in teststr.

by Marvin

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=24683 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

Aug. 2, 2016

Re: [PATCH 1/2] kernel32/tests/loader: Add tests for fiber-local storage.

by Alexandre Julliard

John Sheu <sheu(a)google.com> writes: > Signed-off-by: John Sheu <sheu(a)google.com> > --- > dlls/kernel32/tests/loader.c | 125 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 123 insertions(+), 2 deletions(-) The tests fail here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so loader && touch loader.ok loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 make[1]: *** [loader.ok] Error 14 -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2016

Re: [PATCH v2] msxml3/test: Add XMLParser Tests

by Nikolay Sivov

On 02.08.2016 11:02, Alistair Leslie-Hughes wrote: > With Signed-off. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/msxml3/tests/xmlparser.c | 196 ++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 188 insertions(+), 8 deletions(-) > > diff --git a/dlls/msxml3/tests/xmlparser.c b/dlls/msxml3/tests/xmlparser.c > index 32514e3..bf896e4 100644 > --- a/dlls/msxml3/tests/xmlparser.c > +++ b/dlls/msxml3/tests/xmlparser.c > @@ -26,8 +26,45 @@ > #include "windows.h" > #include "ole2.h" > #include "xmlparser.h" > +#include "rpcproxy.h" > #include "wine/test.h" Why do you need this? > + > +static HRESULT hresult_NotifyEvent = S_OK; Please move this global variable to factory instance. > > static HRESULT WINAPI nodefact_QueryInterface(IXMLNodeFactory *iface, > REFIID riid, void **ppvObject) > @@ -54,34 +91,67 @@ static ULONG WINAPI nodefact_Release(IXMLNodeFactory *iface) > } > > static HRESULT WINAPI nodefact_NotifyEvent(IXMLNodeFactory *iface, > - IXMLNodeSource *pSource, XML_NODEFACTORY_EVENT iEvt) > + IXMLNodeSource *source, XML_NODEFACTORY_EVENT event) > { > - return E_NOTIMPL; > + switch(event) > + { > + case XMLNF_STARTDOCUMENT: > + CHECK_EXPECT(NotifyStartDocument); > + trace("NotifyEvent: XMLNF_STARTDOCUMENT\n"); > + break; > + case XMLNF_ENDPROLOG: > + CHECK_EXPECT(NotifyEndProlog); > + trace("NotifyEvent: XMLNF_ENDPROLOG\n"); > + break; > + case XMLNF_ENDDOCUMENT: > + CHECK_EXPECT(NotifyEndDocument); > + trace("NotifyEvent: XMLNF_ENDDOCUMENT\n"); > + break; > + case XMLNF_DATAAVAILABLE: > + CHECK_EXPECT(NotifyDataAvailable); > + trace("NotifyEvent: XMLNF_DATAAVAILABLE\n"); > + break; > + default: > + ok(0, "Unsupported NotifyEvent %p %d\n", source, event); > + return E_FAIL; > + } > + > + return hresult_NotifyEvent; > } Arguably trace()'s are not really useful in this context, and will appear on every parsing test. > > static HRESULT WINAPI nodefact_BeginChildren(IXMLNodeFactory *iface, > IXMLNodeSource *pSource, XML_NODE_INFO *pNodeInfo) > { > - return E_NOTIMPL; > + trace("nodefact_BeginChildren %p %p %d\n", pSource, pNodeInfo, > + pNodeInfo ? pNodeInfo->dwType : 0); > + return S_OK; > } > > static HRESULT WINAPI nodefact_EndChildren(IXMLNodeFactory *iface, > IXMLNodeSource *pSource, BOOL fEmpty, XML_NODE_INFO *pNodeInfo) > { > - return E_NOTIMPL; > + trace("nodefact_EndChildren %p %d %p %d\n", pSource, fEmpty, pNodeInfo, > + pNodeInfo ? pNodeInfo->dwType : 0); > + return S_OK; > } > > static HRESULT WINAPI nodefact_Error(IXMLNodeFactory *iface, > IXMLNodeSource *pSource, HRESULT hrErrorCode, USHORT cNumRecs, > XML_NODE_INFO **ppNodeInfo) > { > - return E_NOTIMPL; > + CHECK_EXPECT(FactoryError); > + trace("nodefact_Error %p %08x %d %p\n", pSource, hrErrorCode, cNumRecs, ppNodeInfo); > + return S_OK; > } > > -static HRESULT WINAPI nodefact_CreateNode(IXMLNodeFactory *iface, IXMLNodeSource *pSource, > - PVOID pNodeParent, USHORT cNumRecs, XML_NODE_INFO **ppNodeInfo) > +static HRESULT WINAPI nodefact_CreateNode(IXMLNodeFactory *iface, IXMLNodeSource *source, > + void *parent, USHORT recs, XML_NODE_INFO **nodeinfo) > { > - return E_NOTIMPL; > + trace("nodefact_CreateNode %p %p %d %p\n", source, parent, recs, nodeinfo); > + > + *nodeinfo = NULL; > + > + return S_OK; > } > > static const IXMLNodeFactoryVtbl nodefactoryVtbl = > @@ -150,6 +220,114 @@ static void create_test(void) > IXMLParser_Release(parser); > } > > +static void parse_documnet(void) > +{ > + HRESULT hr; > + IXMLParser *parser; > + IStream* stream = NULL; > + HGLOBAL hMem; > + LPBYTE bytes; > + > + hr = CoCreateInstance(&CLSID_XMLParser30, NULL, CLSCTX_INPROC_SERVER, &IID_IXMLParser, (void**)&parser); > + if (FAILED(hr)) > + { > + win_skip("IXMLParser is not available (0x%08x)\n", hr); > + return; > + } > + > + hMem = GlobalAlloc(GMEM_MOVEABLE, strlen(empty_document)); > + bytes = GlobalLock(hMem); > + memcpy(bytes, empty_document, strlen(empty_document)); > + GlobalUnlock(hMem); > + > + CreateStreamOnHGlobal(hMem, TRUE, &stream); > + > + hr = IXMLParser_SetFactory(parser, &thenodefactory); > + ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > + > + hr = IXMLParser_SetInput(parser, (IUnknown *)stream); > + ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > + > + hr = IXMLParser_GetParserState(parser); > + ok(hr == XMLPARSER_IDLE, "got 0x%08x\n", hr); > + > + SET_EXPECT(NotifyStartDocument); > + SET_EXPECT(NotifyEndDocument); > + SET_EXPECT(NotifyEndProlog); > + SET_EXPECT(NotifyDataAvailable); > + hr = IXMLParser_Run(parser, -1); > + todo_wine ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > + todo_wine CHECK_CALLED(NotifyStartDocument); > + todo_wine CHECK_CALLED(NotifyEndDocument); > + todo_wine CHECK_CALLED(NotifyEndProlog); > + todo_wine CHECK_CALLED(NotifyDataAvailable); Main problem is that this does not test actual callback order - actual ordering is - start document; - create node; - end children; - end prolog; - data available; - end document; Please use test sequences facility saxreader.c is using - add_call(), ok_sequence(), etc. > START_TEST(xmlparser) > { > HRESULT hr; > @@ -160,6 +338,8 @@ START_TEST(xmlparser) > return; > > create_test(); > + parse_documnet(); > + parse_documnet_error(); I guess it was meant to be 'document'. > > CoUninitialize(); > } >

Aug. 2, 2016

Re: [PATCH 10/11] dxgi: Add multi-monitor test for IDXGISwapChain_GetContainingOutput().

by Matteo Bruni

2016-08-01 22:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>: > + refcount = IDXGIOutput_Release(output); > + ok(!refcount, "IDXGIOuput has %u references left.\n", refcount); > refcount = IDXGIOutput_Release(output2); > ok(!refcount, "IDXGIOuput has %u references left.\n", refcount); There are a number of those "Ouput" typos through the patch, probably copypasted from this preexisting ok() message. Certainly not worth a resend by itself, but since you're going to anyway...

Aug. 2, 2016

Re: [PATCH 02/11] wined3d: Add WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH flag.

by Matteo Bruni

2016-08-01 22:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>: > - FIXME("Ignoring SwapEffect and Flags\n"); > + FIXME("Ignoring SwapEffect %#x.\n", desc->SwapEffect); Yes please. I ended up making a similar change for debugging at least twice in separate occasions (even though in neither case the swap effect had anything to do with the issue at hand) but I didn't feel like sending just the trace change and I never completed a patch actually passing the swap effect to wined3d. I still might at some point, but in the meantime I'd love to see the actual swap effect traced.

Aug. 2, 2016

Re: wine-1.8.4-rc1

by Michael Stefaniuc

On 08/01/2016 01:01 PM, Hugh McMaster wrote: > On Sunday, 31 July 2016 11:19 PM, André Hentschel wrote: > >> Am 30.07.2016 um 22:49 schrieb Michael Stefaniuc: >>> Hello guys, >>> >>> I have pushed wine-1.8.4-rc1 (with tag) to >>> https://github.com/mstefani/wine-stable >> >> It builds fine in buildroot, but then thinks it's a 1.8.3 build (./wine --version told me so), despite "Wine version >1.8.4" in the VERSION file > > It's just a mistake in the configure file. Not a mistake, Alexandre generates the configure part before pushing out the final 1.8.4. This is just to avoid noise due to differences in autoconf versions. > > # Identity of this package. > PACKAGE_NAME='Wine' > PACKAGE_TARNAME='wine' > PACKAGE_VERSION='1.8.3' > PACKAGE_STRING='Wine 1.8.3' bye michael

Aug. 2, 2016