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

Re: [PATCH 1/5] d3d9/tests: Add some tests for draw methods.

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=23169 Your paranoid android. === w864 (64 bit device) === device.c:4351: Test failed: cw is 0xf60, expected 0x7f. device.c:4360: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4351: Test failed: cw is 0xf60, expected 0x7f. device.c:4360: Test failed: Callback cw is 0xf60, expected 0x7f.

May 24, 2016

How to finish implementing serial port read interval timeouts?

by Alex Henrie

Alexandre, A problem with serial port read interval timeouts was brought up in bug 40540.[1] The code that you wrote [2] works great for some applications, but it does not help others. The problem is that the read interval timer needs to be started immediately if ReadFile is able to read any data from the serial port buffer, rather than waiting for more data to arrive before starting the timer. It seems to me that NtReadFile [3] needs to tell serial_queue_async [4] if it read anything from the serial port before it sent the asynchronous read request to the Wineserver. If anything was read, serial_queue_async needs to start the read interval timer. Otherwise, serial_reselect_async should be the one to start the timer like it is now. I could hack something in to achieve the desired behavior, but before I submit anything, I wanted to ask your opinion on how it should be done. -Alex [1] https://bugs.winehq.org/show_bug.cgi?id=40540 [2] https://source.winehq.org/git/wine.git/commitdiff/bc0bf9e505922b81df1c317d6… [3] https://source.winehq.org/git/wine.git/blob/698d4114677205c3e5a0df659d230fe… [4] https://source.winehq.org/git/wine.git/blob/698d4114677205c3e5a0df659d230fe…

May 24, 2016

Re: ddraw/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=23163 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 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 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

May 23, 2016

Re: [PATCH 1/1] libwine: Use WINEUSER as user_name, if set

by Andrey Gursky

Hi, this is essential for MSYS2 [1]. WINEPREFIX makes wine installation portable, but once you start wine on a different account, you get also a different user on a MSYS2 shell. Regards, Andrey [1] https://msys2.github.io/

May 23, 2016

Re: [PATCH] msacm32: Added converter for ADPCM to PCM 8 bit mono.

by Fabian Maurer

Hello, and thanks for the feedback. The code is mostly C&P, so I didn't know if I should reformat it. I'll try to merge the two functions and fix the indentation in the process. Just wasn't sure if I should touch the working function or rather make a new one for my purposes. I'll resend the patch when I'm finished and have done the required tests. Fabian

May 23, 2016

Re: [PATCH] msacm32: Added converter for ADPCM to PCM 8 bit mono.

by Andrew Eikum

Thanks for working on this. Some comments below. On Fri, May 20, 2016 at 02:54:01AM +0200, Fabian Maurer wrote: > +/*********************************************************************** > + * R8 > + * > + * Read a 8 bit sample > + */ > +static inline short R8(const unsigned char* src) > +{ > + return *src; > +} > + R8 is never used. > + nsamp_blk--; /* remove the sample in block header */ > + for (; nblock > 0; nblock--) > + { > + const unsigned char* in_src = src; > + > + /* handle header first */ > + sample = R16(src); > + stepIndex = (unsigned)*(src + 2); > + clamp_step_index(&stepIndex); > + src += 4; > + W8(dst, sample); dst += 1; > + > + for (nsamp = nsamp_blk; nsamp > 0; nsamp -= 2) > + { > + process_nibble(*src, &stepIndex, &sample); > + W8(dst, sample); dst += 1; > + process_nibble(*src++ >> 4, &stepIndex, &sample); > + W8(dst, sample); dst += 1; > + } The indentation here and elsewhere is a mess. I suggest just using 4-space indents, no hard tabs. > + /* we have now to realign the source pointer on block */ > + src = in_src + adsi->pwfxSrc->nBlockAlign; > + } > +} > + The only difference between cvtMMima8K and cvtMMima16K is a couple of multiplications by 2 and the use of W8 instead of W16, right? I think you can have just one function and use adsi->pwfxDst->wBitsPerSample to determine sample size, to avoid so much code duplication. > - /* adpcm decoding... */ > - if (adsi->pwfxDst->wBitsPerSample == 16 && adsi->pwfxDst->nChannels == 2) > - aad->convert = cvtSSima16K; > - if (adsi->pwfxDst->wBitsPerSample == 16 && adsi->pwfxDst->nChannels == 1) > - aad->convert = cvtMMima16K; > + /* adpcm decoding... */ > + if (adsi->pwfxDst->wBitsPerSample == 16 && adsi->pwfxDst->nChannels == 2) > + aad->convert = cvtSSima16K; > + if (adsi->pwfxDst->wBitsPerSample == 16 && adsi->pwfxDst->nChannels == 1) > + aad->convert = cvtMMima16K; > + if (adsi->pwfxDst->wBitsPerSample == 8 && adsi->pwfxDst->nChannels == 1) > + aad->convert = cvtMMima8K; > + /* FIXME: Stereo support for 8bit samples*/ > + if (adsi->pwfxDst->wBitsPerSample == 8 && adsi->pwfxDst->nChannels == 2) > + goto theEnd; More bad indentation. Andrew

May 23, 2016

Re: shell32: Initialize all of wszDstPath in ISFHelper_fnCopyItems. ISFHelper_fnCopyItems.

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > On Wed, 18 May 2016, Alexandre Julliard wrote: >> Actually there's no reason to initialize the entire buffer. > > And MAXPATH+1 is correct? Or is that arbitrary as well? > > Initialized an array of WCHAR to the size the array would have > were it an array of char feels quite unintuitive, so at least a > comment would be good. MAXPATH+1 is definitely wrong. The intent was clearly to fill the whole buffer, and if this is what we wanted, your fix would be correct. My point is that we don't need to fill the whole buffer, so fixing it the right way would be better. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2016

Re: shell32: Initialize all of wszDstPath in ISFHelper_fnCopyItems. ISFHelper_fnCopyItems.

by Gerald Pfeifer

On Wed, 18 May 2016, Alexandre Julliard wrote: >> wszDstPath is an array of WCHAR, which are wider than one byte, >> so this should have been (MAXPATH+1)*sizeof(WCHAR) -- or the more >> robust approach I here propose. > Actually there's no reason to initialize the entire buffer. And MAXPATH+1 is correct? Or is that arbitrary as well? Initialized an array of WCHAR to the size the array would have were it an array of char feels quite unintuitive, so at least a comment would be good. Gerald

May 22, 2016

Re: [PATCH] wined3d: Don't accept WINED3DFMT_NULL

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-22 um 13:23 schrieb Józef Kucia: > Yes, the handling of WINED3DFMT_NULL textures could be improved. We > should ensure that WINED3DFMT_NULL won't ever have a GL texture > allocated. I'd love to have D3DFMT_NULL textures handled in d3d8 / d3d9, and just set the render target to NULL in wined3d in that case. Afaik having no render target is valid in d3d10. Obviously that means we'll have to handle mapping those textures in the client libraries, which might make this approach uglier than the current one. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXQfk0AAoJEN0/YqbEcdMwQi4P/11gvZpXxhpS3wGFUVb18FPS RvQA9KbasTeRqZMDf0F1ePK8RLEc1N6FMxHRPg9VVVXB5/jY/AyUMdIwbtdkNG8d L6KdaUgf7KOcRiURu40u7PRIBJmNVv/FItPBj2TvO+sXMOuODP/hm+2hOjbwkFon kgTmB34dqIwt+Fa7vZaouN0UpTx28XfxySZB/qmM9ub6uN4mbbKmCJ2sGbeB6+Od RALeW73/VxOoS4JBAnqcrMKZ3cqOzZpluuZ3AIg/RnIP6c1B7PqAZMb7FFA0EwwU 9hPrPrHwT37vqqeTk/aBoldOT8oOgC8luwYC1mEoO9Ges3l4+B/lTvlS0on9tvp4 fn5tPTKaO5S+Zzc48wrMODICCtGuDSHTPHjxl/r1OTV8XIsy8UeiUp6EPE/XTlaF bgJn975JyxVqeiqXkCujiAZVNVQ4mWHHNavRpxlSkFuq28lfIlQd4DxxQmrkyam1 xHnekCjmU02OiRPVHNVr6ScD2Y9BZOwygdbay+mp34bxQxd18wZocipGdHlX4SK0 yHSOeKDZ22bXS8RyFh2qSO2qjKJ3tsPQp2mBvQMOu72oaVGBrOyxYWySFefhBac4 7WQmT5lRC2KNJa8+HIPkTIMhK2yHamNw4vuAaOftHw3hUio412EG4mNniOTzZcP1 0NSdAmcZXKT46RhbFgiV =b32K -----END PGP SIGNATURE-----

May 22, 2016

Re: [PATCH 12/12] wined3d: Use ARB_fragment_coord_conventions for vpos fixups when supported.

by Matteo Bruni

2016-05-22 18:23 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 20 May 2016 at 19:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> if (reg_maps->vpos) >> { >> - if (shader->device->wined3d->flags & WINED3D_PIXEL_CENTER_INTEGER) >> + if (gl_info->supported[ARB_FRAGMENT_COORD_CONVENTIONS]) >> + shader_addline(buffer, "vpos = gl_FragCoord;\n"); >> + else if (shader->device->wined3d->flags & WINED3D_PIXEL_CENTER_INTEGER) > Isn't it harder than that? You're dropping the y-flip completely now. > I think we can actually do that regardless of > ARB_fragment_coord_conventions if we have always_offscreen, but not in > general. You're correct of course... That probably means we need onscreen / offscreen shader variants in the AlwaysOffscreen = disabled case, which might be okay. Although... > It does look like the benefits of ARB_fragment_coord_conventions are > somewhat limited. I probably mixed it up with ARB_clip_control when I > initially suggested it. I think that would allow us to get rid of the > position fixup, but we'd have to make it a requirement for shader > model 4 if we wanted to avoid patch 6/12. Right. It looks like ARB_clip_control is available in Mesa for AMD, Nvidia and Intel since 10.6 so I think it might be reasonable to make use of it when supported (I'd keep it optional). I'll have a look.

May 22, 2016