wine-devel April 2015

wine-devel@winehq.org

54 participants
164 discussions

Start a nNew thread

Re: [PATCH 1/2] ntdll/tests: Add test for FileFsFullSizeInformation(try 2)
by Marvin 17 Apr '15

17 Apr '15

1 0

WineConf 2015
by Michael Stefaniuc 17 Apr '15

17 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello guys, after we rethought WineConf and did it at/during FOSDEM for the last two years, it is time for a real WineConf again. We are missing too much our keynote, our governance discussions as well as our hackatons. Also the two full days should give more time for the most important topic aka the hallway discussions. After two years in Europe the old tradition would call for a session over in USA/Canada but this is not a strict requirement. Now the most important thing is to find volunteers that would want to host the WineConf. They have the bigger say in the date too, there are two options: - - either in late spring (preferred by me), - - or early fall (preferred by Jeremy) I have started also http://wiki.winehq.org/WineConf2015 please feel free to add agenda topics to it. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTY5awACgkQ0ei8kcpE1VG2YQCguwUys0se+wV96lPfjZ+Qi6LJ 8ooAoJDxist2eZLgMXsRqUZVloGpBRgz =7Ta5 -----END PGP SIGNATURE-----

6 12

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings.
by Ken Thomases 16 Apr '15

16 Apr '15

This hoists some of the knock-on effects of WM_MACDRV_UPDATE_DESKTOP_RECT to the place where it is sent. However, it only does so for one of the two places where it is sent. It is also sent in macdrv_displays_changed() On Apr 16, 2015, at 5:18 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Same as the previous patch, just for winemac.drv. > > The message ping-pong between the ChangeDisplaySettings calling thread > and the desktop thread is more complicated here than in winex11. The > problem again is that sendMessageTimeout(SMTO_BLOCK) will not process > messages sent by the desktop, leading to a deadlock. Replacing > SendMessageTimeout in the desktop with PostMessage is not an option > either because then messages will be executed in a different order in > the thread that called ChangeDisplaySettings. > > This patch will lead to DISPLAYCHANGE messages being sent on redundant > changes. This matches the behavior of winex11 and happens to fix the > user32/sysparam.ok test, but it fixes it for the wrong reason (the real > problem afaics is that OSX only supports 32 bpp, so no change takes > place although one was requested). I think redundant changes should be > intercepted in user32 before the display driver is called. > --- > dlls/winemac.drv/display.c | 8 ++++++-- > dlls/winemac.drv/window.c | 4 ---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/winemac.drv/display.c b/dlls/winemac.drv/display.c > index 10ecf67..f7ce163 100644 > --- a/dlls/winemac.drv/display.c > +++ b/dlls/winemac.drv/display.c > @@ -564,8 +564,12 @@ better: > size_t width = CGDisplayModeGetWidth(best_display_mode); > size_t height = CGDisplayModeGetHeight(best_display_mode); > > - SendMessageW(GetDesktopWindow(), WM_MACDRV_UPDATE_DESKTOP_RECT, mode_bpp, > - MAKELPARAM(width, height)); > + SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_RESET_DEVICE_METRICS, 0, 0, > + SMTO_BLOCK | SMTO_ABORTIFHUNG, 2000, NULL); > + SendMessageTimeoutW(GetDesktopWindow(), WM_MACDRV_UPDATE_DESKTOP_RECT, mode_bpp, > + MAKELPARAM(width, height), SMTO_BLOCK, ~0U, NULL); > + SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_DISPLAYCHANGE, mode_bpp, > + MAKELPARAM(width, height), SMTO_BLOCK | SMTO_ABORTIFHUNG, 2000, NULL); > ret = DISP_CHANGE_SUCCESSFUL; > } > else > diff --git a/dlls/winemac.drv/window.c b/dlls/winemac.drv/window.c > index 7a777e6..fa12af5 100644 > --- a/dlls/winemac.drv/window.c > +++ b/dlls/winemac.drv/window.c > @@ -1666,13 +1666,9 @@ LRESULT CDECL macdrv_WindowMessage(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) > if (!GetWindowRect(hwnd, &current_desktop_rect) || > !CGRectEqualToRect(cgrect_from_rect(current_desktop_rect), new_desktop_rect)) > { > - SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_RESET_DEVICE_METRICS, 0, 0, > - SMTO_ABORTIFHUNG, 2000, NULL); > SetWindowPos(hwnd, 0, CGRectGetMinX(new_desktop_rect), CGRectGetMinY(new_desktop_rect), > CGRectGetWidth(new_desktop_rect), CGRectGetHeight(new_desktop_rect), > SWP_NOZORDER | SWP_NOACTIVATE | SWP_DEFERERASE); > - SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_DISPLAYCHANGE, wp, lp, > - SMTO_ABORTIFHUNG, 2000, NULL); > } > } > return 0; > -- > 2.3.4 > > >

1 0

Re: [PATCH 1/2] d3drm/tests: Make get_refcount return ULONG instead of int.
by Stefan Dösinger 16 Apr '15

16 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 These patches look good to me. On 04/13/15 18:59, Aaryaman Vasishta wrote: > --- dlls/d3drm/tests/d3drm.c | 2 +- 1 file changed, 1 insertion(+), > 1 deletion(-) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 2f154f9..f089707 100644 --- a/dlls/d3drm/tests/d3drm.c +++ > b/dlls/d3drm/tests/d3drm.c @@ -33,7 +33,7 @@ ok(count == rc_new, > "Invalid refcount. Expected %d got %d\n", rc_new, count); \ } > > -static int get_refcount(IUnknown *object) +static ULONG > get_refcount(IUnknown *object) { IUnknown_AddRef( object ); return > IUnknown_Release( object ); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVL81eAAoJEN0/YqbEcdMwrRYP/j37mA7B6bg9RveFxAYQS8VX AVROgmPd+hZDl/JKKnSMrUgHU3Y6MtCGwKd6Pb42yRhpU8qw/j6dPW1QqUYSII0V MpqpON1tY6WRV8M2eCBJ5+qLBwzFDxi51a4ta+7BUbK6Jl9IJw58OdyL5pt5WSID XneEmweh3BVI3ay4ZYn5jlK53BArCFu5yfclYPklL5uNb4sdA5zTJoavvwUHYMHc grjeEXAxRnBn8zmD13H5+s8GRC59Sx/vHJl6PTlv2A4bU22HwTku3b7/RbAGyYtB rB4Y+SRUeDn8e5YAe6+kWmwAOORdQFf1plmLx+bjIc13UYlnBTLnOjV8KMZm9vrC nhCcxUVeY3YYahA7q37nEOMZHVt++mX5pJ00vdV47QzZVAat05pA9tiesI3n5IAm DNrDRPV1olBT2OIz20Xo0YvtdBnvkOQDKB+SfYtD8YnGGNw/WZKUEwBh5IpNtvbE iZ/d3AMB1h4A1trWofNR17nZJbTwQwTmIKI6ggw2Cr6DpPb6SFp6odoA4OjajGGB e+sqBTaf5yf2QbDzjn694f4PKAeTZwnkXXzR9Quu2J1Zu4dZFSWFvnFnq5ZMgTqq P1RrnGJJdx9p1JytzRhi9M9vnIr4UUGMNfOOGuw/qvnCyYHXM67ka9leXs82ruK3 aZbHB7YZDSthklM3u+RX =r66h -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings.
by Marvin 16 Apr '15

16 Apr '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=12822 Your paranoid android. === wxppro (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w2003std (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === wvistau64 (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w2008s64 (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w7u (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w8 (32 bit sysparams) === sysparams.c:2493: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2506: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === wvistau64 (64 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w2008s64 (64 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out

1 0

Re: [PATCH 3 / 2] d3d9: Add support for d3d9ex formats
by Sergey Isakov 16 Apr '15

16 Apr '15

Ignore, please, this is included in previous patch. Sorry! On 16.04.2015, at 12:47, Sergey Isakov wrote: > just forget two lines in previous commit > <patch-d3d9ex-d3d9-device.txt>

1 0

Re: [PATCH 1 / 2] d3d9: Add support for D3D9ex new formats
by Stefan Dösinger 16 Apr '15

16 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Do you know a game that needs these formats? Is there a d3d9 game that actually locks the depth buffer? Do Windows drivers support these formats? Am 2015-04-16 um 09:37 schrieb Sergey Isakov: > + case WINED3DFMT_D32_LOCKABLE: return D3DFMT_D32_LOCKABLE; > + case WINED3DFMT_S8_LOCKABLE: return D3DFMT_S8_LOCKABLE; WINED3DFMT_D32_LOCKABLE doesn't exist yet. Your patches are in the wrong order. > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index 174fc13..6934528 100644 > --- a/dlls/d3d9/tests/device.c > +++ b/dlls/d3d9/tests/device.c > @@ -2199,6 +2199,8 @@ static void test_display_modes(void) > TEST_FMT(D3DFMT_R8G8_B8G8, D3DERR_INVALIDCALL); > > TEST_FMT(D3DFMT_D16_LOCKABLE, D3DERR_INVALIDCALL); > + TEST_FMT(D3DFMT_D32_LOCKABLE, D3DERR_INVALIDCALL); > + TEST_FMT(D3DFMT_S8_LOCKABLE, D3DERR_INVALIDCALL); Please add a test that actually uses the format and locks them. It's ok if parts of the test (those that depend on depth transfers to / from system memory) are marked todo since wined3d doesn't handle depth locking at all. > + /* d3d9ex formats */ > + /* Z-Stencil formats valid for CPU access */ > + D3DFMT_D32_LOCKABLE = 84, The second comment is misaligned and I don't think these comments add much information. > + // s10e5 formats (16-bits per channel) This is an unrelated change. C++ comments ("//") are not allowed in Wine as our sources are plain C. > + // Monochrome 1 bit per pixel format > + D3DFMT_A1 = 118, > + // 2.8 biased fixed point > + D3DFMT_A2B10G10R10_XR_BIAS = 119, > + // Binary format indicating that the data has no inherent type > + D3DFMT_BINARYBUFFER = 199, Adding those is OK, but should be in a separate patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVL4cnAAoJEN0/YqbEcdMw6eMP/2b06nt5c3E9Stwm52T7l3aZ ytyrBcrqT7lE2XHVEhFH6te/NSgUXO5KYPqkgZQfx+/YvmnnevXeA1jfIMh5wOoD trBXmIDbhtgt1ABXmOB6CmN710B3zLBwnxMj4rUfiZAHgW4T6aONKxy4VmNGNxnl i5QxgMBOJbsAocu5URUpeiyGd87f3YWD1mTcrtAjwgTSNyF33VAx7O0zcV7Iui9e NY5fzYG7ff19zcPKRDIuOO0/ga93yYh6OcesiyUon+CHh+PxCcnztdXuNA6uIf2X N+OOudRbWrgnrpGbhudraRgoQOXIl+Sg1chX97qmPdtgz8Ftgf98yBWMld+QKllW fbTa8mIyiZBdO+0hTRYeiSMdDH0q4PnBbetvPW1lLRHVIlNqbL67yi4q9F+nvRoz jv5ueaz8S4iflG57ZVBVjmBok4QMxoX34J1V3M/qahsWhK1+hFVKXM7cJn9j0hNW H6GS/HdNA35yqwNJyKQdj3i2P1ptom39vLqHLlPCmX9okjiTSXfrtDsJBZdsHNC3 GP9uJWZnhE61rTmlwQ1vpdxZvVUp8whIgsgu9GWX7KaDXa3kYSf58sjE5aEAuKhh 4thc8OElq1BzRPHRIZNbyUoqZ6qHELYt88UNMA74obHun69UOeyvN2MIKn8wvTDh wIttvErryrAqz5+mFjKK =r5/p -----END PGP SIGNATURE-----

1 0

Re: Andrew Eikum : winecfg: Use a listview for speaker configuration.
by Bruno Jesus 15 Apr '15

15 Apr '15

On Wed, Apr 15, 2015 at 10:43 AM, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: e17f4fd2f814a2a651c229ead4f86ab25130fe06 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e17f4fd2f814a2a651c229ead… > > Author: Andrew Eikum <aeikum(a)codeweavers.com> > Date: Tue Apr 14 14:01:46 2015 -0500 > > winecfg: Use a listview for speaker configuration. This is much better, thanks Andrew.

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 8)
by Stefan Dösinger 15 Apr '15

15 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are a few issues with this. They seem vaguely familiar to me, I think I have raised them before but they got lost in the list to array conversion: On 04/15/15 12:07, Alistair Leslie-Hughes wrote: > @@ -405,9 +405,48 @@ static HRESULT WINAPI IDirectPlay8AddressImpl_GetComponentByIndex(IDirectPlay8Ad > const DWORD dwComponentID, WCHAR *pwszName, DWORD *pdwNameLen, void *pvBuffer, > DWORD *pdwBufferSize, DWORD *pdwDataType) > { I assume you're supposed to write the name to pwszName if it is non-NULL, and check *pdwNameLen against the string length first. > + entry = This->components[dwComponentID]; > + > + if(*pdwBufferSize < entry->size) > + { > + *pdwBufferSize = entry->size; > + return DPNERR_BUFFERTOOSMALL; > + } It seems to me that it should assign *pdwDataType and *pdwNameLen in this case. The test should be extended to explicitly check the assigned lengths. Your code never sets *pdwNameLen, and it sets *pdwDataType only if the buffer is big enough. The concern about assigning *pdwDataType in the buffer to small case also applies to GetComponentByName. > + switch (entry->type) > + { > + case DPNA_DATATYPE_DWORD: > + memcpy(pvBuffer, &entry->data.value, sizeof(DWORD)); > + break; > + case DPNA_DATATYPE_GUID: > + memcpy(pvBuffer, &entry->data.guid, sizeof(GUID)); > + break; Assignments should be enough in these cases. The same applies to the existing GetComponentByName code. A semi-related problem in the existing GetComponentByName code: > if(!pwszName || !pdwBufferSize || !pdwDataType || (!pvBuffer && pdwBufferSize)) > return E_POINTER; The second check for pdwBufferSize is redundant, you already established it is not NULL. I assume that's supposed to be *pdwBufferSize. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVLj+3AAoJEN0/YqbEcdMws+UP/0q9wkiDyPPLi5+tbp8NXPKZ NItf38ksjFeForuNvmRt/Q0MAvQeJ0CSpqoyk3nH9G0EvcNQPXEpBHBCiL7aqUVU HN0OWc07OANPPrvAVqNRAVVaaAr1v9NFd+CJFNqNf7d0uOj0D1GMJtvJw+1ia06P qFfAUIIRSf1ay4RocO2HyAsaYwtps15Pib067jBJT/iVriMJQuflB9WRBy6BmKrR DM0PzySi3+quFjl+tYKUitUeR4RgGsMXUSx8V3l03929Y1duRO0uSfzAs18Mquqh wovE36jJfYhpBhJa7oAI9CVkNvr/EBMSVzHtBOGWM6mewMI3CGrfn+ZLxjOe1kk3 pIFXfIlbBBTZJYusL8fOxL0itacE2+YB5Opzi2K6TyNfnqWHscR5g7q+JH6iIe4k /JepaI2mqPsD2RgvM7SKBH2s6qz+cfd7uHWiW+QzzVEqIixbb3eJm1raR9p2UMAb +aJ9XPYpIeRzy8+BxCXLWhd5GQIFOSlUisQwxbwM9a/d9URFgcLS2KDX3ZjPPBcL hTOCS3jDiIfjf5lTpl1wj/rb+9zmK0JkpFyf6/EbxZEThP/fNuwSHtIYaY/4UO97 H9bpWYI5x1N7VnXaAFhCy9uwMeJ05ZYj0AhVl70S4Q1pHsFSX5XWumTOpfxXtJhH WRMpPPalUDabz3fPcAgG =rxp6 -----END PGP SIGNATURE-----

1 0

Re: msvcrt: improve accuracy of exp/pow/cosh and sinh
by Ruslan Kabatsayev 14 Apr '15

14 Apr '15

Hi, Are you sure this will be of any use if one selects SSE instead of x87 instruction set to handle doubles (like -mfpmath=sse)? No one guarantees the functions like sinh will be evaluated on x87 FPU and even that this legacy instruction set will used at all. Regards, Ruslan On Sat, Apr 4, 2015 at 7:40 PM, Zheng Chen <chanchengcc(a)gmail.com> wrote: > The default fpu_cw = 0x27f makes the exp/pow/cosh/sinh functions producing > less accurate results. This patch temporally changes fpu_cw to 0x37f in > these functions for more accurate results. > > Thanks to Qian for his ideas. > > This patch fixes parts of these two bugs: 37149, 37150 > > >

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2015