February 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Dmitry Timoshkov

Jacek Caban <jacek(a)codeweavers.com> wrote: > >>> Please don't create fake embedded blocks. > >> I need this declaration here, otherwise I wouldn't be able to use > >> handles for testing lparam value. > > wparam/lparam could be tested directly in the window procedure. > > It would require some global variables and new window procedure. It's > cleaner to do it using existing tools IMO. Writing the tests for user32 requires a bit of efforts, yes. But since you are new to this area I think it's justified to ask for more tests to show that you well understand the code and can proof that the patch is 100% correct. -- Dmitry.

Feb. 29, 2016

Student interested in GSoC 2016 implementing D3DX9 API idea

by Xu Zhao

Hello Wine Community, First congrats that Wine Project get accepted into GSoC 2016 summer organization! I am currently a PhD student in University of Toronto and I am interested in the D3DX9 API implementation task. Mainly because I would like to see more games can run in wine because of my work! My research field is operating system so I am a pretty good C/CPP programmer. However I am not very familiar with DirectX related programming and hopefully I can get some help from the community, like where to start. I have read the wiki entry of D3DX9 API and want to get some help in selecting a reasonable sized API list, maybe someone can reply and provide some help? Thank you! Regards, - Xu -- Xu Zhao i(a)xuzhao.net

Feb. 29, 2016

The Wine Project has been accepted as a GSoC 2016 mentor organization!

by André Hentschel

Hi, I'm a little late, but yes, we're accepted again!

Feb. 29, 2016

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.

by Miklós Máté

On 02/29/2016 06:10 PM, Matteo Bruni wrote: > 2016-02-29 3:59 GMT+01:00 Ken Thomases <ken(a)codeweavers.com>: >> On Feb 26, 2016, at 5:29 PM, Miklós Máté <mtmkls(a)gmail.com> wrote: >> >>> @@ -2320,6 +2322,7 @@ static BOOL X11DRV_wglDestroyPbufferARB( struct wgl_pbuffer *object ) >>> TRACE("(%p)\n", object); >>> >>> pglXDestroyPbuffer(gdi_display, object->drawable); >>> + pglXDestroyContext(gdi_display, object->tmp_context); >> I think you need to check if object->tmp_context is non-zero before calling glXDestroyContext() to avoid a GLXBadContext error. Mesa handles ctx=0 by doing nothing. I guess the blob drivers do the same. >> >> >>> + if (!object->tmp_context) { >>> + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >>> + object->prev_context = prev_context; >>> + } else if (object->prev_context != prev_context) { >>> + pglXDestroyContext(gdi_display, object->tmp_context); >>> + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >>> + object->prev_context = prev_context; >>> + } >> Those two branches are mostly the same. This could be reduced to: >> >> if (!object->tmp_context || object->prev_context != prev_context) { >> if (object->tmp_context) >> pglXDestroyContext(gdi_display, object->tmp_context); >> object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >> object->prev_context = prev_context; >> } I don't think this improves readability, but whatever. >> >> >> Is it necessary, when a context is destroyed, to go through all wgl_pbuffer structs looking for any whose prev_context matches the one being destroyed and clear it? Otherwise, you risk having a stale reference that could be reused for a different context and not realize you need to recreate tmp_context. Of course, enumerating all of them in a thread-safe manner is going to require a lot of added infrastructure and complexity. > Good point, that's necessary in principle and it shouldn't be too hard > to do by keeping a wgl_pbuffers list (similarly to context_list for > wgl_context, you should probably reuse the same context_section > critical section for synchronization). > > The other points brought up by Ken are valid too of course. If a context is destroyed, and a new context is created, what are the chances that the two pointers end up being the same? MM

Feb. 29, 2016

Re: [PATCH 6/6] d3d10core/tests: Port test_multiple_render_targets() from d3d11.

by Marvin

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=20980 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 5/6] d3d10core/tests: Introduce check_texture_color().

by Marvin

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=20979 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 4/6] d3d11/tests: Introduce check_texture_color().

by Marvin

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=20978 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 3/6] d3d11/tests: Add test for multiple render targets.

by Marvin

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=20977 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 1/6] d3d10core/tests: Port test_create_typeless_resource() from d3d11.

by Marvin

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=20976 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: ole32: Do not open registry keys with no access rights.

by Thomas Faber

On 2016-02-29 17:03, Sebastian Lackner wrote: > On 29.02.2016 16:49, Thomas Faber wrote: >> While simply opening a subkey (as done here) does not require any >> access rights in particular, NtOpenKey with 0 desired access always >> fails with STATUS_ACCESS_DENIED on Windows. >> Consequently specifying a nonzero access is a prerequisite for some day >> fixing Wine's NtOpenKey behavior in this regard. > > It would be nice to have tests for that in the wine source tree > (marked with todo_wine, until all places which rely on it have been fixed). It definitely would! Patch submitted. Thanks, Thomas

Feb. 29, 2016