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

Re: [PATCH 1/5] ddraw/tests: Move IDirect3DViewport::TransformVertices tests to ddraw1.c.
by Henri Verbeet 30 Aug '16

30 Aug '16

On 29 August 2016 at 23:01, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + * is transformed, and this vertex is offscreen.· Trailing whitespace. As an aside, those float comparisons are probably safe enough, but perhaps those should use compare_vec4()?

1 0

Re: kernel32: Stub CAL_RETURN_GENITIVE_NAMES flag.
by Nikolay Sivov 30 Aug '16

30 Aug '16

On 29.08.2016 22:24, David Keijser wrote: > This stops GetCalendarInfoW from reporting unknown caltype when it's > really a case of unsupported flags. > > Signed-off-by: David Keijser <keijser(a)gmail.com> > --- > dlls/kernel32/time.c | 4 +++- > include/winnls.h | 7 ++++--- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/time.c b/dlls/kernel32/time.c > index b7a7918..e1fd107 100644 > --- a/dlls/kernel32/time.c > +++ b/dlls/kernel32/time.c > @@ -860,6 +860,8 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > FIXME("flag CAL_NOUSEROVERRIDE used, not fully implemented\n"); > if (CalType & CAL_USE_CP_ACP) > FIXME("flag CAL_USE_CP_ACP used, not fully implemented\n"); > + if (CalType & CAL_RETURN_GENITIVE_NAMES) > + FIXME("flag CAL_RETURN_GENITIVE_NAMES used, not fully implemented\n"); Hi, David. LOCALE_RETURN_GENITIVE_NAMES itself is implemented, you should pass it to GetLocaleInfo instead of stripping it from caltype. P.S. anyone working on translations please take another look at SMONTHNAME* constants for your language, to make sure genitive forms are there, if applicable. > > if (CalType & CAL_RETURN_NUMBER) { > if (!lpValue) > @@ -878,7 +880,7 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > > /* FIXME: No verification is made yet wrt Locale > * for the CALTYPES not requiring GetLocaleInfoA */ > - switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP)) { > + switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP|CAL_RETURN_GENITIVE_NAMES)) { > case CAL_ICALINTVALUE: > if (CalType & CAL_RETURN_NUMBER) > return GetLocaleInfoW(Locale, LOCALE_RETURN_NUMBER | LOCALE_ICALENDARTYPE, > diff --git a/include/winnls.h b/include/winnls.h > index 1a7baaf..3d950f6 100644 > --- a/include/winnls.h > +++ b/include/winnls.h > @@ -471,9 +471,10 @@ static const WCHAR LOCALE_NAME_SYSTEM_DEFAULT[] = {'!','s','y','s','-','d','e',' > #define MAX_DEFAULTCHAR 2 > > /* Defines for calendar handling */ > -#define CAL_NOUSEROVERRIDE LOCALE_NOUSEROVERRIDE > -#define CAL_USE_CP_ACP LOCALE_USE_CP_ACP > -#define CAL_RETURN_NUMBER LOCALE_RETURN_NUMBER > +#define CAL_NOUSEROVERRIDE LOCALE_NOUSEROVERRIDE > +#define CAL_USE_CP_ACP LOCALE_USE_CP_ACP > +#define CAL_RETURN_NUMBER LOCALE_RETURN_NUMBER > +#define CAL_RETURN_GENITIVE_NAMES LOCALE_RETURN_GENITIVE_NAMES > > #define CAL_ICALINTVALUE 0x01 > #define CAL_SCALNAME 0x02 >

2 1

Re: [PATCH 5/5] ddraw/tests: Extend TransformVertices invalid data tests.
by Marvin 29 Aug '16

29 Aug '16

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=25440 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 3/5] ddraw: Fix offscreen flag handling in TransformVertices.
by Marvin 29 Aug '16

29 Aug '16

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=25439 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 2/5] ddraw: Copy extra vertex data in viewport::TransformVertices.
by Marvin 29 Aug '16

29 Aug '16

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=25438 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 1/5] ddraw/tests: Move IDirect3DViewport::TransformVertices tests to ddraw1.c.
by Marvin 29 Aug '16

29 Aug '16

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=25437 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit d3d) === d3d.c:2051: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2235: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2382: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [v2 2/2] winejoystick.drv: Disable joysticks via wine registry on Mac
by Ken Thomases 29 Aug '16

29 Aug '16

Hi, On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static void char_device_name_length(IOHIDDeviceRef device, char *name, int max_length) > +{ > + CFStringRef str = copy_device_name(device); > + CFIndex len = CFStringGetLength(str); > + > + if (name) > + name[0] = 0; > + > + if (max_length >= len) > + { > + CFStringGetCString(str,name,max_length,kCFStringEncodingASCII); > + CFRelease(str); > + } > + else > + { > + CFStringRef substr = CFStringCreateWithSubstring(kCFAllocatorDefault, str, CFRangeMake(0, max_length)); > + CFRelease(str); > + CFStringGetCString(substr,name,max_length,kCFStringEncodingASCII); > + CFRelease(substr); > + } > +} I realize you based this function on code from DInput. Unfortunately, that code is pretty badly broken. CFStringGetLength() returns the length of the string in UTF-16 code units, which is basically the same as WCHARs. It's not meaningful to compare that to a buffer size that's in ASCII chars. Using ASCII is wrong, too. If the name has any non-ASCII characters in it, the conversion will just fail. Second, it's potentially unnecessarily restrictive. Your device_disabled_registry() function, by virtue of using the "A" variant RegQueryValueEx(), uses the ANSI code page, not ASCII. The ANSI code page could maybe handle more names than ASCII would. You could get a wide string and then use WideCharToMultiByte() to convert it to CP_ACP, but since you control all of the relevant code, it's just better to work with wide strings throughout. Change your device_disabled_registry() and get_config_key() functions to accept a wide string. Then, you can safely use CFStringGetLength() and CFStringGetCharacters() to acquire the WCHAR-based wide string from the CFString. You can just cast a WCHAR* to a UniChar*. -Ken

1 0

Re: [v2 1/2] winejoystick.drv: Add functionality to disable joystick via registry
by Ken Thomases 29 Aug '16

29 Aug '16

On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > + get_app_key(&hkey, &appkey); > + > + /* Joystick settings are in the 'joysticks' subkey */ > + if (appkey) > + { > + if (RegOpenKeyA(appkey, joystick_key, &temp)) temp = 0; > + RegCloseKey(appkey); > + appkey = temp; > + } > + if (hkey) > + { > + if (RegOpenKeyA(hkey, joystick_key, &temp)) temp = 0; > + RegCloseKey(hkey); > + hkey = temp; > + } It seems the appending of the Joysticks subkey should be done in get_app_key(). -Ken

1 0

Re: rpcrt4/tests: Don't load GetUserNameEx dynamically.
by Marvin 29 Aug '16

29 Aug '16

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=25430 Your paranoid android. === w864 (32 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {9d7329b2-6dfd-11e6-be78-e71666c2e04a} === w864 (64 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {cfff88a2-6dfd-11e6-be78-e71666c2e04a} === w8 (32 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 2000814083 instead of RE3 === w864 (32 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 === w864 (64 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 117440515 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3 === w1064 (64 bit server) === server.c:1010: Test failed: get_ranged_enum() returned 6356995 instead of RE3 server.c:1010: Test failed: get_ranged_enum() returned 6029315 instead of RE3

1 0

Re: d3drm/tests: Fix crash when surface can't be created
by Henri Verbeet 29 Aug '16

29 Aug '16

On 28 August 2016 at 16:49, André Hentschel <nerv(a)dawncrow.de> wrote: > Should fix crashes like: > https://test.winehq.org/data/a83d5d3b83042d2305de0595c0d03e4e7bf1e29e/xp_wx… > Does this happen on any setups that aren't using "VirtualBox Graphics Adapter" as display driver? I don't think failing the test or skipping is ultimately much more useful than crashing here, but if it's just about skipping cleanly I'd rather just blacklist the driver in a way similar to ddraw_is_warp() in the ddraw tests.

1 0