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

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-12 11:20, schrieb Stefan Dösinger: > Am 2014-02-11 14:23, schrieb Martin Storsjö: >> Yes - now I extended the test to use a non-power-of-two texture >> size, and if I hack out the ARB_TEXTURE_NON_POWER_OF_TWO support >> (in wined3d/directx.c) the tests fail and crash. > Alright, I guess I should have a look at it. It looks like I screwed up heightscale handling with my recent surface memory management rework. YUY2 and UYVY are regular block-based formats, but YV12, NV12 and I420 are not. The block-based properties of those 3 formats (or lack thereof) could use some tests as well. I think I didn't test YV12 when I wrote / updated test_surface_blocks and test_volume_blocks in dlls/d3d9/tests/device.c because none of my cards supported it in d3d9. Maybe that's different with I420 and NV12 - I haven't checked on Windows yet. Ddraw has some YV12 tests in dlls/ddraw/tests/overlay.c. It shows that this format does not use a block-based offset calculation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+069AAoJEN0/YqbEcdMwNAgP/A8tEN/u8cCzQLB+6AHAf2u+ 7NXGlVp/Fg5j3PCxjJZCF2KbRpfB95uw1NdLhK5RsIdMIc1Hp+5yqegCUysLu7hk YDxyg0Vpf7DpT5Dla2VCgRNo1EhdHTTtXCXmMiIcIEbNMnVNNiQFpzSU9LUg3XEc RqfyNHYB1jZL0DsaqjY4IcvKubxlb0biVmZr6+473lAzNYobstZbpQ1Bh/m7Inwk Sqed3dlsasP9C30Bz91M079no5g5sW6kR0Ve8eiXgWEEqAYdqCRUBXxEqRU5n4Fz ZwUj2FNeBgv/uxLqRf5Qc4e0FnbX3CyVrN/Re+Famko+ELze16oQ7azcZXnGx5iw KdBLauQkPP5rg2exl8PeJaJirjjRkm1IAsgWMhzZzZSUQX+rljVtwF6zeZrdQz7u 3TZ2OpmyTkrp33o+HeEHmeK7v6JRuhS6JVFESUDMAJTtc0aXD4R8dqrK+qj0FZVc UM34QRc+i57EAVFIdcIeHWINNe2KWB7sqL62UvITHNEwp2S6nrFlRpUK4AHqtRQ1 YDI/qpTKUDDrNSggJ2bUOsYWzO7UWE19FRy5gWGra3KoamNVYkOSQA06oY2x8+1S /fSf7hs9ZmFj3tSrNet+IiSIWTfSQy9cE3Dwy1Dpc5Ywwl6Gzc06hLH1nCZdeC5N pyFGw3SzvnHEe3BjdImM =pafk -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 14:23, schrieb Martin Storsjö: > Yes - now I extended the test to use a non-power-of-two texture > size, and if I hack out the ARB_TEXTURE_NON_POWER_OF_TWO support > (in wined3d/directx.c) the tests fail and crash. Alright, I guess I should have a look at it. On which Windows systems(Windows version, GPU) did you test your test? I know that there are plenty of differences in YUV handling, so I'd like to run the tests on some of my Windows installations too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+0r+AAoJEN0/YqbEcdMwqGAP/A68ghy8wMyYn/eioC2T/WbY pA47v2lGAMEZmVhBuJHX9YY+VkjO4l1xd8lPsGtnCs0eNXcoEUtonrs39LSv//w8 VeT2EuVmyl6KboA4uf3gVXKudZRvGmWwMMJmAlzPuTO+Dmll5Sm4bf/fJ0VIDj1c oKUS+D0MRJJPEab0g/irXzJDNIcmHZcXaJ30VaUYgkHx3c+2iRTDUhwKYj4ygxb1 TOA/PpTfn8Y6ZXhY9u8QWK2sSjHfDNA3JTa85CJJ/QyWhJ717/RwXek5MSMFqcml Pb4uit/BoAiddaVSty2esazBjbsa8tC3Mp3a2iTzB60NGMYo4Oh8MV6OiPxMVFH3 fH4lRcQrTZ7kYILLZgoEpgPAAzjPhp2QwRaIK5GzcO4vy4yhQasX09lN/oXAgM93 vTJZzMdcbKqI+OMSMoqbzsH7yeJUXtQXIRB18azK0/Vv/Vo3Oy8j+vJmK8HTe8Cs KqS828yuOJCZAt5s0ZNYguiOYRpkC/1AteULxO9oQYUioWeWZC2KlBME5sdpDTLH pJx0GpIqSwEIIwNBSqa9Pr9Xa2EWrK2bOwCphgkSPAVV2U/RQ7SIroWC8opVBlN+ EU+rFMuV4ASXnDe8u1PU2xGW7Xs4YbjEWoPeU33hF1obqdY0H6RFFH/ZA+rqh61Q tfjvovHdl0ynDaVg+A8p =OpGr -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: ddraw/tests: Skip the primary palette tests if the 640x480x8 mode is not supported.

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://newtestbot.winehq.org/JobDetails.pl?Key=4809 Your paranoid android. === w8 (32 bit ddraw2) === ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001.

Feb. 12, 2014

Re: [PATCH 2/4] qedit/tests: Expand the SampleGrabber COM tests.

by Michael Stefaniuc

On 02/12/2014 01:18 AM, Marvin wrote: > 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://newtestbot.winehq.org/JobDetails.pl?Key=4795 > > Your paranoid android. > > > === w2008s64 (32 bit mediadet) === > mediadet.c:150: Test failed: CoCreateInstance failed: 80040154 > mediadet: unhandled exception c0000005 at 00401857 > > === w2008s64 (64 bit mediadet) === > mediadet.c:150: Test failed: CoCreateInstance failed: 80040154 > mediadet: unhandled exception c0000005 at 00000000004017B5 The classic "dll is missing and tests are skipped by winetest.exe". Same for patch 4/4. bye michael

Feb. 12, 2014

Re: How can I get a bugzilla database dump?

by Austin English

On Tue, Feb 11, 2014 at 7:12 PM, Scott Ritchie <scottritchie(a)ubuntu.com>wrote: > A volunteer and I have been working on a secret prototype project for > Wine, but before showing it to the world I'd like to demo how it would > tie in to bugzilla. > > To do this, it would be easiest to just have a copy of our current > database. Is this an easy thing to get for me? > > Thanks, > Scott Ritchie > > > ftp://ftp.winehq.org/pub/wine/wine-bugzilla-20140212.tar.gz -- -Austin

Feb. 12, 2014

How can I get a bugzilla database dump?

by Scott Ritchie

A volunteer and I have been working on a secret prototype project for Wine, but before showing it to the world I'd like to demo how it would tie in to bugzilla. To do this, it would be easiest to just have a copy of our current database. Is this an easy thing to get for me? Thanks, Scott Ritchie

Feb. 11, 2014

Re: ws2_32/tests: Add WSAEnumNameSpaceProviders[A|W] tests (try 2)

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://newtestbot.winehq.org/JobDetails.pl?Key=4799 Your paranoid android. === wxppro (32 bit sock) === sock.c:559: Test failed: oob_server (b30): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:559: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:559: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 000007FEFE4C9CD9

Feb. 11, 2014

Re: ws2_32/tests: Add WSAEnumNameSpaceProviders[A|W] tests

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://newtestbot.winehq.org/JobDetails.pl?Key=4798 Your paranoid android. === build (build) === Make failed

Feb. 11, 2014

Re: [PATCH 4/4] qedit/tests: COM tests for IEnumPins from SampleGrabber.

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://newtestbot.winehq.org/JobDetails.pl?Key=4796 Your paranoid android. === w2008s64 (32 bit mediadet) === mediadet.c:150: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401857 === w2008s64 (64 bit mediadet) === mediadet.c:150: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00000000004017BD

Feb. 11, 2014

Re: [PATCH 2/4] qedit/tests: Expand the SampleGrabber COM tests.

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://newtestbot.winehq.org/JobDetails.pl?Key=4795 Your paranoid android. === w2008s64 (32 bit mediadet) === mediadet.c:150: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401857 === w2008s64 (64 bit mediadet) === mediadet.c:150: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00000000004017B5

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Frédéric Delanoy

On Tue, Feb 11, 2014 at 5:13 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Tue, Feb 11, 2014 at 11:51 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > > What if the field is only editable by users when it's in the > "unspecified" state, this way it would work as before. When changed > from unspecified to any other the field would turn read only for > users. Simplest solution would be to make version field editable - upon bug creation for standard users - by admin users all the time Frédéric

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Bruno Jesus

On Tue, Feb 11, 2014 at 11:51 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Tue, 11 Feb 2014 01:03:52 -0600 > Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> >> I don't think there's a need for a compromise that makes it even more >> complicated. If we're not going to change the policy, making the >> version field write-once for most users is fine for enforcing it imo, >> and as long as we have the original reported version I don't think >> it's worth adding a field for the last tested one. >> > > I agree. > > As for whether the policy should be changed, I can think of one argument against it that hasn't been mentioned: we have a large body of experienced users who are accustomed to doing it the current way, no way to effectively communicate such an abrupt change in policy to all of them, and getting people to change their habits is far more difficult than changing the permissions on a field. In the short term, at least, such a change would lead to more noise in bugzilla as triagers have to explain to experienced users that we've suddenly decided to handle this in a way that is completely opposite to the way we've been doing it for years. What if the field is only editable by users when it's in the "unspecified" state, this way it would work as before. When changed from unspecified to any other the field would turn read only for users.

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Rosanne DiMesio

On Tue, 11 Feb 2014 01:03:52 -0600 Vincent Povirk <madewokherd(a)gmail.com> wrote: > > I don't think there's a need for a compromise that makes it even more > complicated. If we're not going to change the policy, making the > version field write-once for most users is fine for enforcing it imo, > and as long as we have the original reported version I don't think > it's worth adding a field for the last tested one. > I agree. As for whether the policy should be changed, I can think of one argument against it that hasn't been mentioned: we have a large body of experienced users who are accustomed to doing it the current way, no way to effectively communicate such an abrupt change in policy to all of them, and getting people to change their habits is far more difficult than changing the permissions on a field. In the short term, at least, such a change would lead to more noise in bugzilla as triagers have to explain to experienced users that we've suddenly decided to handle this in a way that is completely opposite to the way we've been doing it for years. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 11, 2014

Re: [PATCH 3/6] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Martin Storsjö

On Tue, 11 Feb 2014, Stefan Dösinger wrote: > > Am 11.02.2014 um 12:14 schrieb Martin Storsjo <martin(a)martin.st>: > >> --- >> dlls/wined3d/arb_program_shader.c | 187 +++++++++++++++++++++++++------------- >> 1 file changed, 122 insertions(+), 65 deletions(-) >> >> diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c >> index 6d17ea3..8390c9e 100644 >> --- a/dlls/wined3d/arb_program_shader.c >> +++ b/dlls/wined3d/arb_program_shader.c >> @@ -6768,22 +6768,68 @@ const struct fragment_pipeline arbfp_fragment_pipeline = { >> arbfp_fragmentstate_template, >> }; >> >> +struct arbfp_blit_type >> +{ >> + enum complex_fixup fixup; >> + GLenum textype; >> +}; >> ... >> +static int arbfp_blit_type_compare(const void *key, const struct wine_rb_entry *entry) >> +{ >> + const struct arbfp_blit_type *ka = key; >> + const struct arbfp_blit_type *kb = &WINE_RB_ENTRY_VALUE(entry, const struct arbfp_blit_desc, entry)->type; >> + >> + return memcmp(ka, kb, sizeof(*ka)); >> +} > You have to watch out for padding space added by the compiler if you memcmp the structure. I think there’s no guarantee that enum complex_fixup is 4 bytes. Either use memset to initialize it to zero, or (preferred) make the fixup member a bitfield and add an explicit padding field for the remaining bits (see some structures in wined3d_private.h for examples) and set the padding to zero manually. Ah, right, yes. Or what about just doing two separate comparisons for fixup and textype instead of a memcmp of the struct? // Martin

Feb. 11, 2014

Re: [PATCH 1/3] msvcrt/tests: Don't pass path containing spaces to _spawnvp (try3)

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > I've seen that this patch was marked as pending. I'm not sure what > should I change in it. The argv[0] argument is not used in child > process so maybe it will be clearer if I put some dummy value there. I > can also change the tests to not use _spawnvp. It's probably ok to use the basename, but you have to do it correctly. Also adding a helper function wouldn't hurt. -- Alexandre Julliard julliard(a)winehq.org

Feb. 11, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Tue, 11 Feb 2014, Stefan Dösinger wrote: > Oh, by the way: Were you able to test the texture rectangle codepath > with your test? Yes - now I extended the test to use a non-power-of-two texture size, and if I hack out the ARB_TEXTURE_NON_POWER_OF_TWO support (in wined3d/directx.c) the tests fail and crash. // Martin

Feb. 11, 2014

Re: [PATCH 1/3] msvcrt/tests: Don't pass path containing spaces to _spawnvp (try3)

by Piotr Caban

Hi, s I've seen that this patch was marked as pending. I'm not sure what should I change in it. The argv[0] argument is not used in child process so maybe it will be clearer if I put some dummy value there. I can also change the tests to not use _spawnvp. There's following comment near _spawnvp implementation: Like on Windows, this function does not handle arguments with spaces or double-quotes. Here are some results that shows what happens on windows when the tests are executed without this patch. The behavior on wine is similar. E:\>msvcrt_crosstest.exe file file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 791 tests executed (0 marked as todo, 0 failures), 0 skipped. E:\>"a a\msvcrt_crosstest.exe" file Fatal: test 'a\msvcrt_crosstest.exe' does not exist. file.c:1417: Test failed: bad position 0 expecting 8 file.c:1419: Test failed: Couldn't read back the data Fatal: test 'a\msvcrt_crosstest.exe' does not exist. Fatal: test 'a\msvcrt_crosstest.exe' does not exist. file.c:1987: Test failed: i 0, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '⌂' file.c:1987: Test failed: i 1, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '⌂' file.c:1987: Test failed: i 2, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '⌂' Fatal: test 'a\msvcrt_crosstest.exe' does not exist. file.c:2024: Test failed: fread() returned 0: ferror=0 file.c:2027: Test failed: got '⌂' expected 'Hello worldHello worldHello world' file: 791 tests executed (0 marked as todo, 10 failures), 0 skipped. In the failing case argv[0] = "a" argv[1] = "a\msvcrt_crosstest.exe" argv[2] = "file" Thanks, Piotr

Feb. 11, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

Oh, by the way: Were you able to test the texture rectangle codepath with your test? Am 11.02.2014 um 13:13 schrieb Stefan Dösinger <stefandoesinger(a)gmail.com>: > > Am 11.02.2014 um 12:14 schrieb Martin Storsjo <martin(a)martin.st>: >> +#define D3DFMT_YV12 MAKEFOURCC('Y','V','1','2') >> +#define D3DFMT_I420 MAKEFOURCC('I','4','2','0') >> +#define D3DFMT_NV12 MAKEFOURCC('N','V','1','2’) > There’s no need for global definitions. Other tests that use custom fourccs just use MAKEFOURCC in their code. > >> + struct >> + { >> + DWORD color1, color2; >> + DWORD rgb1, rgb2; >> + } >> + test_data[] = >> + { >> + { 0x000000, 0xffffff, 0x00008800, 0x00ff7dff }, >> + { 0xff0000, 0x00ffff, 0x004aff14, 0x00b800ee }, >> + { 0x00ff00, 0xff00ff, 0x000024ee, 0x00ffe114 }, >> + { 0x0000ff, 0xffff00, 0x00b80000, 0x004affff }, >> + { 0xffff00, 0x0000ff, 0x004affff, 0x00b80000 }, >> + { 0xff00ff, 0x00ff00, 0x00ffe114, 0x000024ee }, >> + { 0x00ffff, 0xff0000, 0x00b800ee, 0x004aff14 }, >> + { 0xffffff, 0x000000, 0x00ff7dff, 0x00008800 }, >> + }; > Please make this static const. The same applies to the formats[] table. > > I’ll look at the details of the test and the other patches later today, when my headache is gone :-\ . >

Feb. 11, 2014

Re: [PATCH 3/6] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Stefan Dösinger

Am 11.02.2014 um 12:14 schrieb Martin Storsjo <martin(a)martin.st>: > --- > dlls/wined3d/arb_program_shader.c | 187 +++++++++++++++++++++++++------------- > 1 file changed, 122 insertions(+), 65 deletions(-) > > diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c > index 6d17ea3..8390c9e 100644 > --- a/dlls/wined3d/arb_program_shader.c > +++ b/dlls/wined3d/arb_program_shader.c > @@ -6768,22 +6768,68 @@ const struct fragment_pipeline arbfp_fragment_pipeline = { > arbfp_fragmentstate_template, > }; > > +struct arbfp_blit_type > +{ > + enum complex_fixup fixup; > + GLenum textype; > +}; > ... > +static int arbfp_blit_type_compare(const void *key, const struct wine_rb_entry *entry) > +{ > + const struct arbfp_blit_type *ka = key; > + const struct arbfp_blit_type *kb = &WINE_RB_ENTRY_VALUE(entry, const struct arbfp_blit_desc, entry)->type; > + > + return memcmp(ka, kb, sizeof(*ka)); > +} You have to watch out for padding space added by the compiler if you memcmp the structure. I think there’s no guarantee that enum complex_fixup is 4 bytes. Either use memset to initialize it to zero, or (preferred) make the fixup member a bitfield and add an explicit padding field for the remaining bits (see some structures in wined3d_private.h for examples) and set the padding to zero manually. > + desc = HeapAlloc(GetProcessHeap(), 0, sizeof(*desc)); > + if (!desc) > + { > + ERR("Out of memory\n"); > + GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)); > + checkGLcall("glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)"); > + GL_EXTCALL(glDeleteProgramsARB(1, &shader)); > + checkGLcall("GL_EXTCALL(glDeleteProgramsARB(1, &shader))"); > + return 0; > + } > ... > + ERR("Out of memory\n"); > + GL_EXTCALL(glDeleteProgramsARB(1, &shader)); > + checkGLcall("GL_EXTCALL(glDeleteProgramsARB(1, &shader))"); > + GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)); > + checkGLcall("glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)"); > + HeapFree(GetProcessHeap(), 0, desc); > + return 0; > + } You can use goto (yes, goto) to avoid code duplication in error handling. See e.g. wined3d_device_init_3d in device.c > - upload_palette(surface, context); I think you lost that call. The unfortunate thing about the P8 conversion is that the shader conversion codepath is essentially dead code for various reasons. So it’s tricky to test and likely already broken.

Feb. 11, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

Am 11.02.2014 um 12:14 schrieb Martin Storsjo <martin(a)martin.st>: > +#define D3DFMT_YV12 MAKEFOURCC('Y','V','1','2') > +#define D3DFMT_I420 MAKEFOURCC('I','4','2','0') > +#define D3DFMT_NV12 MAKEFOURCC('N','V','1','2’) There’s no need for global definitions. Other tests that use custom fourccs just use MAKEFOURCC in their code. > + struct > + { > + DWORD color1, color2; > + DWORD rgb1, rgb2; > + } > + test_data[] = > + { > + { 0x000000, 0xffffff, 0x00008800, 0x00ff7dff }, > + { 0xff0000, 0x00ffff, 0x004aff14, 0x00b800ee }, > + { 0x00ff00, 0xff00ff, 0x000024ee, 0x00ffe114 }, > + { 0x0000ff, 0xffff00, 0x00b80000, 0x004affff }, > + { 0xffff00, 0x0000ff, 0x004affff, 0x00b80000 }, > + { 0xff00ff, 0x00ff00, 0x00ffe114, 0x000024ee }, > + { 0x00ffff, 0xff0000, 0x00b800ee, 0x004aff14 }, > + { 0xffffff, 0x000000, 0x00ff7dff, 0x00008800 }, > + }; Please make this static const. The same applies to the formats[] table. I’ll look at the details of the test and the other patches later today, when my headache is gone :-\ .

Feb. 11, 2014

Re: [PATCH 1/2] wined3d: Add support for NV12 textures

by Martin Storsjö

On Mon, 10 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > The shader looks ok to me. Please add a test - see yuv_color_test in > dlls/d3d9/tests/visual.c as an example, although it might not be > feasible to integrate a NV12 test into the UYVY / YUY2 test loop. > > Since the UYVY / YUY2 test already covers the color space conversion > parts I think a NV12 test should make sure that the coordinate > selection works properly. Test that e.g. a 4x4 or 8x8 texture produces > the correct color pattern. Ok, I've made such a test, will resend the full patchset soon. > Am 2014-02-10 12:08, schrieb Martin Storsjo: >> This fixes video playback with the sample app from OpenH264. >> --- >> I haven't been able to test the GL_TEXTURE_RECTANGLE_ARB codepath >> here - if I explicitly disable >> gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] the same app >> crashes. Similarly for YV12 (which already exists and works), >> if I disable ARB_TEXTURE_NON_POWER_OF_TWO there, the app crashes >> and the video output is also garbled (the luma channel seems to >> be right but chroma is handled incorrectly). > I don't know what could be wrong with the texture rectangle codepath. > I tested it when I wrote it for other formats, but it's quite possible > that it has suffered from bitrot in the years since then. Also keep in > mind that wined3d assumes limited ARB_TEXTURE_NON_POWER_OF_TWO support > if OpenGL 2.0 is supported. Yeah, I might have a look later if I can figure it out. It's probably not of highest priority at the moment anyway. >> @@ -6772,6 +6772,7 @@ struct arbfp_blit_priv { >> GLenum yuy2_rect_shader, yuy2_2d_shader; >> GLenum uyvy_rect_shader, uyvy_2d_shader; >> GLenum yv12_rect_shader, yv12_2d_shader; >> + GLenum nv12_rect_shader, nv12_2d_shader; >> GLenum p8_rect_shader, p8_2d_shader; >> GLuint palette_texture; >> }; > It might be a good idea to replace those 10 shaders and the poorly > scaling search for them with a rbtree. Yeah, I know, I started this > mess, but back then it was just 4 shaders and we've been too lazy to > clean this up since then :-\ . Ok, I made a patch that does this, on top of the NV12 patch. If requested I can reorder them but it's a bit of work. >> + switch(textype) { >> + case GL_TEXTURE_2D: tex = "2D"; break; >> + case GL_TEXTURE_RECTANGLE_ARB: tex = "RECT"; break; >> + default: >> + FIXME("Implement nv12 correction for non-2d, non-rect textures\n"); >> + return FALSE; >> + } > Regarding the code style please use the style found in > dlls/wined3d/cs.c. We're migrating the code style of wined3d to this > style, but since style-only changes are frowned upon we're doing this > as we go. I'm sorry for the mess :-( Ok, I've tried to make the newly added code match this as well as possible. // Martin

Feb. 11, 2014

Re: [PATCH 2/2] draw: Return the D3D identifier when GetDeviceIdentifier is called with no flags.

by Henri Verbeet

On 11 February 2014 06:54, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > + memset(&adapter_id, 0x0, sizeof(adapter_id)); > + adapter_id.driver = DriverName; > + adapter_id.driver_size = sizeof(DriverName); > + adapter_id.description = DriverDescription; > + adapter_id.description_size = sizeof(DriverDescription); I think you can just write that as: + adapter_id.driver = DDDI->szDriver; + adapter_id.driver_size = sizeof(DDDI->szDriver); + adapter_id.description = DDDI->szDescription; + adapter_id.description_size = sizeof(DDDI->szDescription); + adapter_id.device_name_size = 0; > + /* check how strings are copied into the structure */ > + ok(pdddi2->szDriver[MAX_DDDEVICEID_STRING - 1]==0, "szDriver not cleared\n"); > + ok(pdddi2->szDescription[MAX_DDDEVICEID_STRING - 1]==0, "szDescription not cleared\n"); I don't think there anything in the code that guarantees this.

Feb. 11, 2014

Re: [2/2] shell32: Supply a module name to CreateProcess

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > --- a/dlls/shell32/shlexec.c > +++ b/dlls/shell32/shlexec.c > @@ -315,6 +315,8 @@ static UINT_PTR SHELL_ExecuteW(const WCHAR *lpCmd, WCHAR *env, BOOL shWait, > WCHAR curdir[MAX_PATH]; > DWORD dwCreationFlags; > const WCHAR *lpDirectory = NULL; > + WCHAR module_path[MAX_PATH] {0}; Does this really compile? -- Dmitry.

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> A potential other option..two fields: > First known buggy version: > Last tested version: > > (not necessarily a fan of it, just brainstorming) I don't think there's a need for a compromise that makes it even more complicated. If we're not going to change the policy, making the version field write-once for most users is fine for enforcing it imo, and as long as we have the original reported version I don't think it's worth adding a field for the last tested one.

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Austin English

On Mon, Feb 10, 2014 at 9:35 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > > > > Probably, but it saves quite a bit of time and hair for a tester and > > > avoids inspecting the whole bug history and all the comments to find > out > > > an exact version that an original reporter had used. There are bug > reports > > > where somebody comes and says "The bug is back!", so in order to test > whether > > > this is a regression or the bug was never fixed one needs to test using > > > an original Wine version. > > > > In a situation like that you should be inspecting the comments anyway. > > The only difference if we change the version field is that you have to > > open the bug history, search for Version, and read the first entry to > > find out what the original reported version was (if that first entry > > is wrong, there will be a comment explaining what it actually is and > > why). > > For instance the Regression SHA1 field was introduced exactly to avoid > searching through all the comments and filtering the wrong ones. > > > And inspecting the comments will be faster because they won't be > > cluttered with "still present in x.y.z". > > I wouldn't be so sure about both of these statements :). > > -- > Dmitry. > A potential other option..two fields: First known buggy version: Last tested version: (not necessarily a fan of it, just brainstorming) -- -Austin

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Probably, but it saves quite a bit of time and hair for a tester and > > avoids inspecting the whole bug history and all the comments to find out > > an exact version that an original reporter had used. There are bug reports > > where somebody comes and says "The bug is back!", so in order to test whether > > this is a regression or the bug was never fixed one needs to test using > > an original Wine version. > > In a situation like that you should be inspecting the comments anyway. > The only difference if we change the version field is that you have to > open the bug history, search for Version, and read the first entry to > find out what the original reported version was (if that first entry > is wrong, there will be a comment explaining what it actually is and > why). For instance the Regression SHA1 field was introduced exactly to avoid searching through all the comments and filtering the wrong ones. > And inspecting the comments will be faster because they won't be > cluttered with "still present in x.y.z". I wouldn't be so sure about both of these statements :). -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> Probably, but it saves quite a bit of time and hair for a tester and > avoids inspecting the whole bug history and all the comments to find out > an exact version that an original reporter had used. There are bug reports > where somebody comes and says "The bug is back!", so in order to test whether > this is a regression or the bug was never fixed one needs to test using > an original Wine version. In a situation like that you should be inspecting the comments anyway. The only difference if we change the version field is that you have to open the bug history, search for Version, and read the first entry to find out what the original reported version was (if that first entry is wrong, there will be a comment explaining what it actually is and why). And inspecting the comments will be faster because they won't be cluttered with "still present in x.y.z".

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > > > > The original version is useful to test the original bug, it may be the > > > > difference between resolving it as FIXED (was able to reproduce and no > > > > longer happens) or WORKSFORME (could not reproduce in the reported > > > > version and nowadays). > > > > > > Why is the original version better for this purpose than a later > > > version that was tested and known to be affected by the bug? > > > > It's always better to test using exact version that the user had in order > > to avoid any side effects of patches applied after that point, possible > > another regression, something else that may happen after that (like > > introducing new compiler optimization in default flags, changed config.h > > dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.) > > > > Testing using a later Wine version may reproduce something that looks > > like an original bug but be not the same thing in reality. > > > > -- > > Dmitry > > > > I think the number of cases where this would matter is trivial (compared to > the overall problem of what the version field means/keeping that value > meaningful). Probably, but it saves quite a bit of time and hair for a tester and avoids inspecting the whole bug history and all the comments to find out an exact version that an original reporter had used. There are bug reports where somebody comes and says "The bug is back!", so in order to test whether this is a regression or the bug was never fixed one needs to test using an original Wine version. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Austin English

On Mon, Feb 10, 2014 at 4:40 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > > > > The original version is useful to test the original bug, it may be the > > > difference between resolving it as FIXED (was able to reproduce and no > > > longer happens) or WORKSFORME (could not reproduce in the reported > > > version and nowadays). > > > > Why is the original version better for this purpose than a later > > version that was tested and known to be affected by the bug? > > It's always better to test using exact version that the user had in order > to avoid any side effects of patches applied after that point, possible > another regression, something else that may happen after that (like > introducing new compiler optimization in default flags, changed config.h > dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.) > > Testing using a later Wine version may reproduce something that looks > like an original bug but be not the same thing in reality. > > -- > Dmitry > I think the number of cases where this would matter is trivial (compared to the overall problem of what the version field means/keeping that value meaningful). -- -Austin

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > The original version is useful to test the original bug, it may be the > > difference between resolving it as FIXED (was able to reproduce and no > > longer happens) or WORKSFORME (could not reproduce in the reported > > version and nowadays). > > Why is the original version better for this purpose than a later > version that was tested and known to be affected by the bug? It's always better to test using exact version that the user had in order to avoid any side effects of patches applied after that point, possible another regression, something else that may happen after that (like introducing new compiler optimization in default flags, changed config.h dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.) Testing using a later Wine version may reproduce something that looks like an original bug but be not the same thing in reality. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> The original version is useful to test the original bug, it may be the > difference between resolving it as FIXED (was able to reproduce and no > longer happens) or WORKSFORME (could not reproduce in the reported > version and nowadays). Why is the original version better for this purpose than a later version that was tested and known to be affected by the bug?

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Bruno Jesus

On Mon, Feb 10, 2014 at 10:14 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> That's a bad idea IMO. Version field as "version where the bug was >> found" provides useful information as an "upper bound", i.e. for v_N, >> the bug appeared in V_i...V_N-1, V_N >> If you change the meaning of the field, you'd have to examine the bug >> history to find that info. > > When would that information be useful apart from regressions? If it's > only useful for regressions, aren't we optimizing for an uncommon > case? The original version is useful to test the original bug, it may be the difference between resolving it as FIXED (was able to reproduce and no longer happens) or WORKSFORME (could not reproduce in the reported version and nowadays). Bruno

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> That's a bad idea IMO. Version field as "version where the bug was > found" provides useful information as an "upper bound", i.e. for v_N, > the bug appeared in V_i...V_N-1, V_N > If you change the meaning of the field, you'd have to examine the bug > history to find that info. When would that information be useful apart from regressions? If it's only useful for regressions, aren't we optimizing for an uncommon case? Generally, regressions will have that information in a comment anyway, and indirectly in the Regression SHA1 field.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Frédéric Delanoy

On Mon, Feb 10, 2014 at 6:32 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > In fact, I would like to propose that we change the field's definition > to be the LATEST WINE VERSION in which the bug is known to be present. > This way, people retesting bugs won't have to flood them with comments > of "still present in version x.y.x", and one can quickly search to > find e.g. download bugs that weren't tested recently. That's a bad idea IMO. Version field as "version where the bug was found" provides useful information as an "upper bound", i.e. for v_N, the bug appeared in V_i...V_N-1, V_N If you change the meaning of the field, you'd have to examine the bug history to find that info. -- Frédéric Delanoy

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Rosanne DiMesio

> On Mon, Feb 10, 2014 at 5:32 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > I've not seen any explanation in this > > thread of when any affected version is not good enough, and you really > > need to know the version the reporter was using. The only situation I can think of where this would be important is when the bug reporter claims it is a regression, but does not do a regression test. Someone who comes along later and is willing to run the regression test will want to know the first bad version. However, presumably that info would still be available in the bug's history field, so changing it in the version field shouldn't be a problem. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 10, 2014

Re: [PATCH 1/5] wined3d: Introduce a sub resource structure.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-10 17:59, schrieb Henri Verbeet: > On 10 February 2014 13:28, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> This structure will be a base structure for buffers, surfaces >> and volumes. It will take care of location management, opengl >> buffers, mapping and (at least for now) memory allocation. Sub >> resources will also store the pointer to the container resource. >> > I'm not convinced this is really the correct approach to this. Do you have any specific concerns or alternative ideas? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+R2bAAoJEN0/YqbEcdMwERQP/1eDnXTbI6Hzs5HK28TXGOlc wo3fCvLsp0ZCYOaWLLIU7qT6DJpxjfC6YqKgCRoPpjI9bhHL0hK/vdC89paN0CN6 Qtuq5vktDCaZ9RtuEaAeaQo005d9SxfDh5fLYFEIo+VAjRvb7cQLusiHaiei86Ut WetV6fM9NfHb1E+TOCIAnhkDb2mwhak4iGjIALcpNcRq8OEKOrdDNejk+jHB9bsK aUxU9j3om2EIc9FLHrncosH1GQE4rA4uBV82R3/vNaAGh2deFAuMDFNMJc0M9GrS 8zOPISJxhJzXOVT8fCEfKLcTt7+Aebj+7NIw9BjPP/eg8SBd4SQJ9iM3B2eeVM39 TnzbapXmuUDTbgf6wsebAx9M5S3w+m3yyLJQFC4UJ8lFO8pNqOVvF7gv0NScS7VN kBB/npqr9tLK+Wqa5LOenNYZOdqmUcvuPjDuzI/rrpeiPE3/QdDeFm4uDJ7Ea+9Y ahUk7OkXMTropCrn0j552OTkDasiSfDAgI95shZ0mKtlF+bB28Ef+/GL7cNTZ1bW 1aDb1GsWqsEuEoJI0I+s6Ui6QIo3DSJol2qPOgqo0U/E4qXzhg7z4tBZ8wlSxYdZ MmbXHnkikQPyiud82HgafUXqFzHYfBsJG/UK6OkwgARnLc8d5J1yWdtBzW8hDG79 NZA6/TaxAyI2OJhW/QUH =OQkX -----END PGP SIGNATURE-----

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Jerome Leclanche

On Mon, Feb 10, 2014 at 5:32 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> IMO that field is important for testing bugs in the correct or at >> least a close wine version in order to reproduce the issue. > > But it should be equally useful for this as long as it's a version > where the bug is present. It doesn't matter whether it was the > originally reported version. I've not seen any explanation in this > thread of when any affected version is not good enough, and you really > need to know the version the reporter was using. I believe there is no > situation where that is important, and people changing it back are > just adding noise to the bug for no good reason. > > In fact, I would like to propose that we change the field's definition > to be the LATEST WINE VERSION in which the bug is known to be present. > This way, people retesting bugs won't have to flood them with comments > of "still present in version x.y.x", and one can quickly search to > find e.g. download bugs that weren't tested recently. > > As a bugzilla triager, I am extremely highly in favour of that. It makes a lot more sense for users, is a lot more easily explained and won't cause so much meta-drama. But then again, it's whatever is most useful to the devs that really matters. J. Leclanche

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> IMO that field is important for testing bugs in the correct or at > least a close wine version in order to reproduce the issue. But it should be equally useful for this as long as it's a version where the bug is present. It doesn't matter whether it was the originally reported version. I've not seen any explanation in this thread of when any affected version is not good enough, and you really need to know the version the reporter was using. I believe there is no situation where that is important, and people changing it back are just adding noise to the bug for no good reason. In fact, I would like to propose that we change the field's definition to be the LATEST WINE VERSION in which the bug is known to be present. This way, people retesting bugs won't have to flood them with comments of "still present in version x.y.x", and one can quickly search to find e.g. download bugs that weren't tested recently.

Feb. 10, 2014

Re: [PATCH 1/5] wined3d: Introduce a sub resource structure.

by Henri Verbeet

On 10 February 2014 13:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This structure will be a base structure for buffers, surfaces and > volumes. It will take care of location management, opengl buffers, > mapping and (at least for now) memory allocation. Sub resources will > also store the pointer to the container resource. > I'm not convinced this is really the correct approach to this.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Bruno Jesus

On Mon, Feb 10, 2014 at 11:18 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Mon, Feb 10, 2014 at 04:28:48PM +0900, Dmitry Timoshkov wrote: >> Jerome Leclanche <adys.wh(a)gmail.com> wrote: >> > What is the reasoning behind that, really? What is the point of having >> > a version field that tells the developers absolutely nothing? >> >> One need to be a developer to comment on this I'd guess, but telling an >> exact used Wine version in the bug report is already a very good start. >> > > I don't know. As a developer, I've never used that field for anything, > and I find the "user changed version, admin changed it back" dance to > be a distraction in my Bugs mailbox. IMO that field is important for testing bugs in the correct or at least a close wine version in order to reproduce the issue. I vote for setting the field as admin only, and maybe a "set once" for users when they report the bug, it then can be reset by admins later. Regards, Bruno

Feb. 10, 2014

Re: bcrypt: Add semi-stub implementation of BCryptGenRandom (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > + > + /* Zero sized buffer should work too */ > + ret = pBCryptGenRandom(NULL, buffer, 0, BCRYPT_USE_SYSTEM_PREFERRED_RNG); > + ok(ret == STATUS_SUCCESS, "Expected success, got 0x%x\n", ret); > + > + /* Test random number generation - It's impossible for a sane RNG to return 8 zeros */ > + rnd[0] = 0; > + rnd[1] = 0; > + ret = pBCryptGenRandom(NULL, buffer, sizeof(DWORD) * 2, BCRYPT_USE_SYSTEM_PREFERRED_RNG); > + ok(ret == STATUS_SUCCESS, "Expected success, got 0x%x\n", ret); > + ok(rnd[0] || rnd[1], "Expected a random number, got 0\n"); > + trace("BCryptGenRandom : %08X%08X\n", rnd[0], rnd[1]); There's no reason to work with DWORDs, the function returns bytes, just use that directly. -- Alexandre Julliard julliard(a)winehq.org

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Jerome Leclanche <adys.wh(a)gmail.com> wrote: > > > What is the reasoning behind that, really? What is the point of having > > > a version field that tells the developers absolutely nothing? > > > > One need to be a developer to comment on this I'd guess, but telling an > > exact used Wine version in the bug report is already a very good start. > > > > I don't know. As a developer, I've never used that field for anything, > and I find the "user changed version, admin changed it back" dance to > be a distraction in my Bugs mailbox. Just add a e-mail filter? > I'd be fine if we just eliminated the field entirely. You probably don't follow bugzilla close enough if the version field is not important to you. Quite often precise Wine version could be a sign of a known bug/fix/regression. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Andrew Eikum

On Mon, Feb 10, 2014 at 04:28:48PM +0900, Dmitry Timoshkov wrote: > Jerome Leclanche <adys.wh(a)gmail.com> wrote: > > What is the reasoning behind that, really? What is the point of having > > a version field that tells the developers absolutely nothing? > > One need to be a developer to comment on this I'd guess, but telling an > exact used Wine version in the bug report is already a very good start. > I don't know. As a developer, I've never used that field for anything, and I find the "user changed version, admin changed it back" dance to be a distraction in my Bugs mailbox. I'd be fine if we just eliminated the field entirely. Andrew

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Rosanne DiMesio

> > Reports for too old versions could be avoided by not listing old versions > at all, and telling a user that if he/she can't find his/her version in > the list to upgrade. > > -- The AppDB already does that, so I can tell you from experience that users who cannot find their version on the list will simply choose one arbitrarily and then explain in a comment that they are really using version x, but it wasn't on the list. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 10, 2014

Re: [PATCH 1/2] wined3d: Add support for NV12 textures

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The shader looks ok to me. Please add a test - see yuv_color_test in dlls/d3d9/tests/visual.c as an example, although it might not be feasible to integrate a NV12 test into the UYVY / YUY2 test loop. Since the UYVY / YUY2 test already covers the color space conversion parts I think a NV12 test should make sure that the coordinate selection works properly. Test that e.g. a 4x4 or 8x8 texture produces the correct color pattern. Am 2014-02-10 12:08, schrieb Martin Storsjo: > This fixes video playback with the sample app from OpenH264. > --- > I haven't been able to test the GL_TEXTURE_RECTANGLE_ARB codepath > here - if I explicitly disable > gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] the same app > crashes. Similarly for YV12 (which already exists and works), > if I disable ARB_TEXTURE_NON_POWER_OF_TWO there, the app crashes > and the video output is also garbled (the luma channel seems to > be right but chroma is handled incorrectly). I don't know what could be wrong with the texture rectangle codepath. I tested it when I wrote it for other formats, but it's quite possible that it has suffered from bitrot in the years since then. Also keep in mind that wined3d assumes limited ARB_TEXTURE_NON_POWER_OF_TWO support if OpenGL 2.0 is supported. > @@ -6772,6 +6772,7 @@ struct arbfp_blit_priv { > GLenum yuy2_rect_shader, yuy2_2d_shader; > GLenum uyvy_rect_shader, uyvy_2d_shader; > GLenum yv12_rect_shader, yv12_2d_shader; > + GLenum nv12_rect_shader, nv12_2d_shader; > GLenum p8_rect_shader, p8_2d_shader; > GLuint palette_texture; > }; It might be a good idea to replace those 10 shaders and the poorly scaling search for them with a rbtree. Yeah, I know, I started this mess, but back then it was just 4 shaders and we've been too lazy to clean this up since then :-\ . > + switch(textype) { > + case GL_TEXTURE_2D: tex = "2D"; break; > + case GL_TEXTURE_RECTANGLE_ARB: tex = "RECT"; break; > + default: > + FIXME("Implement nv12 correction for non-2d, non-rect textures\n"); > + return FALSE; > + } Regarding the code style please use the style found in dlls/wined3d/cs.c. We're migrating the code style of wined3d to this style, but since style-only changes are frowned upon we're doing this as we go. I'm sorry for the mess :-( -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+MA3AAoJEN0/YqbEcdMw434P/36l/R7vl7k3mx24+cYw1mll DOqx4yov+V+I3ERFbQjWmzwvAKoxFbo2+Qn7AaEAegGk1x5G3cuw4jZmo+C4bUb0 uvePY9WbvZptGFdavLAEgYWaBtY6M9pNJkp1PuIehqeq9D3XP98AUH4awzWFbfcD /dQQGVow1D8hkp57iATzUpEwDZBGttAePxyYR/gj7r1FnqPpVD0NW/zWoLJBWMrq 4YQSZBmJQK3xq5mcVlajNUg0Ylh82fp0bzxCie8Zw1jNuahmbGEAaht87fzxWCMc DgdcCS19aZEa39kNT/0ft/vybIPNyHVA+Mon+JgYmEVQRxhJMCl6gYbEKYCWcs0f OZc6d5B8Z4PX9FiPTnofs49SRq2+Gh6YggJdjToY2YZ2iOGgD4A87EIj2iZQc+6w 9jz2SLIZPl4zrjBY5Ji31qyKy8c+emOO9KC1OdnkFPo6eUeIussjrCfX7r2mNyRs 2qNHLz2yrd8aG0+swYvHocZ/wnUeOtgaTYJef8BTEut0+iBsDJ/eQom1/84orhxJ oHmdTbfepXMEoQvhkMSu79gZBMnwvFERZngzOPjKuw0KS3XM+KIFOy1nFeVAMGvb AoVa39jkByIcF0tN6vuf12LdWtdMqkwKeNuF36iEwVAgzkr8pAU6xHL5QqY1QhuB zsCB0PSX3QSmNC/4s7k8 =r3du -----END PGP SIGNATURE-----

Feb. 10, 2014

Re: configure: Avoid nesting cat calls.

by Alexandre Julliard

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > @@ -3453,9 +3453,7 @@ fi > AC_CONFIG_COMMANDS([Makefile], [wine_fn_output_makefile Makefile], > [wine_fn_output_makefile () > { > - cat Make.tmp - <<\_WINE_EOF >\$tmp/makefile && mv -f \$tmp/makefile \$[]1 && rm -f Make.tmp && return > -`cat $wine_rules_file` > -_WINE_EOF > + cat Make.tmp $wine_rules_file >\$tmp/makefile && mv -f \$tmp/makefile \$[]1 && rm -f Make.tmp && return This doesn't do the same thing at all, it can't possibly work. -- Alexandre Julliard julliard(a)winehq.org

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Jerome Leclanche <adys.wh(a)gmail.com> wrote: > > Reports for too old versions could be avoided by not listing old versions > > at all, and telling a user that if he/she can't find his/her version in > > the list to upgrade. > > I'd be in favour of dropping old versions, unfortunately I believe > this involves thousands of existing bugs losing their current version > field. Not listing old Wine versions at the bug reporting time and actually removing those versions from bugzilla altogether are two separate things. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Michael Stefaniuc

On 02/10/2014 08:47 AM, Jerome Leclanche wrote: > On Mon, Feb 10, 2014 at 7:28 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: >> >> Reports for too old versions could be avoided by not listing old versions >> at all, and telling a user that if he/she can't find his/her version in >> the list to upgrade. > > I'd be in favour of dropping old versions, unfortunately I believe > this involves thousands of existing bugs losing their current version > field. The best solution would be to keep the old versions but filter them out from the drop down that is presented to the users. > Then again, I hate bugzilla and the new bug page is a UX disaster. The > minuscule scroll areas for component/version, the attachment size > limit which gives no warning at that point (and simply disappears once > the bug is filed)... > While we're talking about changes to the new bug UI, I'd like to > suggest dropping Component from there altogether and put it in > advanced fields (if editable by users at all - you need a pretty deep > understanding of wine/windows APIs to pick one). The Component field is useful though I would prefer if we could drop the "directx-" prefix from the components that have it. The "Comp" field in the bug listings is too short and shows only "directx-". bye michael

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Frédéric Delanoy

On Mon, Feb 10, 2014 at 3:10 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote: > >> Version field should be never changed and left at the original version >> that the user had reported the problem for. There is no point in changing >> it to an earlier or a later one IMHO. > > Well, if that's the consensus that develops, then perhaps we could either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.) (b) would be best IMO. BTW the Version field explanation can be found when hovering the "Version" field in bug creation form ("The version field defines the version of the software the bug was found in"). That sentence seems clear enough, although one could maybe replace "software" by "Wine". -- Frédéric Delanoy

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Jerome Leclanche

On Mon, Feb 10, 2014 at 7:28 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Reports for too old versions could be avoided by not listing old versions > at all, and telling a user that if he/she can't find his/her version in > the list to upgrade. I'd be in favour of dropping old versions, unfortunately I believe this involves thousands of existing bugs losing their current version field. Then again, I hate bugzilla and the new bug page is a UX disaster. The minuscule scroll areas for component/version, the attachment size limit which gives no warning at that point (and simply disappears once the bug is filed)... While we're talking about changes to the new bug UI, I'd like to suggest dropping Component from there altogether and put it in advanced fields (if editable by users at all - you need a pretty deep understanding of wine/windows APIs to pick one). J. Leclanche

Feb. 10, 2014