November 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 4/5] d3d/tests: Table fog does not abs the fog coordinate.
by Marvin Nov. 26, 2014

Nov. 26, 2014

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=10451 Your paranoid android. === w8 (32 bit visual) === visual.c:17111: Test failed: Got unexpected color 0x000000ff, case 3. visual.c:17111: Test failed: Got unexpected color 0x000000ff, case 4.

1 0

Re: [PATCH 4/5] d3d/tests: Table fog does not abs the fog coordinate.
by Marvin Nov. 26, 2014

Nov. 26, 2014

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=10450 Your paranoid android. === w8 (32 bit visual) === visual.c:5508: Test failed: Got unexpected color 0x000000ff, case 3. visual.c:5508: Test failed: Got unexpected color 0x000000ff, case 4.

1 0

Re: [PATCH 3/3] d3d8: Only one fullscreen swapchain is allowed (v2).
by Marvin Nov. 25, 2014

Nov. 25, 2014

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=10437 Your paranoid android. === w8 (32 bit device) === device.c:1217: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1262: Test failed: Reset failed, hr 0x88760868. device.c:1264: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1268: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1275: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1276: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1277: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1278: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1279: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1280: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1285: Test failed: Screen width is 640, expected 800. device.c:1286: Test failed: Screen height is 480, expected 600. device.c:1292: Test failed: Back buffer width is 640, expected 800. device.c:1294: Test failed: Back buffer height is 480, expected 600. device.c:1324: Test failed: Screen width is 640, expected 1024. device.c:1325: Test failed: Screen height is 480, expected 768. device.c:2512: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2517: Test failed: The focus window is active. device.c:2525: Test failed: Got unexpected hr 0x88760869. device.c:2531: Test failed: Got unexpect screen size 800x600. device.c:2546: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2555: Test failed: Got unexpect screen size 800x600. device.c:2568: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2575: Test failed: Got unexpect width 640. device.c:2576: Test failed: Got unexpect height 480.

1 0

Re: user32/tests: Ensure ShowWindow returns false when window is already hidden
by Marvin Nov. 25, 2014

Nov. 25, 2014

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=10433 Your paranoid android. === w7u (32 bit msg) === msg.c:12214: Test failed: unexpected hwnd 00080150 msg.c:12236: Test failed: bad time 30a5c/30a6b

1 0

first patches from a new developer
by Marc Bessières Nov. 24, 2014

Nov. 24, 2014

Hello, I'm new to wine development. I've just sent my first 2 patches: http://source.winehq.org/patches/data/107855 http://source.winehq.org/patches/data/107856 The second patch passed successfully on testbot: https://testbot.winehq.org/JobDetails.pl?Key=10426 I read the wiki beforehand, so hopefully I didn't make too many mistakes. But please don't hesitate to give any comments so I can improve. Marc

1 0

Re: [PATCH 2/2 try2] mshtml: Added IHTMLDocument2::execCommand implementation.
by Marvin Nov. 24, 2014

Nov. 24, 2014

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=10429 Your paranoid android. === w2000pro (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED dom.c:6147: Test failed: execCommand returned 0 === wxppro (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED dom.c:6147: Test failed: execCommand returned 0 === wvistau64 (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === w2008s64 (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === wvistau64 (64 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === w2008s64 (64 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED

1 0

Re: [PATCH 2/2] mshtml: Added IHTMLDocument2::execCommand implementation.
by Marvin Nov. 24, 2014

Nov. 24, 2014

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=10428 Your paranoid android. === w2000pro (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED dom.c:6147: Test failed: execCommand returned 0 === wxppro (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED dom.c:6147: Test failed: execCommand returned 0 === wvistau64 (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === w2008s64 (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === wvistau64 (64 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === w2008s64 (64 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED

1 0

Re: [PATCH 5/5] d3d8: Only one fullscreen swapchain is allowed.
by Henri Verbeet Nov. 24, 2014

Nov. 24, 2014

On 21 November 2014 at 18:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(!desc.windowed) Formatting. (Also present in the d3d9 version.)

1 0

Re: [PATCH 2/5] d3d9/tests: Fix test_cursor().
by Henri Verbeet Nov. 24, 2014

Nov. 24, 2014

On 21 November 2014 at 18:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + window = CreateWindowA("d3d9_test_wc", "d3d9_test", WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 0, 0, 640, 480, NULL, NULL, NULL, NULL); > + > + ret = SetCursorPos(50, 50); > + ok(ret, "Failed to set cursor position.\n"); > + flush_events(); > memset(&info, 0, sizeof(info)); > info.cbSize = sizeof(info); > ok(GetCursorInfo(&info), "GetCursorInfo failed\n"); > cur = info.hCursor; > > - window = CreateWindowA("d3d9_test_wc", "d3d9_test", WS_OVERLAPPEDWINDOW, > - 0, 0, 640, 480, NULL, NULL, NULL, NULL); > ok(!!window, "Failed to create a window.\n"); I think I'd prefer the ok() moved as well, like in the d3d8 version.

1 0

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical line output after resampled
by Sebastian Lackner Nov. 24, 2014

Nov. 24, 2014

Hi, while looking quickly over your patch I noticed a couple of mistakes / things you should probably change: On 21.11.2014 15:32, 刘昌辉 wrote: >+ int src_img_height = src_rect.Height; >+ int dest_img_width = dest_rect.X + dest_rect.Width; >+ int dest_img_height = dest_rect.Height; >+ BYTE* src_img_data = malloc (src_img_width*src_img_height*4); >+ BYTE* dest_img_data = malloc (dest_img_width*dest_img_height*4); You shouldn't use malloc(...) and free(...) in wine source, use HeapAlloc(...) and HeapFree(...) instead. >+ >+ /*first line*/ >+ value = *( (DWORD*)dest_img_data + dest_rect.X) ; >+ /*printf ("pixel(%d,%d) = %08x\n", dest_rect.X, 0, value );*/ I assume the printf was for debugging, remove it, or if it is really very important then use trace(...) instead. Other tests use GdipBitmapGetPixel(...) for reading the color of specific pixels. If its possible to use that here too, it would look a bit better than directly accessing the memory. >+ ok ( value > 0, >+ "dest image color should same as src image color\n"); You are switching between different styles in your patch several times. Try to make the style match a bit more the sourrounding code, especially whitespace before and after functions. In this case a linebreak is also not really necessary for example, other lines are much longer. Regards, Sebastian

4 4

Re: [PATCH 1/5] dxgi/tests: Test fullscreen and multiple swapchains.
by Marvin Nov. 23, 2014

Nov. 23, 2014

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=10394 Your paranoid android. === wvistau64 (32 bit device) === device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. device.c:469: Test failed: Got unexpected hr 0x87a0001. device.c:475: Test failed: Got unexpected hr 0. === w2008s64 (32 bit device) === device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. device.c:469: Test failed: Got unexpected hr 0x87a0001. device.c:475: Test failed: Got unexpected hr 0. === w7u (32 bit device) === device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. device.c:469: Test failed: Got unexpected hr 0x87a0001. device.c:475: Test failed: Got unexpected hr 0. === w8 (32 bit device) === device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. device.c:469: Test failed: Got unexpected hr 0x87a0001. device.c:475: Test failed: Got unexpected hr 0. === wvistau64 (64 bit device) === device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. device.c:469: Test failed: Got unexpected hr 0x87a0001. device.c:475: Test failed: Got unexpected hr 0. === w2008s64 (64 bit device) === device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. device.c:469: Test failed: Got unexpected hr 0x87a0001. device.c:475: Test failed: Got unexpected hr 0.

2 1

Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution
by Mark Harmstone Nov. 23, 2014

Nov. 23, 2014

Oops, sorry, yes I did. How about the attached patch? It only calls XRRSetScreenSize if there's only one active CRTC. I've managed to scrounge another monitor now, and it works for me with both single and multiple monitors. On 20/11/14 13:19, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Did you accidentally drop the wine-devel CC, or was this on purpose? > I'd like to CC wine-devel on my reply but don't want to forward your > mail without your consent. > > Stefan > > On 11/20/14 14:03, Mark Harmstone wrote: >> Hi, >> >> I tested this with KDE 4.14.3 and kwin 4.11.14, and it worked fine >> - if there's a KDE bug, it must have been fixed in the latest >> versions. I only have a single monitor to test with, though. >> >> Setting crtc_info->x and crtc_info->y to 0 in XRRSetCrtcConfig >> does stop it from failing outright, but in my experience these are >> only non-zero when panning is already on. For the first resolution >> change, it won't prevent the drivers from going into panning mode, >> and won't (for instance) stop Icewind Dale from failing on startup >> on low resolutions. >> >> Plus all this patch is doing is what xrandr is doing already - >> does that mean that xrandr also messes up multi-monitor setups, or >> would you need to pass it different arguments? And I'm not sure >> what the official Wine line is on this, but it seems to me sensible >> to prioritize simple common setups over complicated rare ones - I'm >> sure far more people use nvidia-drivers than have two monitors. >> >> Mark >> >> >> On 20/11/14 12:48, Stefan Dösinger wrote: On 11/20/14 13:11, Mark >> Harmstone wrote: >>>>> This changes xrandr12_set_current_mode so it behaves the same >>>>> way as xrandr does in 1.2 mode (e.g, `xrandr --output HDMI-0 >>>>> --crtc 0 --mode 640x480`). Before XRRSetCrtcConfig is called, >>>>> the CRTC is temporarily disabled, then XRRSetScreenSize is >>>>> called. (XRRSetCrtcConfig will fail if the CRTC isn't >>>>> disabled first.) >> I've experimented with this a few weeks ago, and it drastically >> improves the usability of fullscreen applications on >> Metacity-based window managers. Unfortunately I'm afraid it is not >> quite that simple. It breaks KDE (may be a bug) and it breaks >> multi-monitor setups. >> >> Testing on Windows (sorry, I did not write formal tests) shows that >> in single monitor setups the virtual screen size is adjusted to >> match the monitor's resolution when the resolution is changed. So >> the change is correct in single monitor setups, but needs tests. >> >> In multi-monitor setups the virtual screen size is changed too, but >> it still takes both monitors into account. E.g. you had two >> monitors at 1920x1080, where one is to the right of the other. So >> you have a virtual screen of 3840x1080. If you change the res of >> the left monitor to 640x480 you get a virtual screen size of >> 2560x1080. >> >> I hackily "fixed" the Nvidia panning bug by replacing crtc_info->x >> and crtc_info->y in pXRRSetCrtcConfig with 0, 0. That way the mode >> set succeeds and the CRTC is positioned correctly. The direct3d >> mouse grab takes care of the mouse moving outside the window, but >> only after clicking in the window once. The d3d grab is incorrect >> though as far as I can see. Windows doesn't grab the mouse in >> fullscreen d3d games in dual monitor setups. >> >> Passing an offset of 0, 0 to pXRRSetCrtcConfig may be the correct >> thing to do. It seems that the content of crtc_info->x and >> crtc_info->y depends on the mouse pointer location, which would be >> an odd thing for a mode change to depend on. May be an Nvidia bug. >> >> Finally, there is a bug in all window managers forked from >> Metacity. If the new resolution is smaller in width or height than >> half the virtual screen size (= old resolution for single-monitor >> setups) then the WM places the window incorrectly. xwininfo reports >> where the window *should* be - at 0x0-WxH. But the real display >> location is something different, depending on the exact incarnation >> of the WM. In Unity it is shifted by 64x64 (unity bar I guess) and >> stretched to the virtual screen size. In MATE I think the window is >> centered. I suspect this is caused by the window positioning logic >> breaking. I have not been able to isolate the bug in the window >> manager code yet. >> >> All in all I'm afraid we have a number of different bugs to fix in >> all Metacity forks, Wine, the Nvidia driver and maybe KDE. >> >> Fwiw, KDE and FVWM place fullscreen windows properly. MATE and >> Unity also adjust their title bars and window maximization to match >> the new CRTC size, not the screen size. >> >>> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJUbepaAAoJEN0/YqbEcdMwl0YP/2/QPABqbt3awjNBqQjAV7eA > 0nH8AqvoaSCJ6Ecy3allYa8MC21RmyhK5mCa7e4yWnqTkOaOFCqgjnwPf7C1p7MO > g/aGKsEFpHEM1YL1uvraKDVMeZGVXnSnE08eTrovNBvNvAhZn4Q/y6DZlOVjsJ44 > djJA98/cYoditLcOVSmnqPv9hY85jQYTT2jduvZ7oMbRMhdjU5KZkyEMiCN83F/t > iaY3IQfDzuoGBgH9/f+cSlNlNE8AJvXocJwOVfoW7FD/VU81N9jl5yMzujqEznos > UquZ0CzBlyEWH7i0nxtjL/rfbc4giyF8aKByhSl9PS3k+DaKNsPtt6FWl4a/5+/i > LJU4DQwdWFyQMtyR84kLvskPtNFB7ZNtzmPFvMtVBSziu0NvTGCEPTKKdPX+GgdP > MiX3hSZFhkHzmoEEzfEGI0+j2Azj1RLi7xdVW/z/XIwhsPEd3dAytMaYWe8T05qI > +ysOMuUGRz0tNVPSFiiO7FYcvsj4/o5la/fa0DbIh77GJvZqm8xHCHI6+Lf+Gx5N > EurAoLaH+m8FTA5YRUoTKbxtVY/j+/B7LiTW5x53QcQH/Cb/B9Q2dcH5g/UGugDo > eNm2ZFVqHkIRBa695sm4uTWZHj6RQUblBmLi2tIIdfIihiinZVDBci1CFua+Obsu > p7VTdlbDMVuomwzPL7FA > =DLsp > -----END PGP SIGNATURE----- >

2 2

Re: fusion: Remove unused IAssemblyCacheItem (Clang)
by Nikolay Sivov Nov. 22, 2014

Nov. 22, 2014

On 21.11.2014 22:58, André Hentschel wrote: > --- > dlls/fusion/asmcache.c | 94 -------------------------------------------------- > 1 file changed, 94 deletions(-) > I guess the idea was to create some instance with CreateAssemblyCacheItem(), it's trivial and I think we should do that instead of removing item code (even if it's a stub).

1 0

Re: dwrite/tests: Remove unused functions (Clang)
by Nikolay Sivov Nov. 22, 2014

Nov. 22, 2014

On 21.11.2014 22:58, André Hentschel wrote: > --- > dlls/dwrite/tests/analyzer.c | 7 ------- > dlls/dwrite/tests/layout.c | 7 ------- > 2 files changed, 14 deletions(-) I'll send a patch to use those helpers, don't remove them for now.

1 0

Re: dwrite: Remove unused code (Clang)
by Nikolay Sivov Nov. 22, 2014

Nov. 22, 2014

On 21.11.2014 22:58, André Hentschel wrote: > --- > dlls/dwrite/bidi.c | 6 ------ > dlls/dwrite/shape.c | 2 -- > 2 files changed, 8 deletions(-) > I don't mind, let's remove that. Looks like iso_previousChar() could be removed from usp10 too then.

1 0

Re: wined3d: Add NVIDIA Geforce GT 750M to supported device list.
by Jonas Maebe Nov. 21, 2014

Nov. 21, 2014

FWIW, I have such an NVIDIA Geforce GT 750M card (under OS X 10.9.5) and Crossover 13.2 returned 768MB of vram for it. Crossover 14/14.0.1 returns 128MB instead, which resulted in a number of games suddenly crashing because they ran out of VRAM. This issue was quickly diagnosed by the helpful Codeweavers support person, and resolved by adding the registry entry to override the video memory size. Looking at the current source code, I assume that's because shader_arb_get_caps() can set the shader_caps->vs_version maximally to 3, while d3d_level_from_caps() will only return WINED3D_D3D_LEVEL_10 for shader_caps->vs_version==4. As a result, d3d_level_from_caps now returns WINED3D_D3D_LEVEL_9_SM3, which is translated for an unknown NVidia card into CARD_NVIDIA_GEFORCE_6800. That one is indeed defined as having 128MB of VRAM.

5 13

Re: [PATCH 5/5] d3d8: Only one fullscreen swapchain is allowed.
by Marvin Nov. 21, 2014

Nov. 21, 2014

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=10398 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2517: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2522: Test failed: The focus window is active. device.c:2530: Test failed: Got unexpected hr 0x88760869. device.c:2536: Test failed: Got unexpect screen size 800x600. device.c:2551: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2560: Test failed: Got unexpect screen size 800x600. device.c:2573: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2580: Test failed: Got unexpect width 640. device.c:2581: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 4/5] d3d8/tests: Fix test_cursor().
by Marvin Nov. 21, 2014

Nov. 21, 2014

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=10397 Your paranoid android. === w8 (32 bit device) === device.c:1186: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1231: Test failed: Reset failed, hr 0x88760868. device.c:1233: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1237: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1244: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1245: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1246: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1247: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1248: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1249: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1254: Test failed: Screen width is 640, expected 800. device.c:1255: Test failed: Screen height is 480, expected 600. device.c:1261: Test failed: Back buffer width is 640, expected 800. device.c:1263: Test failed: Back buffer height is 480, expected 600. device.c:1293: Test failed: Screen width is 640, expected 1024. device.c:1294: Test failed: Screen height is 480, expected 768. device.c:2481: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2486: Test failed: The focus window is active. device.c:2494: Test failed: Got unexpected hr 0x88760869. device.c:2500: Test failed: Got unexpect screen size 800x600. device.c:2515: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2524: Test failed: Got unexpect screen size 800x600. device.c:2537: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2544: Test failed: Got unexpect width 640. device.c:2545: Test failed: Got unexpect height 480.

1 0

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical line output after resampled
by Vincent Povirk Nov. 21, 2014

Nov. 21, 2014

This will break in cases where the destination area (defined by points) is not a rectangle. On Fri, Nov 21, 2014 at 8:32 AM, 刘昌辉 <liuchanghui(a)linuxdeepin.com> wrote: > > > >

1 0

Re: [PATCH 4/5] wined3d: Don't minimize hidden Windows.
by Henri Verbeet Nov. 21, 2014

Nov. 21, 2014

On 19 November 2014 20:13, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2189,6 +2189,13 @@ static LRESULT CALLBACK test_proc(HWND hwnd, UINT message, WPARAM wparam, LPARAM > } > } > > + if (unexpected_messages) > + { > + const struct message *i; > + for (i = unexpected_messages; i->message; i++) > + ok(i->message != message, "Got unexpected message %x on window %p.\n", message, hwnd); Note that putting the ok() in test_proc() makes it hard to find the actual test that failed.

2 1

Re: shell32/tests: Fix a copy and paste error (PVS-Studio)
by Marvin Nov. 20, 2014

Nov. 20, 2014

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=10373 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

2 1

Re: [2/2] ws2_32: Implement returning the proper time with SO_CONNECT_TIME.
by Bruno Jesus Nov. 20, 2014

Nov. 20, 2014

On Thu, Nov 20, 2014 at 10:27 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Based on a patch by Erich Hoover. > > To avoid calculations on the client-side, the server sends the connect time as relative (negative) value. > Needs tools/make_requests. Hi, Sebastian. Thanks for taking care of this, but actually I'm thinking by doing this in a different way. I'm thinking about moving SO_CONNECT_TIME, SO_SNDBUF and SO_RECVBUF to the server with some new server message or the one Erich created for the WSAIoctl. By doing it this way we can fix not only this bug but also https://bugs.winehq.org/show_bug.cgi?id=8606 where we can store the pretended SO_SNDBUF value and return to the client when asked. Some other messages could also be done there like SO_EXCLUSIVEADDR, SO_DEBUG and others that require only memory to store/retrieve the value. This would also help for SO_ACCEPTCONN which is bugged in OSX due to a kernel problem. Not sure if my approach would be accepted anyway. Best wishes, Bruno

2 6

Re: [PATCH 1/2] Add tests for calling ShowWindow(SW_HIDE) on a hidden window.
by Marvin Nov. 20, 2014

Nov. 20, 2014

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=10364 Your paranoid android. === w7u (32 bit msg) === msg.c:12217: Test failed: unexpected hwnd 0014013C msg.c:12239: Test failed: bad time 309c0/309cf

2 1

Re: [PATCH] explorer: Fix copy_path_string() when an unnecessary \ follow the path.
by Huw Davies Nov. 20, 2014

Nov. 20, 2014

On Thu, Nov 20, 2014 at 08:29:17PM +0800, Jactry Zeng wrote: > @@ -639,6 +640,11 @@ static int copy_path_string(LPWSTR target, LPWSTR source) > while (*source && *source != ',') target[i++] = *source++; > target[i] = 0; > } > + > + last = strlenW(target) - 1; > + if (target[0] && target[last] == '\\') > + target[last] = 0; > + > return i; > } You probably want PathRemoveBackslashW() Huw.

2 1

Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution
by Stefan Dösinger Nov. 20, 2014

Nov. 20, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/20/14 13:11, Mark Harmstone wrote: > This changes xrandr12_set_current_mode so it behaves the same way > as xrandr does in 1.2 mode (e.g, `xrandr --output HDMI-0 --crtc 0 > --mode 640x480`). Before XRRSetCrtcConfig is called, the CRTC is > temporarily disabled, then XRRSetScreenSize is called. > (XRRSetCrtcConfig will fail if the CRTC isn't disabled first.) I've experimented with this a few weeks ago, and it drastically improves the usability of fullscreen applications on Metacity-based window managers. Unfortunately I'm afraid it is not quite that simple. It breaks KDE (may be a bug) and it breaks multi-monitor setups. Testing on Windows (sorry, I did not write formal tests) shows that in single monitor setups the virtual screen size is adjusted to match the monitor's resolution when the resolution is changed. So the change is correct in single monitor setups, but needs tests. In multi-monitor setups the virtual screen size is changed too, but it still takes both monitors into account. E.g. you had two monitors at 1920x1080, where one is to the right of the other. So you have a virtual screen of 3840x1080. If you change the res of the left monitor to 640x480 you get a virtual screen size of 2560x1080. I hackily "fixed" the Nvidia panning bug by replacing crtc_info->x and crtc_info->y in pXRRSetCrtcConfig with 0, 0. That way the mode set succeeds and the CRTC is positioned correctly. The direct3d mouse grab takes care of the mouse moving outside the window, but only after clicking in the window once. The d3d grab is incorrect though as far as I can see. Windows doesn't grab the mouse in fullscreen d3d games in dual monitor setups. Passing an offset of 0, 0 to pXRRSetCrtcConfig may be the correct thing to do. It seems that the content of crtc_info->x and crtc_info->y depends on the mouse pointer location, which would be an odd thing for a mode change to depend on. May be an Nvidia bug. Finally, there is a bug in all window managers forked from Metacity. If the new resolution is smaller in width or height than half the virtual screen size (= old resolution for single-monitor setups) then the WM places the window incorrectly. xwininfo reports where the window *should* be - at 0x0-WxH. But the real display location is something different, depending on the exact incarnation of the WM. In Unity it is shifted by 64x64 (unity bar I guess) and stretched to the virtual screen size. In MATE I think the window is centered. I suspect this is caused by the window positioning logic breaking. I have not been able to isolate the bug in the window manager code yet. All in all I'm afraid we have a number of different bugs to fix in all Metacity forks, Wine, the Nvidia driver and maybe KDE. Fwiw, KDE and FVWM place fullscreen windows properly. MATE and Unity also adjust their title bars and window maximization to match the new CRTC size, not the screen size. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUbeMbAAoJEN0/YqbEcdMwutAP/jWwKCaDNL0OzaWoQhVM8+XN fmshL9cSYha3jVnJ8TJU92ch/7NcFsnGFL0dAEFz1bZqpM9lHwqapdjhqP7PUI0r yIpRNoBR+UjeX46zQ1oIbcib2UpXhm0YZQ0x45DaaUGvVDFGSs0d2Oo4nulDJFx+ DkEdSxe9p403rc6S2nfWHROaUmT3v/stYs9nN+A+YuBleYZwJz+e+MknElTBiboo RcIWnOICDksJ08oEhWaMxNDLtQstMYp0cuRtPNeB3jCWxRP00xsgXgZ2uAigSrrI OPcLgQ5jq3MFDdHorgz7pM3aOa5YvouFxt1OsCsbyekSovBJMj4WaB0QHmqOxPUQ 2LQzS9TMsR0CJYl6hdsykB6c8Gdqdcc8Gv+SoLUn7FjUckvXi6cgnN+XnXTFBQT2 ah6S59gVYxwvb4IVdvYuAL/AvN3tlfR6rOkw/U3Z16u0KHa2C0SQRSK8ohuFabzS SMq2VEq4Cspub3nYCSOSSFZvmUKxlHdyQPPfXEpFEfBQaM40CnsfqN/7vfchj0dQ jAExC4Z1PGvFJFqVnTFaxZ3eIOPBDIBOTgkDK14gWaxrZoGySTJtDe6513iLBsQv 75JZxcfl5VZbzIfYuUcVjvXoWyr4gqeOSJhe/oEITpd5UwEAZabcvJ/yIH8s3u0T tliUU3UuYOfzLsP7jLP2 =eGIQ -----END PGP SIGNATURE-----

1 0