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

d3drm patch feedback
by Stefan Dösinger 18 Jun '15

18 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here's the feedback for the patch you posted on IRC: > + GUID driver = IID_IDirect3DRGBDevice; Do you need this? Can't you just pass &IID_IDirect3DRGBDevice to CreateDeviceFromClipper? It may generate a const warning though. > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface (hr = %x).\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper (hr = %x).\n", hr); Can you pass a NULL clipper? If this crashes, just put a comment in the test. What if the clipper has no HWND and no clip list? Call GetClipper on the render target and see if the clipper is assigned. > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, 300, 200, &device2); For the sake of completeness pass 0 width and height. I expect one of the two results: Either it returns an error, or d3drm starts to use the window dimensions for the render target now. > + todo_wine ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d , ref2 = %d\n", ref1, ref2); Minor detail: Use %u for unsigned. > + ok((surface_desc.dwWidth == 300) && (surface_desc.dwHeight == 200), "Expected surface dimentions = 300, 200, got %d, %d.\n", > + surface_desc.dwWidth, surface_desc.dwHeight); > + ok((surface_desc.ddsCaps.dwCaps & (DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE)) == (DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE), > + "Expected caps containing %x, got %x.\n", DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE, surface_desc.ddsCaps.dwCaps); > + expected_flags = DDSD_PIXELFORMAT | DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PITCH; > + ok(surface_desc.dwFlags == expected_flags, "Expected %x for flags, got %x.\n", expected_flags, surface_desc.dwFlags); Test the pixel format here. First query the current bpp with EnumDisplaySettings and check that the pixel format matches the screen properties. > + /* Check if ddraw supports change of display mode */ The comment is somewhat outdated. Either remove it or say something like "Test if the render target format follows the screen format". > + ok(surface_desc.ddpfPixelFormat.dwRGBBitCount == 16, "Expected 16bpp, got %dbpp.\n", > + surface_desc.ddpfPixelFormat.dwRGBBitCount); Similar to the %u -> %u above Once these are fixed the patch can go to wine-patches as far as I'm concerned. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVgt8QAAoJEN0/YqbEcdMwOTYP/jXwDY+gUs/zmAyqB5hJp8by FO0YSZsi0Z3QMMzfqenCy9+/PmqjMHyRPQvhM8CFpcdWsUi8bH6PzTiooAYOcvzf GXEnj46T1O0wiJfLK+RnzfvYNzITLWf2XK6ek1OtP1z6Y3JhADXwoLW/tSM+kKp7 Crih31t9ewiSMG5iebcSdviI59WrFtUHmS9Mdp5UnWVQB8smZII8c+VAOf/SmWZ1 cGKosFncJVNuXpF0fq5gWiy3m1VcJ1xoWsG1rXbrOzVFvpw+20twa1FgZm9Z6I3c Pxj2prH2Lz9u7tDZUr75dg3ucRPcUe2QP2bTwwBDDq4oaUZYKgXBLrz94AVZ/Y+j datcVFY7KwY2byGmxmO+0I+iWyj26CIg13jo20gqfRfjt92DFlfi5/Mm/e97rCa1 0V38s0kqN5o4rvU+QbUwHfvHIgr4kAFWZPjDmZd3YececQuoeC7FszND/43UD0tK MTd1Na3hFa5m6zO7oe4fPfGYX55tVhEzphiRkH4K0R0ZTxRsZGGqQoSFAHeAJDH6 0hPd3XjVHxSpHQNd8/8aFeOMJ8pBR+4MRUMcFBDn0XlDUYw0kUdvRkttKoNVCSGw H0BS00wj/fs/G4D/pCLEFEX7wF9qDM5O6xKQRoyXG3+i9oN+zdzCNMs6SV1J2Bci Jedz7Aw7+yAByiH/GePR =aa6D -----END PGP SIGNATURE-----

2 1

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Theodore Dubois 17 Jun '15

17 Jun '15

> While it seems Theodore didn't do his homework and didn't know about that source distribution, one of his point remains: > it's not a database, git, or something easily readable, just a blob Yes, I really hate that it’s a huge blob. I’m working on a little project to try and diff Crossover’s wine and wine 1.7.25, and identify all the hacks. The github repo is tbodt/crossover-wine, but I haven’t actually done any real work on it yet. Currently, it’s nothing but a fork of wine-mirror/wine. We’ll see when I get around to it. ~Theodore

1 0

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Theodore Dubois 17 Jun '15

17 Jun '15

I originally sent this email to Jeremy, but forgot to CC the mailing list. ~Theodore On Jun 16, 2015, at 1:48 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >> I'm obviously very sad that you perceive us as evil. Do you mind me >> asking where you got that feeling from? If there is an information >> source that is revealing all of our evil secrets, I'd like to know about >> it. <grin> > > I thought you were evil because I didn't realize that all your hacks are actually already public. (And those <evil grin>s.) I'm sorry. > >> All of our Wine code, including our hacks, is publicly released, here: >> https://www.codeweavers.com/products/faq/source/ > > I had seen that source page, but I didn't realize it contained all the hacks. I thought it was just the main Wine source code. > >> Um, nearly all of the work that we do on CrossOver is done by sending >> public emails to this mailing list. How is that not open? Or perhaps I >> should ask - what gave you the impression that we did not develop openly? > > I thought that because you were evil, you must have some non-public mailing list. I guess I was wrong. > > Well, now I don't feel CodeWeavers is evil anymore. You are doing some awesome work on Wine. Without it, Wine would not have gotten to the point where it could run Crysis. > > ~Theodore

1 0

Re: [1/2] winhttp/tests: Fix a test failure on win2k.
by Marvin 17 Jun '15

17 Jun '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=14399 Your paranoid android. === w8 (32 bit winhttp) === winhttp.c:864: Test failed: failed to send request 2148074273 winhttp.c:868: Test failed: failed to retrieve certificate context 12019 winhttp.c:873: Test failed: failed to retrieve key bitness 4317 winhttp.c:877: Test failed: failed to retrieve certificate info 12019 winhttp.c:890: Test failed: failed to receive response 12019 winhttp.c:895: Test failed: failed unexpectedly 12019 winhttp.c:896: Test failed: request failed unexpectedly 3735928559 winhttp.c:907: Test failed: WinHttpReadData failed: 12019. winhttp.c:911: Test failed: read_size = 0

1 0

IDirect3DRM*::CreateDeviceFrom* tests
by Aaryaman Vasishta 17 Jun '15

17 Jun '15

Testing if pixel format of the render target changes when the mode is changed: https://testbot.winehq.org/JobDetails.pl?Key=14395 <https://testbot.winehq.org/JobDetails.pl?Key=14356> All the three tests together: https://testbot.winehq.org/JobDetails.pl?Key=14403 Please review the code and let me know of any modifications that are required. Thank you! Jam

1 1

Re: [2/2] Add stub dll d3dcompiler_47 (try 2)
by Matteo Bruni 17 Jun '15

17 Jun '15

2015-06-17 8:01 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > Removed LPVOID > > Changelog: > Add stub dll d3dcompiler_47 > > > Best Regards > Alistair Leslie-Hughes Both patches look good to me. Thanks Alistair!

1 0

Re: [PATCH 2/8] wined3d: Avoid potential division by 0 when computing fog scale.
by Henri Verbeet 17 Jun '15

17 Jun '15

On 16 June 2015 at 22:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > get_fog_start_end(context, state, &start, &end); > - scale = 1.0f / (end - start); > + scale = end == start ? INFINITY : 1.0f / (end - start); Do we really need this? It almost feels nicer to just pass "end - start" to the shader and handle the division there, or perhaps even just pass "start".

3 3

[PATCH 1/2] secur32: Added support for a few more algorithms in schannel_get_cipher_algid.
by Hugh McMaster 17 Jun '15

17 Jun '15

On Tue, 16 Jun 2015 13:46:32 +0200, Jacek Caban wrote: >- case GNUTLS_CIPHER_AES_256_CBC: return CALG_AES; >+ case GNUTLS_CIPHER_AES_128_GCM: return CALG_AES_128; >+ case GNUTLS_CIPHER_AES_192_CBC: return CALG_AES_192; >+ case GNUTLS_CIPHER_AES_256_GCM: >+ case GNUTLS_CIPHER_AES_256_CBC: return CALG_AES_256; Those changes are causing fatal build errors in Wine: schannel_gnutls.c: In function ‘schannel_get_cipher_algid’: schannel_gnutls.c:272:10: error: ‘GNUTLS_CIPHER_AES_128_GCM’ undeclared (first use in this function) case GNUTLS_CIPHER_AES_128_GCM: return CALG_AES_128; ^ schannel_gnutls.c:272:10: note: each undeclared identifier is reported only once for each function it appears in schannel_gnutls.c:274:10: error: ‘GNUTLS_CIPHER_AES_256_GCM’ undeclared (first use in this function) case GNUTLS_CIPHER_AES_256_GCM: ^ make[1]: *** [schannel_gnutls.o] Error 1 make[1]: Leaving directory `/home/hugh/wine-test/dlls/secur32' make: *** [dlls/secur32] Error 2 -- Hugh McMaster

3 5

Re: [PATCH 3/8] wined3d: Cleanup and simplify texture sampling code generation.
by Henri Verbeet 17 Jun '15

17 Jun '15

On 16 June 2015 at 22:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > switch (resource_type) > { > case WINED3D_SHADER_RESOURCE_TEXTURE_1D: ... > + type_part = "1D"; > break; There's nothing necessarily wrong with this, but it also seems that aside from the "texrect" handling you could just use the same lookup table you're using for the coordinate mask size.

1 0

Re: [PATCH] riched20: Fix link notification conditions and add tests.
by Alexandre Julliard 17 Jun '15

17 Jun '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -4121,6 +4121,10 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > return 0; > case WM_SETCURSOR: > { > + POINT cursor_pos; > + if (wParam == (WPARAM)editor->hWnd && GetCursorPos(&cursor_pos) && > + ScreenToClient(editor->hWnd, &cursor_pos)) > + ME_LinkNotify(editor, msg, 0, MAKELPARAM(cursor_pos.x, cursor_pos.y)); Getting the current cursor position doesn't look right, it should be the message position. -- Alexandre Julliard julliard(a)winehq.org

2 3