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

Re: [PATCH 2/2] mscoree: Implement ICorRuntimeHost::CreateDomain{, Ex}(). (try 4)
by Vincent Povirk 16 Feb '16

16 Feb '16

It doesn't seem to work. According to the test program, GetDefaultDomain and CreateDomain are returning the same IUnknown. :( Maybe we need to set the thread domain somehow in RuntimeHost_Invoke?

1 0

Re: ddraw/tests: Use todo_wine_if() in tests
by Marvin 16 Feb '16

16 Feb '16

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=20563 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit d3d) === d3d.c:2329: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2329: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2329: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2329: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2513: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2660: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2660: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2660: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2660: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

XInput: Comments on core and further steps
by Juan Jose Gonzalez 16 Feb '16

16 Feb '16

Hi, I just published a patch with my xinput core implementation. If anyone is interested in an evdev (linux) backend I could publish that too, but I guess it won't make it into wine due to the tendency towards the HID architecture. A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think. The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet: - How can we find new devices? The current work for the HID architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar? - How do we map a controller's buttons and axes to the corresponding XInput ones? This has to be done per controller model. My evdev backend has a lookup list that matches controllers to a certain mapping using some selection criteria (Name, Vendor ID, etc.). My idea was to load the mappings from the registry, but for this to be usable by regular users, a GUI would have to be implemented to create those registry entries. Any ideas are welcome. Juan

4 10

Re: [PATCH 2/2 v4] user32: Add more dialog creation message tests
by Marvin 16 Feb '16

16 Feb '16

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=20560 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:13904: Test failed: 10: WaitForSingleObject failed msg.c:13904: Test failed: 11: WaitForSingleObject failed === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0

Re: [PATCH 6/8] wined3d: Remove fbo_entry->d3d_depth_stencil.
by Henri Verbeet 16 Feb '16

16 Feb '16

On 14 February 2016 at 21:33, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Instead of storing the format flags we could store the depth and stencil > attachments as separate objects in the key. However, I don't think it is > worth making the key bigger. The depth and stencil attachment will > always be the same object. Another option would be to merge it with the "attached" field in to a "flags" field.

1 0

Re: [PATCH 1/8] wined3d: Retrieve FBO attachments from GL in context_check_fbo_status.
by Henri Verbeet 16 Feb '16

16 Feb '16

On 14 February 2016 at 21:33, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + if (gl_info->supported[EXT_FRAMEBUFFER_MULTISAMPLE]) > + gl_info->fbo_ops.glGetRenderbufferParameteriv(GL_RENDERBUFFER, GL_RENDERBUFFER_SAMPLES, &samples); > + else > + samples = 1; I don't think this will do the right thing in core contexts, or if only ARB_framebuffer_object is supported. > + gl_info->fbo_ops.glGetRenderbufferParameteriv(GL_RENDERBUFFER, GL_RENDERBUFFER_INTERNAL_FORMAT, &fmt); > + FIXME("\t%s: renderbuffer %d, %dx%d, %d samples, format %x.\n", > + debug_fboattachment(attachment), name, width, height, samples, fmt); The '\t' is from the original code of course, but please just replace it with spaces. > + FIXME("\t%s: %s texture %d, %dx%d, format %x.\n", debug_fboattachment(attachment), > + tex_type_str, name, width, height, fmt); %#x for hexadecimal, please. > +#define FBOATTACHMENT_TO_STR(u) case u: return #u The existing functions are a bit of a mess in this regard, but I'd prefer "WINED3D_TO_STR" for new functions. > + FIXME("Unrecognied FBO status 0x%08x\n", attachment); > + return "unrecognized"; The FIXME has room for improvement. You could also consider doing something like "return wine_dbg_sprintf("unknown attachment %#x", attachment);"

1 0

Patch assignment notifications
by Alexandre Julliard 16 Feb '16

16 Feb '16

Folks, I've now added automated email notifications for when you are assigned patches to review. I've tried to make it not too annoying for frequent reviewers, and hopefully easy to filter. Please let me know what you think. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2 v3] user32: Add more dialog creation message tests
by Marvin 16 Feb '16

16 Feb '16

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=20553 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0

Re: [PATCH 2/2 v2] user32: Add more dialog creation message tests
by Dmitry Timoshkov 16 Feb '16

16 Feb '16

Hi Piotr, this test doesn't actually provide any proof for the 1/2 patch. I'd expect to see a test that checks also the messages sent/received by edit control. -- Dmitry.

2 1

Re: [PATCH 2/2 v2] user32: Add more dialog creation message tests
by Marvin 16 Feb '16

16 Feb '16

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=20550 Your paranoid android. === w7u (32 bit msg) === msg.c:8799: Test failed: did not get expected count for minimum timeout (54 != ~100). === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0