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

New WineHQ Server
by Jeremy White 11 Jul '14

11 Jul '14

Hi Folks, As you probably saw, we have deployed a new server to replace our 5 year old work horse. This new server will hopefully hold us for the next 5 years. It's got good specs; 6 core Xeon, 32G of RAM (easily expandable to 128), raid 10 (also easily expandable). In a particularly nice development, this server was purchased by the Software Freedom Conservancy using funds provided by a donor. This donor doesn't want a particularly big fuss made out of it, and so prefers that I not announce a name publicly. I'd like to thread this needle somewhat carefully, as *I* think it's a remarkably generous gift. So I propose that, at our next convenient opportunity, we all lift a glass in appreciation of anonymous donors everywhere! Cheers, Jeremy

4 3

Re: [PATCH 6/6] wined3d: Do not warn about WINED3DUSAGE_WRITEONLY.
by Henri Verbeet 07 Jul '14

07 Jul '14

On 3 June 2014 09:41, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > As the previous tests show, we can't do anything with this flag. Sort of. It may make sense to set WINED3D_BUFFER_DOUBLEBUFFER if WINED3DUSAGE_WRITEONLY isn't set.

2 7

Wine freetext search no longer working
by Hugh McMaster 03 Jul '14

03 Jul '14

As of 29 June 2014, the freetext source code search option at http://source.winehq.org/search is not working. The error message is "Unexpected return value 2 from Glimpse". A quick search on the internet reveals the following from http://lxr.sourceforge.net/en/troubleshooting.shtml: Unexpected return value x from Glimpse Glimpse was unable to complete the free-text search query. If x is 2, files are inaccessible. These usually are the auxiliary caches, which may be missing or have incorrect access rights. The relevant directory is defined by the 'glimpsedir' or 'glimpsedirbase' configuration parameters. There is no problem with the identifier search option. -- Hugh McMaster

2 3

Re: [PATCH 3/3] winecoreaudio.drv: Use AUHAL API instead of AudioQueue
by Ken Thomases 01 Jul '14

01 Jul '14

Hi, I'm concerned about the use of the AudioConverter API within the capture callback (ca_capture_cb). I have it embedded in my memory that it's not permitted to call a converter on the device thread. I can't find a hard and fast declaration of that in the documentation, although Technical Note TN2091: Device input using the HAL Output Audio Unit does say this: <https://developer.apple.com/library/mac/technotes/tn2091/_index.html> "If sample rate conversion is needed, it can be accomplished by buffering the input and converting the data on a separate thread with another AudioConverter." If what you're doing were allowed, it would seem they would have mentioned that and not suggested the use of "a separate thread". It also seems that the HAL Output Audio Unit would just do this itself and not have the restriction on the sample rate in the first place. I could have sworn that the API would actually generate errors if you tried to use it on the AUHAL's thread, but I may be thinking of the AUConverter audio unit, instead. Ah, after more searching, I believe it was for the AUConverter audio unit. There's an error, kAudioUnitErr_CannotDoInCurrentContext, that is generated if you try to use such a unit or if you try to make the AudioOutputUnit do the conversion itself. Besides my specific recollection that sample rate conversion is not allowed, there's the general requirement to avoid slow operations in those callbacks. The call to AudioConverterFillComplexBuffer() may be such a slow operation. So could the calls to malloc() in your ca_capture_cb() and feed_cb(). Could you not move the sample rate conversion to the application thread, at the point where the application calls in to get the captured data (or metadata about it)? In AudioClient_IsFormatSupported(), is it really the case that any format for which a stream description can be constructed is supported? Is there a need to try setting the format on an AudioConverter to see if it will accept it? There are still two mentions of AudioQueue in lines like: WARN("AudioQueue doesn't support per-channel volume control\n"); -Ken

2 1

Re: d3dx9: Implement D3DXCreateTorus() + tests
by Matteo Bruni 30 Jun '14

30 Jun '14

Hi Gediminas, 2014-06-30 19:29 GMT+02:00 Gediminas Jakutis <gediminas(a)varciai.lt>: > --- > dlls/d3dx9_36/d3dx9_36.spec | 2 +- > dlls/d3dx9_36/mesh.c | 129 +++++++++++++++++++++++++++++++ > dlls/d3dx9_36/tests/mesh.c | 183 ++++++++++++++++++++++++++++++++++++++++++++ > include/d3dx9shape.h | 2 + > 4 files changed, 315 insertions(+), 1 deletion(-) > +HRESULT WINAPI D3DXCreateTorus(struct IDirect3DDevice9 *device, + float innerradius, float outerradius, UINT sides, UINT rings, struct ID3DXMesh **mesh, ID3DXBuffer **adjacency) The "usual" style is 8 spaces for line continuations (that also applies to some other places in the patch). + float sin; + float cos; Not really an issue but I'd prefer if these wouldn't shadow the functions from math.h. + if (!device || innerradius < 0.0f || outerradius < 0.0f || sides < 3 || rings < 3 || !mesh) + { + return D3DERR_INVALIDCALL; + } Not strictly required but you can either avoid the curly braces (here and below) or add a WARN for the error return condition. Probably a WARN here is nicer. + rotation_step = D3DX_PI / sides * -2.0f; + rotation_curr = 0; Please use 0.0f there instead. + for (i = 0; i < sides; ++i) + { + sin = sinf(rotation_curr); + cos = cosf(rotation_curr); + vertices[i].position.x = innerradius * cos + outerradius; + vertices[i].position.y = 0.0f; + vertices[i].position.z = innerradius * -sin; + vertices[i].normal.x = cos; + vertices[i].normal.y = 0.0f; + vertices[i].normal.z = -sin; + + rotation_curr += rotation_step; + } I might be mistaken but I think you can remove the "-" from the previous "-2.0f" and from both "-sin" here. + for (i = 0; i < numfaces - sides * 2; ++i) + { + faces[i][0] = i % 2 ? i / 2 + sides : i / 2; + faces[i][1] = (i / 2 + 1) % sides ? i / 2 + 1 : i / 2 + 1 - sides; + if ((i + 1 >= sides * 4) && !((i + 1) % sides) && !((i + 1) / sides % 2)) + { + faces[i][2] = (i + 1) / 2; + } + else if (i) + { + faces[i][2] = (i + 1) % (sides * 2) ? (i + 1) / 2 + sides : (i / sides) * sides; + } + else + { + faces[i][2] = sides; + } + } Can't the last "else" just be dropped (and the condition from the previous "else" removed)? I.e. the first "else" for the i == 0 case is equivalent to the second one, AFAICS. Actually the first two branches also look to be the same so this should be enough for the third vertex of each face: faces[i][2] = (i + 1) % (sides * 2) ? (i + 1) / 2 + sides : (i + 1) / 2; + for (j = 0; i < numfaces; ++i, ++j) + { + faces[i][0] = i % 2 ? j / 2 : sides * (rings - 1) + j / 2; This should be equivalent: faces[i][0] = i % 2 ? j / 2 : i / 2; I don't mind all that much for this one though. + faces[i][1] = (i / 2 + 1) % sides ? i / 2 + 1 : i / 2 + 1 - sides; + faces[i][2] = i == numfaces - 1 ? 0 : (j + 1) / 2; + } I guess this separate loop for the last "strip" of the mesh is there to avoid a bunch of "% numvert" in the previous loop. That's okay for me. + hr = D3DXCreateTorus(NULL, 0.0f, 0.0f, 3, 3, &torus, NULL); + ok(hr == D3DERR_INVALIDCALL, "Got result %x, expected %x (D3DERR_INVALIDCALL)\n",hr,D3DERR_INVALIDCALL); Missing spaces after the commas. The notes regarding vertices and faces generation also apply to compute_torus in the test obviously. For some reason your patch has DOS-style CRLF line terminators and that made "git apply" fail for me. Testbot didn't complain though so probably that's not an issue. Generally it's preferred to generate patches with "git format-patch" or even better directly "git send-email".

1 0

Re: [PATCH] riched20: Don't create too many IRichEditOle interfaces for a RichEdit. (try 3)
by Huw Davies 30 Jun '14

30 Jun '14

On Thu, Jun 26, 2014 at 02:52:16PM +0800, Jactry Zeng wrote: > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 2af2582..55821bf 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -4468,7 +4468,20 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > case EM_GETOLEINTERFACE: > { > LPVOID *ppvObj = (LPVOID*) lParam; > - return CreateIRichEditOle(editor, ppvObj); > + if (editor->reOle) > + { > + *ppvObj = editor->reOle; > + IRichEditOle_AddRef(*ppvObj); > + return 1; > + } > + > + if (CreateIRichEditOle(editor, ppvObj)) > + { > + editor->reOle = *ppvObj; > + IRichEditOle_AddRef(*ppvObj); > + return 1; > + } > + return 0; I'm sure you can think about how to simplify this a bit. The clue that it needs simplification is that you've got two AddRef()s in there. Hint: The code is trying to do two things: 1. If needed, assign an interface to reOle 2. AddRef and return. > --- a/dlls/riched20/richole.c > +++ b/dlls/riched20/richole.c > @@ -126,12 +126,13 @@ IRichEditOle_fnRelease(IRichEditOle *me) > > TRACE ("%p ref=%u\n", This, ref); > > - if (!ref) > + if (ref == 1) > { > TRACE ("Destroying %p\n", This); > This->txtSel->reOle = NULL; > ITextSelection_Release(&This->txtSel->ITextSelection_iface); > IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); > + This->editor->reOle = NULL; No, this is wrong. This function should remain unchanged. The editor is in charge of the reOle reference, so it needs to release it when the editor is destroyed - ie in ME_DestroyEditor(). Huw.

2 2

RFC: patch 105133
by Jérôme Gardou 30 Jun '14

30 Jun '14

Hello wine team. According to the patch status page, the following patch is still marked as "new". http://source.winehq.org/patches/data/105133 Is there any prioritisation for the testbot regarding the jobs it processes ? Also, that put aside, I'd like to discuss the approach and the problem there as I understand it: with "modern" stubs, allocations and frees are made per argument. If there is no prioritisation on how this is done, the "freeer" of one argument can rely on data which were freed before in the loop and overwritten, thus causing the mayhem in the heap that can be witnessed here (see https://bugs.winehq.org/show_bug.cgi?id=36743) The patch tries to overcome the problem and frees the arguments marked as "MustFree" before anything else. I believe this is the right approach, but a comment from someone more proficient as me in RPC matters would be greatly appreciated. Regards Jérôme

2 3

Re: [PATCH 3/5] d3d8: Check the device status in present calls.
by Marvin 30 Jun '14

30 Jun '14

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=7768 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000301BA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

1 0

Re: [PATCH 2/5] d3d8: Improve d3d8_device_TestCooperativeLevel().
by Marvin 30 Jun '14

30 Jun '14

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=7767 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000301BA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

1 0

Re: [2/2] ddraw: add dsurface dimension tests, try 10
by Stefan Dösinger 30 Jun '14

30 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You forgot to fix some IDirectDrawSurface2 macros. Otherwise this looks good. Thanks again for your work! Stefan Am 2014-06-29 16:37, schrieb Patrick Rudolph: > + hr = IDirectDraw2_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(hr == tests[i].hr, "Pixelformat %s, test %d returned %08x\n", formats[j].name, i, hr); > + > + if (surface) > + { > + IDirectDrawSurface2_Release(surface); > + surface = NULL; > + } > ... > + hr = IDirectDraw2_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(SUCCEEDED(hr), "CreateSurface returned %08x\n", hr); > + if (surface) > + { > + hr = IDirectDrawSurface2_GetSurfaceDesc(surface, &surfacedesc); > + ok(SUCCEEDED(hr), "GetSurfaceDesc returned %x\n", hr); -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTsTBWAAoJEN0/YqbEcdMwThEP/3uJuJuU4gZNiiRy3AkP6guK cVnLXyasOBmwMNxLSFnt1RXQmYmcmY/cR16I/RRd1NbemC8+tB8PbO3Vp6bTGnx0 i4ZM+EFh+6F6xFzjua99sK67x0MNXqW+fp1L8tz5804piaqcJK/MX9XloMeG45ZL WrGVFqZnFKb67OjoXKqZSo0S4bR/GJveRz9x8KxpGnqsc2Wa/sRftIoiO67FSoaq P1ffH0OEPbkj7pzXFyV2BwHFVIC4LzFXmTWVNgmZfNSnTPossSyg8tuCe9+ZvVZa lVHRu95nda2nh/RRfEk+jH2strX2psmb20/bsNa1RQ4ujWJT+HBcaGbeicsyzqZL i+iJjNG/Pm0DRZ6DPfnUfW6/xIJW89L1fZ8sHLtSJ+jsR3tGQeYV5IAh0G5SBnM2 tXsbrQkVeZ3UfwGVK3zxl+C4UqkXyOhxSR2Bagr3QJqPGi7z2MR0/ScRdfJAAuMj 3yUbHZFYzsGBrgWZ4LYGDaZN2HL2Bnb7Er7QXPCSApgE8klHUwGTOPiRmyuKyYkJ cgysMnnxflVRwLEaMO6roLw4xL849yOiWGIJkFJ+zWZxuweEBEjOPUUv7ch+PfLY UNAWE7+BerPf/0UyNZvXw3MtYOd7cQxFCfwItboUV3iFEaG3ZBYhpT6+/mITHJ2i eP7C9M4fGnoU8F6TbLcZ =ELAp -----END PGP SIGNATURE-----

1 0