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

Re: mmdevapi/tests: Fix a typo in ok() messages

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=23320 Your paranoid android. === w7u (32 bit capture) === capture.c:181: Test failed: Position 375 expected 0 capture.c:231: Test failed: Position 1719 expected 823 capture.c:263: Test failed: Position 1719 expected 823 capture.c:325: Test failed: Position 3063 gap 1792 capture.c:329: Test failed: GCP 11200 vs. BufferSize 21996 capture.c:349: Test failed: Position 4407 expected 3511 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5751 expected 3959 capture.c:375: Test failed: flags 1 === w8 (32 bit capture) === capture.c:325: Test failed: Position 3191 gap 1216 capture.c:349: Test failed: Position 4279 expected 3639 capture.c:374: Test failed: Position 5303 expected 4087 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 3127 gap 1152 capture.c:329: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:349: Test failed: Position 4215 expected 3575 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5303 expected 4023 capture.c:375: Test failed: flags 1 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 4151 gap 2176 capture.c:329: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:349: Test failed: Position 5239 expected 4599 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5687 expected 5047 === w864 (64 bit capture) === capture.c:181: Test failed: Position 119 expected 0 capture.c:231: Test failed: Position 2167 expected 567 capture.c:263: Test failed: Position 2167 expected 567 capture.c:325: Test failed: Position 3191 gap 2176 capture.c:329: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:349: Test failed: Position 4279 expected 3639 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 4727 expected 4087 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1143 expected 0 capture.c:231: Test failed: Position 2167 expected 1591 capture.c:263: Test failed: Position 2167 expected 1591 capture.c:325: Test failed: Position 4215 gap 2176 capture.c:329: Test failed: GCP 13440 vs. BufferSize 21996 capture.c:349: Test failed: Position 5239 expected 4663 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5687 expected 5111

June 3, 2016

Re: [PATCH 2/2] msvcr120/tests: Add critical section test.

by Piotr Caban

Hi, something strange happened while sending this patch. It was sent by me. Sorry for that. Piotr On 06/03/16 14:36, YongHao Hu wrote: > From: YongHao Hu <christopherwuy(a)gmail.com> > > This patch supersedes 122410. > > Signed-off-by: YongHao Hu <christopherwuy(a)gmail.com> > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/msvcr120/tests/msvcr120.c | 251 > +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 251 insertions(+) > > > > >

June 3, 2016

Re: [PATCH] wined3d : Set texture target of WINED3DFMT_NULL to 0

by Henri Verbeet

On 2 June 2016 at 07:39, Max Qian <public(a)maxqia.com> wrote: > This fixes https://bugs.winehq.org/show_bug.cgi?id=40624 > Signed-off-by: Max Qian <public(a)maxqia.com> > --- > dlls/wined3d/context.c | 4 ++-- > dlls/wined3d/wined3d_private.h | 5 +++++ > 2 files changed, 7 insertions(+), 2 deletions(-) > The patch got wrapped, please use git send-email for submitting patches. Regardless, I don't think this is an improvement over Józef's patch. (Which I think would be fine for fixing the regression, even if we want to improve the way WINED3DFMT_NULL is handled in general.)

June 3, 2016

Re: user32/tests: Fix a typo in ok() messages

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=23303 Your paranoid android. === w864 (32 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different === w1064 (32 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different === w864 (64 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:10057: Test failed: SendMessageTimeout succeeded msg.c:10058: Test failed: WmEmptySeq: 0: the msg sequence is not complete: expected 0000 - actual 0400 === w1064 (64 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:7440: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

June 3, 2016

Re: urlmon/tests: Fix a typo in ok() message

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=23302 Your paranoid android. === w1064 (32 bit misc) === misc.c:756: Test failed: [52] wrong mime: L"image/x-icon" === w1064 (64 bit misc) === misc.c:756: Test failed: [52] wrong mime: L"image/x-icon"

June 3, 2016

Re: kernel32/tests: Fix a typo in ok() messages

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=23301 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

June 3, 2016

Re: hlink/tests: Fix a typo in ok() messages

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=23300 Your paranoid android. === w1064 (32 bit hlink) === hlink.c:414: Test failed: url only: Saved data differs hlink.c:414: Test failed: url + friendly name: Saved data differs hlink.c:414: Test failed: url + friendly_name + location: Saved data differs hlink.c:414: Test failed: url + target frame name: Saved data differs === w1064 (64 bit hlink) === hlink.c:414: Test failed: url only: Saved data differs hlink.c:414: Test failed: url + friendly name: Saved data differs hlink.c:414: Test failed: url + friendly_name + location: Saved data differs hlink.c:414: Test failed: url + target frame name: Saved data differs

June 3, 2016

[PATCH] Tell dosbox to read the current user's config

by shankao＠gmail.com

Yes, dosbox supports that trick. But I think that Henri was referring about having it in the same args C variable. It's separated in the last patch. Should I resend it again? I'm a bit confused about how wine deals with patch resend. > Yes according to the dosbox man [1]: -userconf Load the configuration file located in ~/.dosbox. Can be combined with the -conf option. http://linux.die.net/man/1/dosbox

June 3, 2016

Re: [PATCH] Tell dosbox to read the current user's config

by Bruno Jesus

On Thu, Jun 2, 2016 at 6:02 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 2 June 2016 at 05:50, Austin English <austinenglish(a)gmail.com> wrote: >> On 06/01/2016 10:48 PM, shankao(a)gmail.com wrote: >>> Thanks, sending again. Please, let me know if it's correct. >> >> Yes, looks good, thanks. >> > Does that work? It seems somewhat suspicious to combine the -userconf > and -conf options into a single argument. Yes according to the dosbox man [1]: -userconf Load the configuration file located in ~/.dosbox. Can be combined with the -conf option. http://linux.die.net/man/1/dosbox

June 3, 2016

Re: [PATCH 5/5] wined3d: User clip planes emulation for core profile contexts.

by Matteo Bruni

2016-06-02 14:41 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 1 June 2016 at 23:16, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> + if (update_mask & WINED3D_SHADER_CONST_VS_CLIP_PLANES) >> + { >> + for (i = 0; i < gl_info->limits.clipplanes; ++i) >> + shader_glsl_clip_plane_uniform(context, state, i, prog); >> + } > It's not wrong, but it seems somewhat arbitrary to use the > legacy/fixed function clip plane limit. It turns out that GL_MAX_CLIP_PLANES and GL_MAX_CLIP_DISTANCES also have the same value so gl_info->limits.clipplanes is actually the clip distances count on core profile (which is at least 8 by spec). I forgot about it when cleaning up the patch :/ I can write a follow up patch to rename limits.clipplanes and use the "modern" enum to get the limit.

June 2, 2016