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

Re: [PATCH] d3dx9: Improve performance and memory usage in preshader constants setting.

by Matteo Bruni

2016-05-31 11:48 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 05/31/2016 12:24 AM, Matteo Bruni wrote: >> This seems overly complicated and fragile. >> Instead of this kind of "5 instructions bytecode" isn't it easier to >> just store and then lookup a struct with all the info you need? > Keeping a struct with offsets & count altogether is of course more > straightforward, but I intentionally did it this way to save a lot of > extra space and to introduce an easier coalescing. When there is a > matrix transpose involved (which happens quite often in real apps as far > as I have seen) the whole structure would be duplicated for every matrix > element. In the current approach each element for transposed matrix has > just one offset (destination offset changes sequentially and does not > come to the array for each matrix element) and one count of 1. The other > way to optimize this is to introduce a separate operation for transposed > matrix copy, but will it really be simpler or nicer than it is now? > Current approach is indeed a sort of encoding the data copy into a very > simple bytecode. Keeping the whole struct and optimizing as a separate > op for matrix transpose would be the same in principle, but I am afraid > will result in a bit more code and a bit more mess as there will be more > cases to handle. I thought the current approach is simpler as the data > copy is encoded in a generic and simple way so on the actual copy I do > not have to care for any specifics of initial parameter & constant > layout, as well as in process of extending the array & coalescing. I don't see why just moving the part of set_constants() which generates the set_state structures for each "copy" to init time would be more complicated than the current solution. It might take some more memory (not a whole lot more, AFAICS) but other than that it seems strictly nicer to me. Maybe it's a case of "beauty is in the eye of the beholder", I don't know... The issue with transposed matrices seems mostly orthogonal to the encoding of the constant uploads and I agree it's important. What about simply adding a transpose flag and the stride of the matrix and encode it all in one struct (or something like a COPY_STATE_TYPE_COPY_TRANSPOSED op for your approach)? It seems it should be good from a practical standpoint and it should reduce the number of operations (encoded either way) you have to store by a lot. >> I >> guess the end result would be something akin to storing an array of >> struct d3dx_const_copy_state in place of struct d3dx_const_param_set. >> I don't know how the code would exactly look like but I would start by >> moving building all the struct d3dx_const_copy_param to init time. > I am not sure I understand what you mean here, could you please clarify? > In the variant currently suggested the whole building of structure > responsible for parameter copy is already done solely at init time. > Shader/preshader full constant structure is not stored anymore. There is > still an array of parameters and constant description left which is > currently used in effect.c code for setting sampler states. This could > easily be optimized further by not storing the parameters other than > samplers and storing just register index instead of the whole constant > descs for them, but this looked as a separate step to me not fully > related to this patch. Or probably I am misunderstanding your point here. Yeah, that can and should certainly be a separate patch. What I mean is storing the structs d3dx_const_copy_state you compute in set_constants() (as they are right before actually setting the values) in struct d3dx_const_tab in place of the structs d3dx_const_param_set you use to generate them. Does it make sense? >> BTW >> the coalescing you currently do in add_const_set() could be >> potentially done as a separate pass after you generate all the >> "d3dx_const_copy_state-like" structures (but still at init time), >> which might be simpler. > It can be done as a separate pass, but why? In my understanding it will > result just in bigger intermediate array and a few more lines of code. I > will need to do all the same but not at once when getting an "copy > request" but from scanning the pre-stored array. Or am I missing something? No, that's right. It is just an alternative option which I mentioned because it might be simpler or more powerful (e.g. it makes possible to coalesce multiple copies which are not next to each other - it probably wouldn't help much at the moment since you can't coalesce accesses from multiple parameters) in some case. Feel free to take or ignore it.

May 31, 2016

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v5)

by Aaryaman Vasishta

Yup, I'm working on frames and viewports right now. There's no immediate need for these to get in, but I hope it will, eventually :) Cheers, Aaryaman On Wed, Jun 1, 2016 at 12:51 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 31 May 2016 at 14:01, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > Any reviews? Should I resend this patch? > > > I had hoped to have reviewed this by now, but clearly haven't. I'm not > sure when I will, but in the mean time, if you have easier patches, > those don't necessarily need to wait for these to go in. >

May 31, 2016

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v5)

by Henri Verbeet

On 31 May 2016 at 14:01, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > Any reviews? Should I resend this patch? > I had hoped to have reviewed this by now, but clearly haven't. I'm not sure when I will, but in the mean time, if you have easier patches, those don't necessarily need to wait for these to go in.

May 31, 2016

Re: [PATCH] user32/tests: Fix a leak when creating test icons (Valgrind)

by Nikolay Sivov

On 31.05.2016 14:52, Marvin wrote: > 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=23256 > > Your paranoid android. > > > === w864 (32 bit cursoricon) === > > === w1064 (32 bit cursoricon) === > > === w864 (64 bit cursoricon) === > > === w1064 (64 bit cursoricon) === > Those are already failing without this patch.

May 31, 2016

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v5)

by Aaryaman Vasishta

Any reviews? Should I resend this patch? Cheers, Aaryaman On Tue, May 24, 2016 at 8:36 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Tue, May 24, 2016 at 8:32 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > >> On 24 May 2016 at 16:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> >> wrote: >> > Hi, >> > >> > Now that the first 5 patches in the series are committed, I was >> wondering if >> > there's any changes required in this patch (and 7/7) ? >> > >> Possibly, but this one is a bit more complicated than the 5 that came >> before, and I haven't reviewed it in detail yet. >> > Sure, I will wait for your review :) > > Cheers, > Aaryaman >

May 31, 2016

Re: [PATCH] user32/tests: Fix a leak when creating test icons (Valgrind)

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=23256 Your paranoid android. === w864 (32 bit cursoricon) === cursoricon.c:1438: Test failed: Create cursor failed. cursoricon.c:1443: Test failed: GetIconInfo() failed. cursoricon.c:1445: Test failed: Last error: 1402 cursoricon.c:1460: Test failed: DestroyCursor() failed. cursoricon.c:1462: Test failed: Last error: 1402 cursoricon.c:1595: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1602: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1603: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1604: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1610: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1622: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1628: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1662: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1668: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1674: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1681: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1683: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1684: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1687: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1704: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1716: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1722: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1747: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2624: Test failed: LoadImage() failed with 0. cursoricon.c:2624: Test failed: LoadImage() failed with 0. === w1064 (32 bit cursoricon) === cursoricon.c:1438: Test failed: Create cursor failed. cursoricon.c:1443: Test failed: GetIconInfo() failed. cursoricon.c:1445: Test failed: Last error: 1402 cursoricon.c:1460: Test failed: DestroyCursor() failed. cursoricon.c:1462: Test failed: Last error: 1402 cursoricon.c:1595: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1602: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1603: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1604: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1610: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1622: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1628: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1662: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1668: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1674: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1681: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1683: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1684: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1687: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1704: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1716: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1722: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1747: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2624: Test failed: LoadImage() failed with 0. cursoricon.c:2624: Test failed: LoadImage() failed with 0. === w864 (64 bit cursoricon) === cursoricon.c:1438: Test failed: Create cursor failed. cursoricon.c:1443: Test failed: GetIconInfo() failed. cursoricon.c:1445: Test failed: Last error: 1402 cursoricon.c:1460: Test failed: DestroyCursor() failed. cursoricon.c:1462: Test failed: Last error: 1402 cursoricon.c:1595: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1602: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1603: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1604: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1610: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1622: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1628: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1662: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1668: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1674: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1681: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1683: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1684: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1687: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1704: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1716: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1722: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1747: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2624: Test failed: LoadImage() failed with 0. cursoricon.c:2624: Test failed: LoadImage() failed with 0. === w1064 (64 bit cursoricon) === cursoricon.c:1438: Test failed: Create cursor failed. cursoricon.c:1443: Test failed: GetIconInfo() failed. cursoricon.c:1445: Test failed: Last error: 1402 cursoricon.c:1460: Test failed: DestroyCursor() failed. cursoricon.c:1462: Test failed: Last error: 1402 cursoricon.c:1595: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1602: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1603: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1604: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1610: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1622: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1628: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1637: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1639: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1640: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1643: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1662: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1668: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1674: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1681: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1683: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1684: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1687: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1704: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1716: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1722: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1733: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1474: Test failed: GetIconInfo() failed cursoricon.c:1735: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1736: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1739: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1747: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2624: Test failed: LoadImage() failed with 0. cursoricon.c:2624: Test failed: LoadImage() failed with 0.

May 31, 2016

Re: [PATCH 2/5] wined3d: Implement pure integer vertex attributes.

by Józef Kucia

On Tue, May 31, 2016 at 12:04 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 30 May 2016 at 14:24, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> + if (stream_info->use_pure_integers >> + && (element->format->flags[WINED3D_GL_RES_TYPE_BUFFER] & WINED3DFMT_FLAG_INTEGER)) >> + { >> + GL_EXTCALL(glVertexAttribIPointer(i, element->format->gl_vtx_format, element->format->gl_vtx_type, >> + element->stride, element->data.addr + state->load_base_vertex_index * element->stride)); >> + } >> + else >> + { >> + GL_EXTCALL(glVertexAttribPointer(i, element->format->gl_vtx_format, element->format->gl_vtx_type, >> + element->format->gl_normalized, element->stride, >> + element->data.addr + state->load_base_vertex_index * element->stride)); >> + } > stream_info->use_pure_integers strikes me more as a property of the > shader. I.e., if you replaced it with something like "state->vs && > state->vs->reg_maps.shader_version.major >= 4", would anything of > value be lost? True, nothing would be lost.

May 31, 2016

Re: [PATCH 2/5] wined3d: Implement pure integer vertex attributes.

by Henri Verbeet

On 30 May 2016 at 14:24, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (stream_info->use_pure_integers > + && (element->format->flags[WINED3D_GL_RES_TYPE_BUFFER] & WINED3DFMT_FLAG_INTEGER)) > + { > + GL_EXTCALL(glVertexAttribIPointer(i, element->format->gl_vtx_format, element->format->gl_vtx_type, > + element->stride, element->data.addr + state->load_base_vertex_index * element->stride)); > + } > + else > + { > + GL_EXTCALL(glVertexAttribPointer(i, element->format->gl_vtx_format, element->format->gl_vtx_type, > + element->format->gl_normalized, element->stride, > + element->data.addr + state->load_base_vertex_index * element->stride)); > + } stream_info->use_pure_integers strikes me more as a property of the shader. I.e., if you replaced it with something like "state->vs && state->vs->reg_maps.shader_version.major >= 4", would anything of value be lost?

May 31, 2016

Re: [PATCH] d3dx9: Improve performance and memory usage in preshader constants setting.

by Paul Gofman

On 05/31/2016 12:24 AM, Matteo Bruni wrote: > >> +struct d3dx_const_copy_state > I'm not entirely happy with the name, maybe > d3dx_const_param_eval_output or something in that fashion? I will rename to d3dx_const_param_eval_output. > >> unsigned int out; >> + unsigned int *in = (unsigned int *)param->data + set_state.param_offset + j; >> + switch (table_info[set_state.table].type) >> + { >> + case PRES_VT_FLOAT: set_number(&out, D3DXPT_FLOAT, in, param->type); break; >> + case PRES_VT_INT: set_number(&out, D3DXPT_INT, in, param->type); break; >> + case PRES_VT_BOOL: set_number(&out, D3DXPT_BOOL, in, param->type); break; >> + default: >> + FIXME("Unexpected type %#x.\n", table_info[set_state.table].type); >> + break; >> + } >> + regstore_set_values(rs, set_state.table, &out, set_state.table_offset + j, 1); >> + } >> + } >> + set_state.param_offset += count; >> + set_state.table_offset += count; >> + break; >> + } >> + } >> + } >> +} > This seems overly complicated and fragile. > Instead of this kind of "5 instructions bytecode" isn't it easier to > just store and then lookup a struct with all the info you need? Keeping a struct with offsets & count altogether is of course more straightforward, but I intentionally did it this way to save a lot of extra space and to introduce an easier coalescing. When there is a matrix transpose involved (which happens quite often in real apps as far as I have seen) the whole structure would be duplicated for every matrix element. In the current approach each element for transposed matrix has just one offset (destination offset changes sequentially and does not come to the array for each matrix element) and one count of 1. The other way to optimize this is to introduce a separate operation for transposed matrix copy, but will it really be simpler or nicer than it is now? Current approach is indeed a sort of encoding the data copy into a very simple bytecode. Keeping the whole struct and optimizing as a separate op for matrix transpose would be the same in principle, but I am afraid will result in a bit more code and a bit more mess as there will be more cases to handle. I thought the current approach is simpler as the data copy is encoded in a generic and simple way so on the actual copy I do not have to care for any specifics of initial parameter & constant layout, as well as in process of extending the array & coalescing. > I > guess the end result would be something akin to storing an array of > struct d3dx_const_copy_state in place of struct d3dx_const_param_set. > I don't know how the code would exactly look like but I would start by > moving building all the struct d3dx_const_copy_param to init time. I am not sure I understand what you mean here, could you please clarify? In the variant currently suggested the whole building of structure responsible for parameter copy is already done solely at init time. Shader/preshader full constant structure is not stored anymore. There is still an array of parameters and constant description left which is currently used in effect.c code for setting sampler states. This could easily be optimized further by not storing the parameters other than samplers and storing just register index instead of the whole constant descs for them, but this looked as a separate step to me not fully related to this patch. Or probably I am misunderstanding your point here. > BTW > the coalescing you currently do in add_const_set() could be > potentially done as a separate pass after you generate all the > "d3dx_const_copy_state-like" structures (but still at init time), > which might be simpler. It can be done as a separate pass, but why? In my understanding it will result just in bigger intermediate array and a few more lines of code. I will need to do all the same but not at once when getting an "copy request" but from scanning the pre-stored array. Or am I missing something? > Whitespace. >> @@ -931,21 +1107,17 @@ static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_t >> major_stride = max(minor, table_info[table].reg_component_count); >> n = min(major * major_stride, >> desc.RegisterCount * table_info[table].reg_component_count + major_stride - 1) / major_stride; >> + >> for (i = 0; i < n; ++i) >> { >> for (j = 0; j < minor; ++j) >> { >> - unsigned int out; >> - unsigned int *in; >> unsigned int offset; >> >> offset = start_offset + i * major_stride + j; >> - if (offset / table_info[table].reg_component_count >= rs->table_sizes[table]) >> - { >> - if (table_info[table].reg_component_count != 1) >> - FIXME("Output offset exceeds table size, name %s, component %u.\n", desc.Name, i); >> + if ((offset - start_offset) / table_info[table].reg_component_count >= desc.RegisterCount) >> break; > Maybe keeping a WARN or something makes sense here? > This break is just normal for boolean register set (it is covered by test case) and should not happen for vec4 register sets. This is because the inner loop can never be bound by desc.RegisterCount for vec4 registers (as nminor <= 4 and limiting just outer 'n' loop counter is sufficient), but can be bound for boolean single value registers. I will get it back in the same way it was before (FIXME for vec4 register sets and nothing for boolean).

May 31, 2016

Broken AppDB Test Results Pages

by Jimi Huotari

Greetings! I sent two mails about this to appdb(a)winehq.org the other day, but austin987 suggested I'll mail here (and Cc jnewman), too, since it has been a few days now. So I broke a couple of pages: //appdb.winehq.org/objectManager.php?sClass=version&iId=24670 //appdb.winehq.org/objectManager.php?sClass=version&iId=24695 Using QupZilla (QtWebEngine edition), the Xinha editor took its built-in ad-block rules, with some of the style code, and included them in the code for the page, which breaks most of it (none of the test results or notes/comments\bugs show up). Loading up the form at AppDB resulted into a count of HTML: 259501, and this number goes up by about the same amount every time the form is reloaded, and (probably) all of it will be included in the code. It would be great if someone with the power to do so could undo my edits to the two pages I mentioned, as I can't do anything about it myself. :] I already reported the issue upstream of QupZilla, and a fix was quickly put in place there, but the editor itself remains vulnerable (no idea how big of an annoyance /really/ exploiting it could become). Thank you, and apologies for the inconvenience!

May 31, 2016

Re: [PATCH] msi: Use special errorctrl-flag for CreateService

by Hans Leidekker

On Sun, 2016-05-29 at 23:07 +0200, Andreas Maier wrote: > diff --git a/dlls/msi/action.c b/dlls/msi/action.c > index 370007c..5675900 100644 > --- a/dlls/msi/action.c > +++ b/dlls/msi/action.c > @@ -5811,6 +5811,7 @@ static UINT ITERATE_InstallService(MSIRECORD *rec, LPVOID param) > LPWSTR name = NULL, disp = NULL, load_order = NULL, serv_name = NULL; > LPWSTR depends = NULL, pass = NULL, args = NULL, image_path = NULL; > DWORD serv_type, start_type, err_control; > + BOOL can_fail; 'is_vital' would be better. > SERVICE_DESCRIPTIONW sd = {NULL}; > UINT ret = ERROR_SUCCESS; > > @@ -5848,6 +5849,13 @@ static UINT ITERATE_InstallService(MSIRECORD *rec, LPVOID param) > deformat_string(package, MSI_RecordGetString(rec, 10), &pass); > deformat_string(package, MSI_RecordGetString(rec, 11), &args); > deformat_string(package, MSI_RecordGetString(rec, 13), &sd.lpDescription); > + > + /* Should the complete install fail if CreateService fails? */ > + can_fail = (err_control && msidbServiceInstallErrorControlVital >= 0); This can't work. You want: is_vital = (err_control & msidbServiceInstallErrorControlVital); > + /* Remove the msidbServiceInstallErrorControlVital-flag from err_control. > + CreateService (under Windows) would fail if not. */ > + err_control &= ~msidbServiceInstallErrorControlVital; > > /* fetch the service path */ > row = MSI_QueryGetRecord(package->db, query, comp); > @@ -5890,7 +5898,12 @@ static UINT ITERATE_InstallService(MSIRECORD *rec, LPVOID param) > if (!service) > { > if (GetLastError() != ERROR_SERVICE_EXISTS) > + { > ERR("Failed to create service %s: %d\n", debugstr_w(name), GetLastError()); > + if (can_fail) > + return ERROR_INSTALL_FAILURE; While you're at it, this ERR should be a WARN.

May 31, 2016

Re: [PATCH] d3dx9: Improve performance and memory usage in preshader constants setting.

by Matteo Bruni

2016-05-26 20:28 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/d3dx9_private.h | 25 +++- > dlls/d3dx9_36/preshader.c | 259 +++++++++++++++++++++++++++++++++++------- > 2 files changed, 237 insertions(+), 47 deletions(-) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index 9938d83..970ef2f 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -129,14 +129,33 @@ enum pres_reg_tables > PRES_REGTAB_FIRST_SHADER = PRES_REGTAB_CONST, > }; > > +enum const_param_copy_state_type > +{ > + COPY_STATE_TYPE_PARAM, > + COPY_STATE_TYPE_TABLE, > + COPY_STATE_TYPE_PARAM_OFFSET, > + COPY_STATE_TYPE_TABLE_OFFSET, > + COPY_STATE_TYPE_COPY_COUNT The name of the last enumerator is a bit ambiguous (it might be mistaken to be a _COUNT entry == last actual enumerator + 1). I would either change the name a bit or move it from the last place. Although this might be moot, see below. > +struct d3dx_const_copy_state I'm not entirely happy with the name, maybe d3dx_const_param_eval_output or something in that fashion? > @@ -811,10 +820,10 @@ static void d3dx_free_const_tab(struct d3dx_const_tab *ctab) > { > HeapFree(GetProcessHeap(), 0, ctab->inputs); > HeapFree(GetProcessHeap(), 0, ctab->inputs_param); > - if (ctab->ctab) > - ID3DXConstantTable_Release(ctab->ctab); > + HeapFree(GetProcessHeap(), 0, ctab->const_set); > } > > + > static void d3dx_free_preshader(struct d3dx_preshader *pres) That extra blank line doesn't seem necessary. > @@ -835,14 +844,181 @@ void d3dx_free_param_eval(struct d3dx_param_eval *peval) > HeapFree(GetProcessHeap(), 0, peval); > } > > -static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, > - D3DXHANDLE hc, struct d3dx_parameter *param) > +static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab) > +{ > + unsigned int i; > + struct d3dx_const_copy_state set_state; > + > + memset(&set_state, 0, sizeof(set_state)); > + for (i = 0; i < const_tab->const_set_count; ++i) > + { > + switch (const_tab->const_set[i].copy_state_type) > + { > + case COPY_STATE_TYPE_PARAM: > + set_state.param = const_tab->const_set[i].state_change.param; > + break; > + case COPY_STATE_TYPE_TABLE: > + set_state.table = const_tab->const_set[i].state_change.value; > + break; > + case COPY_STATE_TYPE_PARAM_OFFSET: > + set_state.param_offset = const_tab->const_set[i].state_change.value; > + break; > + case COPY_STATE_TYPE_TABLE_OFFSET: > + set_state.table_offset = const_tab->const_set[i].state_change.value; > + break; > + case COPY_STATE_TYPE_COPY_COUNT: > + { > + unsigned int count; > + struct d3dx_parameter *param; > + enum pres_value_type table_type; > + unsigned int j; > + > + count = const_tab->const_set[i].state_change.value; > + param = set_state.param; > + table_type = table_info[set_state.table].type; > + if ((set_state.table_offset + count - 1) / table_info[set_state.table].reg_component_count > + >= rs->table_sizes[set_state.table]) > + { > + FIXME("Insufficient table space allocated.\n"); > + break; > + } > + if ((param->type == D3DXPT_FLOAT && table_type == PRES_VT_FLOAT) > + || (param->type == D3DXPT_INT && table_type == PRES_VT_INT) > + || (param->type == D3DXPT_BOOL && table_type == PRES_VT_BOOL)) > + { > + regstore_set_values(rs, set_state.table, (unsigned int *)param->data + set_state.param_offset, > + set_state.table_offset, count); > + } > + else > + { > + for (j = 0; j < count; ++j) > + { > + unsigned int out; > + unsigned int *in = (unsigned int *)param->data + set_state.param_offset + j; > + switch (table_info[set_state.table].type) > + { > + case PRES_VT_FLOAT: set_number(&out, D3DXPT_FLOAT, in, param->type); break; > + case PRES_VT_INT: set_number(&out, D3DXPT_INT, in, param->type); break; > + case PRES_VT_BOOL: set_number(&out, D3DXPT_BOOL, in, param->type); break; > + default: > + FIXME("Unexpected type %#x.\n", table_info[set_state.table].type); > + break; > + } > + regstore_set_values(rs, set_state.table, &out, set_state.table_offset + j, 1); > + } > + } > + set_state.param_offset += count; > + set_state.table_offset += count; > + break; > + } > + } > + } > +} This seems overly complicated and fragile. Instead of this kind of "5 instructions bytecode" isn't it easier to just store and then lookup a struct with all the info you need? I guess the end result would be something akin to storing an array of struct d3dx_const_copy_state in place of struct d3dx_const_param_set. I don't know how the code would exactly look like but I would start by moving building all the struct d3dx_const_copy_param to init time. BTW the coalescing you currently do in add_const_set() could be potentially done as a separate pass after you generate all the "d3dx_const_copy_state-like" structures (but still at init time), which might be simpler. Does this make sense? Am I missing something? > +static HRESULT add_const_set_value(struct d3dx_const_tab *const_tab, unsigned int value, > + unsigned int *current_value, enum const_param_copy_state_type type) > +{ > + struct d3dx_const_param_set set; > + HRESULT hr; > + > + if (*current_value != value) > + { > + *current_value = value; > + set.copy_state_type = type; > + set.state_change.value = value; > + if (FAILED(hr=append_const_set(const_tab, &set))) Whitespace. > @@ -931,21 +1107,17 @@ static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_t > major_stride = max(minor, table_info[table].reg_component_count); > n = min(major * major_stride, > desc.RegisterCount * table_info[table].reg_component_count + major_stride - 1) / major_stride; > + > for (i = 0; i < n; ++i) > { > for (j = 0; j < minor; ++j) > { > - unsigned int out; > - unsigned int *in; > unsigned int offset; > > offset = start_offset + i * major_stride + j; > - if (offset / table_info[table].reg_component_count >= rs->table_sizes[table]) > - { > - if (table_info[table].reg_component_count != 1) > - FIXME("Output offset exceeds table size, name %s, component %u.\n", desc.Name, i); > + if ((offset - start_offset) / table_info[table].reg_component_count >= desc.RegisterCount) > break; Maybe keeping a WARN or something makes sense here?

May 30, 2016

Re: [v3 1/2] d3dx9: Implement IsParameterUsed function in effect.

by Matteo Bruni

2016-05-26 20:18 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static BOOL walk_parameter_dep(struct d3dx_parameter *param, walk_parameter_dep_func param_func, > + void *data); > + > +static BOOL walk_param_eval_dep(struct d3dx_param_eval *param_eval, walk_parameter_dep_func param_func, > + void *data) > +{ Depending on what you will do with the other planned use, it might make sense to specialize these functions for the only use case you have at the moment, simplifying (e.g. dropping the callback) and renaming (e.g. is_param_eval_param_used() - a name that shows what you expect from these functions) them in the process.

May 30, 2016

Re: CSMT

by Bruno Jesus

On Mon, May 30, 2016 at 1:51 PM, Snorri Sturluson <snorri.sturluson(a)ccpgames.com> wrote: > I’m experimenting with the CSMT (Commandstream multithreading) feature in > wine-staging for improved graphic performance in EVE when running on Mac. > > My initial tests are promising in performance aspect, but unfortunately > parts of the scene are flickering in and out. Has anyone seen anything > similar? Anyone have any pointers on what I should look for to fix this? At least 2 different bugs talk about flickering and CSMT, until now there is no know solution. https://bugs.winehq.org/show_bug.cgi?id=40275 https://bugs.winehq.org/show_bug.cgi?id=39351 Best Regards, Bruno

May 30, 2016

CSMT

by Snorri Sturluson

I'm experimenting with the CSMT (Commandstream multithreading) feature in wine-staging for improved graphic performance in EVE when running on Mac. My initial tests are promising in performance aspect, but unfortunately parts of the scene are flickering in and out. Has anyone seen anything similar? Anyone have any pointers on what I should look for to fix this? /Snorri Sturluson

May 30, 2016

Re: [PATCH 1/5] d3d11: Validate offsets and sizes in parse_dxbc() (AFL).

by Michael Stefaniuc

Hello Henri, I see you marked a couple of patches with "(AFL)". What tool is that? Marcus mentioned it might be the AFL fuzzer http://lcamtuf.coredump.cx/afl/ thanks bye michael

May 30, 2016

Re: [PATCH 1/2] include: Add ID3D10InfoQueue interface

by Henri Verbeet

As a general comment, please follow the style of the other Direct3D code. On 27 May 2016 at 10:07, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +import "oaidl.idl"; > +import "ocidl.idl"; > +import "d3d10.idl"; This doesn't match my version of the SDK headers, what version is this supposed to match?

May 30, 2016

Re: d3dxof: Spelling fixes.

by Henri Verbeet

On 29 May 2016 at 12:42, Francois Gouget <fgouget(a)free.fr> wrote: > @@ -748,7 +748,7 @@ static WORD parse_TOKEN(parse_buffer * buf) > { > buf->list_nb_elements--; > buf->list_separator = FALSE; > - /* Insert separarator between each values and since list does not accept separator at the end > + /* Insert separator between each value, and since list does not accept separator at the end > use a comma so any extra separator will generate an error */ > token = TOKEN_COMMA; > } > @@ -761,7 +761,7 @@ static WORD parse_TOKEN(parse_buffer * buf) > *(DWORD*)buf->value = value; > > buf->list_separator = TRUE; > - /* Convert list into a serie of their basic type counterpart */ > + /* Convert list into a series of their basic type counterpart */ > token = buf->list_type_float ? TOKEN_FLOAT : TOKEN_INTEGER; > } > dump_TOKEN(token); Not to hold it against the patch too much, but there's a lot more wrong there than just the spelling.

May 30, 2016

Re: imm32, user32: Create and destroy the default IME window implicitly. (try 3) (resend)

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > On Fri, 27 May 2016 12:39:27 +0900, Alexandre Julliard wrote: >> Do you have a test showing that this is supposed to happen between >> WM_NCCREATE and WM_NCCALCSIZE? If not, I think it would be useful to >> add one. > Yes. I wrote a patch [1/5] showing that the IME window is created > between WM_NCCREATE and WM_NCCALCSIZE. Thanks! >> Also since the window class is in user32 now the window >> creation could probably happen there too. > Regarding window creation, I think imm32 is better. Because imm32 has > ImmDisableIME API. It affects IME window creation as seen in patch [5/5]. > If I implement the API, its settings will be stored in IMMThreadData, > and it will be referred on window creation. So, creating the IME window > in imm32 makes sense. OK, in that case I'd say the other checks (system metrics, class name, refcount) should all be in imm32 too. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2016

Re: imm32, user32: Create and destroy the default IME window implicitly. (try 3) (resend)

by Akihiro Sagawa

On Fri, 27 May 2016 12:39:27 +0900, Alexandre Julliard wrote: > Do you have a test showing that this is supposed to happen between > WM_NCCREATE and WM_NCCALCSIZE? If not, I think it would be useful to > add one. Yes. I wrote a patch [1/5] showing that the IME window is created between WM_NCCREATE and WM_NCCALCSIZE. > Also since the window class is in user32 now the window > creation could probably happen there too. Regarding window creation, I think imm32 is better. Because imm32 has ImmDisableIME API. It affects IME window creation as seen in patch [5/5]. If I implement the API, its settings will be stored in IMMThreadData, and it will be referred on window creation. So, creating the IME window in imm32 makes sense. I also sent a patch showing some case behaviors: - Patch [2/5] tests when the first window of a thread is a child window. - Patch [3/5] tests when WM_CREATE returns -1. Thanks for reviewing. Akihiro Sagawa

May 29, 2016

Re: [PATCH] kernel32/tests: Fix a leak in tests (Valgrind)

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=23231 Your paranoid android. === w1064 (32 bit locale) === locale.c:2367: Test failed: LCMapStringEx should fail with bad locale name locale.c:2368: Test failed: unexpected error code -559038737 locale.c:2459: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4189: Test failed: IsValidLocaleName should have failed locale.c:4191: Test failed: IsValidLocaleName should have failed locale.c:4558: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4560: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2367: Test failed: LCMapStringEx should fail with bad locale name locale.c:2368: Test failed: unexpected error code -559038737 locale.c:2459: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4189: Test failed: IsValidLocaleName should have failed locale.c:4191: Test failed: IsValidLocaleName should have failed locale.c:4558: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4560: Test failed: For id 7, Expected IVC, got ''

May 29, 2016

Re: ddraw/tests: A spelling fix for a d3d 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=23226 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

May 29, 2016

Re: d3d9/tests: Fix a trailing ok() '\n'.

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=23225 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 29, 2016

Re: setupapi: Add stub for setupapi.dll.CM_Get_DevNode_Status

by André Hentschel

Am 28.05.2016 um 15:55 schrieb Rob Walker: > Fixes https://bugs.winehq.org/show_bug.cgi?id=40691 The Ex function is wrong, have a look at msdn

May 28, 2016

AW: setupapi: Add stub for setupapi.dll.CM_Get_DevNode_Status

by siro＠das-labor.org

Sent from BlackBerry Z30mcfmrrmf Originalnachricht Von: Rob Walker ef Cm f fmrc Fmrrrfmcfmf J efmf‎ Gesendet: Samstag, 28. Mai 2016 15:56 An: wine-patches R‎ Antwort an: wine-devel(a)winehq.org Betreff: setupapi: Add stub for setupapi.dll.CM_Get_DevNode_Stmcv Fcmmcfvefgermfrrfcm rrfmr Fmatus Ff 4M fete c‎ Ec Fixes https://bugs.winehq.org/show_bug.cgi?id=40691 The application launches cleanly without a backtrace dialog generated by FabCheck.exe (which calls CM_Get_DevNode_Status). Tested on Gentoo Linux (wine - without staging patches). Signed-off-by: Rob Walker <bob.mt.wya(a)gmail.com> --- dlls/cfgmgr32/cfgmgr32.spec | 4 ++-- dlls/setupapi/setupapi.spec | 4 ++-- dlls/setupapi/stubs.c | 20 ++++++++++++++++++++ 3 files changed, 24 insertions(+), 4 deletions(-) diff --git a/dlls/cfgmgr32/cfgmgr32.spec b/dlls/cfgmgr32/cfgmgr32.spec index f442157..b6e73ac 100644 --- a/dlls/cfgmgr32/cfgmgr32.spec +++ b/dlls/cfgmgr32/cfgmgr32.spec @@ -60,8 +60,8 @@ @ stdcall CM_Get_DevNode_Registry_PropertyW(long long ptr ptr long long) setupapi.CM_Get_DevNode_Registry_PropertyW @ stdcall CM_Get_DevNode_Registry_Property_ExA(long long ptr ptr ptr long ptr) setupapi.CM_Get_DevNode_Registry_Property_ExA @ stdcall CM_Get_DevNode_Registry_Property_ExW(long long ptr ptr ptr long ptr) setupapi.CM_Get_DevNode_Registry_Property_ExW -@ stub CM_Get_DevNode_Status -@ stub CM_Get_DevNode_Status_Ex +@ stdcall CM_Get_DevNode_Status(ptr ptr long long) setupapi.CM_Get_DevNode_Status +@ stdcall CM_Get_DevNode_Status_Ex(ptr ptr long long) setupapi.CM_Get_DevNode_Status_Ex @ stdcall CM_Get_Device_IDA(ptr ptr long long) setupapi.CM_Get_Device_IDA @ stdcall CM_Get_Device_IDW(ptr ptr long long) setupapi.CM_Get_Device_IDW @ stdcall CM_Get_Device_ID_ExA(ptr ptr long long ptr) setupapi.CM_Get_Device_ID_ExA diff --git a/dlls/setupapi/setupapi.spec b/dlls/setupapi/setupapi.spec index 9bfaadd..a336fc2 100644 --- a/dlls/setupapi/setupapi.spec +++ b/dlls/setupapi/setupapi.spec @@ -71,8 +71,8 @@ @ stdcall CM_Get_DevNode_Registry_PropertyW(long long ptr ptr long long) @ stdcall CM_Get_DevNode_Registry_Property_ExA(long long ptr ptr ptr long ptr) @ stdcall CM_Get_DevNode_Registry_Property_ExW(long long ptr ptr ptr long ptr) -@ stub CM_Get_DevNode_Status -@ stub CM_Get_DevNode_Status_Ex +@ stdcall CM_Get_DevNode_Status(ptr ptr long long) +@ stdcall CM_Get_DevNode_Status_Ex(ptr ptr long long) @ stdcall CM_Get_Device_IDA(ptr ptr long long) @ stdcall CM_Get_Device_IDW(ptr ptr long long) @ stdcall CM_Get_Device_ID_ExA(ptr ptr long long ptr) diff --git a/dlls/setupapi/stubs.c b/dlls/setupapi/stubs.c index ffc766b..e315ea9 100644 --- a/dlls/setupapi/stubs.c +++ b/dlls/setupapi/stubs.c @@ -419,6 +419,26 @@ CONFIGRET WINAPI CM_Get_DevNode_Registry_PropertyW(DEVINST dev, ULONG prop, PULO } /*********************************************************************** + * CM_Get_DevNode_Status (SETUPAPI.@) + */ +CONFIGRET WINAPI CM_Get_DevNode_Status(PULONG pulStatus, PULONG pulProblemNumber, DEVINST dnDevInst, + ULONG ulFlags) +{ + FIXME("%p %p 0x%08x 0x%08x: stub\n", pulStatus, pulProblemNumber, dnDevInst, ulFlags); + return CR_FAILURE; +} + +/*********************************************************************** + * CM_Get_DevNode_Status_Ex (SETUPAPI.@) + */ +CONFIGRET WINAPI CM_Get_DevNode_Status_Ex(PULONG pulStatus, PULONG pulProblemNumber, DEVINST dnDevInst, + ULONG ulFlags) +{ + FIXME("%p %p 0x%08x 0x%08x: stub\n", pulStatus, pulProblemNumber, dnDevInst, ulFlags); + return CR_FAILURE; +} + +/*********************************************************************** * CM_Enumerate_Classes (SETUPAPI.@) */ CONFIGRET WINAPI CM_Enumerate_Classes(ULONG index, LPGUID class, ULONG flags) -- 2.8.3

May 28, 2016

Re: [PATCH] comctl32: Use SetRect() instead of open coding it.

by Nikolay Sivov

if (dis->itemAction & ODA_FOCUS) { - rect.left = xbase + xioff - 1; - rect.right = rect.left + txtsize.cx + 2; - rect.top = dis->rcItem.top; - rect.bottom = dis->rcItem.bottom; + SetRect(&rect, xbase + xioff - 1, dis->rcItem.top, rect.left + txtsize.cx + 2, dis->rcItem.bottom); DrawFocusRect(dis->hDC, &rect); } This change is obviously wrong. I think it's better to leave this one as is.

May 28, 2016

Re: [PATCH 2/3] msctf: Added Push/Pop context tests.

by Jacek Caban

On 05/27/2016 04:46 PM, Marvin wrote: > 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=23219 > > Your paranoid android. > > > === w1064 (32 bit inputprocessor) === > inputprocessor.c:834: Test failed: Deactivation came unexpectedly It's an already existing failure. Jacek

May 27, 2016

Re: [PATCH 3/3] msctf: Fixed ref counts in 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://testbot.winehq.org/JobDetails.pl?Key=23220 Your paranoid android. === w1064 (64 bit inputprocessor) === inputprocessor.c:834: Test failed: Deactivation came unexpectedly

May 27, 2016

Re: [PATCH 2/3] msctf: Added Push/Pop context 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://testbot.winehq.org/JobDetails.pl?Key=23219 Your paranoid android. === w1064 (32 bit inputprocessor) === inputprocessor.c:834: Test failed: Deactivation came unexpectedly

May 27, 2016

Re: imm32, user32: Create and destroy the default IME window implicitly. (try 3) (resend)

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > + /* create default IME window */ > + > + if (imm_register_window && needs_ime_window( hwnd )) > + { > + struct user_thread_info *thread_info = get_user_thread_info(); > + thread_info->ime_win_refs++; > + TRACE("ime_win_refs=%u\n", thread_info->ime_win_refs); > + if (thread_info->ime_win_refs == 1) > + { > + HWND win = imm_register_window( hwnd ); > + TRACE("create ime window (hwnd=%p)\n", win); > + } > + } > + > /* send WM_NCCALCSIZE */ Do you have a test showing that this is supposed to happen between WM_NCCREATE and WM_NCCALCSIZE? If not, I think it would be useful to add one. Also since the window class is in user32 now the window creation could probably happen there too. -- Alexandre Julliard julliard(a)winehq.org

May 27, 2016

Re: [v2 3/3] d3dx9: Add test for IsParameterUsed function.

by Paul Gofman

On 05/26/2016 06:10 PM, Matteo Bruni wrote: > > You could make a small function from this and use it through. You > would check that IsParameterUsed() for the parameter gives the > expected result, then enumerate the parameter elements and members and > check that they are all unused. BTW, is there any case where > IsParameterUsed() for a child is TRUE? > None I could find so far. My initial implementation was returning TRUE for used members, I was quite surprised to find native behaviour to be different.

May 26, 2016

Re: [v2 2/3] d3dx9: Implement IsParameterUsed function in effect.

by Paul Gofman

On 05/26/2016 06:10 PM, Matteo Bruni wrote: > 2016-05-23 12:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > It looks generally good, I only have minor "complaints" (and sorry for > the delay in reviewing...). > >> --- >> dlls/d3dx9_36/effect.c | 113 +++++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 110 insertions(+), 3 deletions(-) >> >> diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c >> index 31aa2d6..cdfc494 100644 >> --- a/dlls/d3dx9_36/effect.c >> +++ b/dlls/d3dx9_36/effect.c >> @@ -3545,15 +3545,122 @@ static HRESULT WINAPI ID3DXEffectImpl_FindNextValidTechnique(ID3DXEffect* iface, >> return E_NOTIMPL; >> } >> >> +typedef BOOL (*walk_parameter_dep_func)(void *data, struct d3dx_parameter *param); >> +static BOOL walk_state_dep(struct d3dx_state *state, walk_parameter_dep_func param_func, >> + void *data); >> +static BOOL walk_param_eval_dep(struct d3dx_param_eval *param_eval, walk_parameter_dep_func param_func, >> + void *data); > I guess you intend to reuse all these functions down the line for some > other API, what are your plans? Well, I intended to reuse, but later realized that the other "walk" function I need in 'dirty' param tracking on CommitChanges implementation are quite different as walk parameter members tree and not dependencies. Now I am reusing just typedef for the tree mapped function, I will remove one prototype and move another one near to the function (I will still need one as there are recursive calls between the two functions).

May 26, 2016

Re: [v2 3/3] d3dx9: Add test for IsParameterUsed function.

by Matteo Bruni

2016-05-23 12:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 537 ++++++++++++++++++++++++++----------------- > 1 file changed, 321 insertions(+), 216 deletions(-) You forgot the "/tests" part of the patch subject prefix. > +static void test_effect_isparameterused(IDirect3DDevice9 *device) > +{ > + ID3DXEffect *effect; > + HRESULT hr; > + D3DXHANDLE param, tech, param_child; > + unsigned int i; > + > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, 0, NULL, &effect, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + tech = effect->lpVtbl->GetTechniqueByName(effect, "tech0"); > + ok(!!tech, "GetTechniqueByName failed.\n"); > + > + param = effect->lpVtbl->GetParameterByName(effect, NULL, "opvect3"); > + ok(!!param, "GetParameterByName failed.\n"); > + ok(effect->lpVtbl->IsParameterUsed(effect, param, tech), "IsParameterUsed should be TRUE for opvect3.\n"); Pretty minor but I would prefer something like ok(..., "Unexpected IsParameterUsed() result for opvect3.\n"); Same for the other IsParameterUsed() ok() calls. > + param = effect->lpVtbl->GetParameterByName(effect, NULL, "arr2"); > + ok(!!param, "GetParameterByName failed.\n"); > + ok(effect->lpVtbl->IsParameterUsed(effect, param, tech), "IsParameterUsed should be TRUE for arr2.\n"); > + for (i = 0; i < 2; ++i) > + { > + param_child = effect->lpVtbl->GetParameterElement(effect, param, i); > + ok(!!param_child, "GetParameterElement failed.\n"); > + ok(!effect->lpVtbl->IsParameterUsed(effect, param_child, tech), > + "IsParameterUsed should be FALSE for arr2[%u].\n", i); > + } You could make a small function from this and use it through. You would check that IsParameterUsed() for the parameter gives the expected result, then enumerate the parameter elements and members and check that they are all unused. BTW, is there any case where IsParameterUsed() for a child is TRUE?

May 26, 2016

Re: [v2 2/3] d3dx9: Implement IsParameterUsed function in effect.

by Matteo Bruni

2016-05-23 12:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> It looks generally good, I only have minor "complaints" (and sorry for the delay in reviewing...). > --- > dlls/d3dx9_36/effect.c | 113 +++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 110 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 31aa2d6..cdfc494 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -3545,15 +3545,122 @@ static HRESULT WINAPI ID3DXEffectImpl_FindNextValidTechnique(ID3DXEffect* iface, > return E_NOTIMPL; > } > > +typedef BOOL (*walk_parameter_dep_func)(void *data, struct d3dx_parameter *param); > +static BOOL walk_state_dep(struct d3dx_state *state, walk_parameter_dep_func param_func, > + void *data); > +static BOOL walk_param_eval_dep(struct d3dx_param_eval *param_eval, walk_parameter_dep_func param_func, > + void *data); I guess you intend to reuse all these functions down the line for some other API, what are your plans? > +static BOOL compare_param_ptr(void *param_comp, struct d3dx_parameter *param) > +{ > + return param_comp == (void *)param; I think the cast is unnecessary here. > +} > + > static BOOL WINAPI ID3DXEffectImpl_IsParameterUsed(ID3DXEffect* iface, D3DXHANDLE parameter, D3DXHANDLE technique) > { > struct ID3DXEffectImpl *effect = impl_from_ID3DXEffect(iface); > + unsigned int i, j; > struct d3dx_parameter *param = get_valid_parameter(&effect->base_effect, parameter); > + struct d3dx_technique *tech = get_valid_technique(&effect->base_effect, technique); > + struct d3dx_pass *pass; > > - FIXME("iface %p, parameter %p, technique %p stub.\n", iface, parameter, technique); > - TRACE("param %p (%s).\n", param, param ? debugstr_a(param->name) : ""); > + TRACE("iface %p, parameter %p, technique %p.\n", iface, parameter, technique); > + TRACE("param %p, name %s, tech %p.\n", param, param ? debugstr_a(param->name) : "", tech); > + if (!tech || !param) > + return FALSE; > > - return TRUE; > + for (i = 0; i < tech->pass_count; ++i) > + { > + pass = &tech->passes[i]; > + for (j = 0; j < pass->state_count; ++j) > + { > + if (walk_state_dep(&pass->states[j], compare_param_ptr, param)) > + { > + TRACE("technique %p, parameter %s, TRUE.\n", tech, param ? debugstr_a(param->name) : ""); I don't think you need to trace technique and parameter again, they are in the immediately preceding ID3DXEffectImpl_IsParameterUsed() TRACE anyway. Maybe the message could simply be "Returning TRUE.\n" or similar. > + return TRUE; > + } > + } > + } > + TRACE("technique %p, parameter %s, FALSE.\n", tech, param ? debugstr_a(param->name) : ""); Same here. > + return FALSE; > } > > static HRESULT WINAPI ID3DXEffectImpl_Begin(ID3DXEffect *iface, UINT *passes, DWORD flags) > -- > 2.5.5

May 26, 2016

Re: How to finish implementing serial port read interval timeouts?

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 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. The easiest would probably be to not try to read anything and go straight to the async call when a read interval is set. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2016

Re: [PATCH 2/2] secur32/tests: Add AcquireCredentialsHandleW tests

by Hans Leidekker

On Thu, 2016-05-26 at 08:07 +0000, Alistair Leslie-Hughes wrote: > + /* Test using the ASCI Structure. */ > + idA.User = (unsigned char*) test_user; > + idA.UserLength = strlen((char *) id.User); > + idA.Domain = (unsigned char *) workgroup; > + idA.DomainLength = strlen((char *) id.Domain); > + idA.Password = (unsigned char*) test_pass; > + idA.PasswordLength = strlen((char *) id.Password); > + idA.Flags = SEC_WINNT_AUTH_IDENTITY_ANSI; id.User, id.Domain and id.Password are Unicode strings.

May 26, 2016

Re: [PATCH 1/2] secur32: Fix handling of ANSI NTLM credentials

by Hans Leidekker

On Thu, 2016-05-26 at 08:07 +0000, Alistair Leslie-Hughes wrote: > --- a/dlls/secur32/ntlm.c > +++ b/dlls/secur32/ntlm.c > @@ -174,27 +174,74 @@ SECURITY_STATUS SEC_ENTRY ntlm_AcquireCredentialsHandleW( > if(pAuthData != NULL) > { > PSEC_WINNT_AUTH_IDENTITY_W auth_data = pAuthData; > + LPWSTR domain = NULL, user = NULL, password = NULL; > + int domain_len = 0, user_len = 0, password_len = 0; > > - TRACE("Username is %s\n", debugstr_wn(auth_data->User, auth_data->UserLength)); > - TRACE("Domain name is %s\n", debugstr_wn(auth_data->Domain, auth_data->DomainLength)); > + if (auth_data->Flags & SEC_WINNT_AUTH_IDENTITY_ANSI) > + { > + if (auth_data->DomainLength) > + { > + domain_len = MultiByteToWideChar(CP_ACP, 0, (char *)auth_data->Domain, > + auth_data->DomainLength, NULL, 0); > + domain = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR) * domain_len); > + MultiByteToWideChar(CP_ACP, 0, (char *)auth_data->Domain, auth_data->DomainLength, > + domain, domain_len); Please check the result of HeapAlloc calls.

May 26, 2016

Re: [PATCH 7/8] d3d11/tests: Add test for SM4 breakc instruction.

by Henri Verbeet

On 25 May 2016 at 10:51, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + static const DWORD ps_breakc_nz_code[] = > + { > +#if 0 > + uint bits; > + > + float4 main() : SV_TARGET > + { > + uint counter = 0; > + > + for (uint i = 0; i < 255; ++i) > + ++counter; > + > + if (counter == 255) > + return float4(0.0f, 1.0f, 0.0f, 1.0f); > + else > + return float4(1.0f, 0.0f, 0.0f, 1.0f); > + } > +#endif It's pretty minor, but "bits" is unused. I'll also note that a sufficiently smart compiler could optimise the shader down to "return float4(0.0f, 1.0f, 0.0f, 1.0f);", although clearly the current version hasn't.

May 25, 2016

Re: [PATCH 2/2] d3d10core/test: Added DXGI_FORMAT_R16_TYPELESS D3D11_BIND_DEPTH_STENCIL test

by Henri Verbeet

On 25 May 2016 at 08:06, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3d10core/tests/device.c | 1 + > 1 file changed, 1 insertion(+) > The subject line certainly has room for improvement, but otherwise this is fine.

May 25, 2016

Re: [PATCH 5/5] jscript: Added non-zero timezone offset 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://testbot.winehq.org/JobDetails.pl?Key=23195 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

May 25, 2016

Re: [PATCH 4/5] jscript: Removed obsolete FIXME comments in tests and add relevant 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://testbot.winehq.org/JobDetails.pl?Key=23194 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

May 25, 2016

Re: [PATCH 3/5] jscript: Added RegExp.global getter implementation.

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=23193 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

May 25, 2016

Re: [PATCH 2/5] jscript: Added RegExp.multiline getter implementation.

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=23192 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

May 25, 2016

Re: [PATCH 1/5] jscript: Added RegExp.ignoreCase getter implementation.

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=23191 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

May 25, 2016

Re: [PATCH 5/5] reg: Simplify syntax and help logic

by Hugh McMaster

On Tuesday, 24 May 2016 11:35 PM, Alexandre Julliard wrote: >Hugh McMaster writes: > >> @@ -907,19 +915,16 @@ int wmain(int argc, WCHAR *argvW[]) >> return 0; >> } >> >> + option_help = (!lstrcmpW(argvW[2], slashHelpW) || !lstrcmpiW(argvW[2], slashHW)); > >You should check argc first. Ah, yes, I missed that. >> - if (argc < 3) >> - { >> - output_message(STRING_INVALID_SYNTAX); >> - output_message(STRING_FUNC_HELP, struprW(argvW[1])); >> - return 1; >> - } >> - else if (argc == 3 && (!lstrcmpW(argvW[2], slashHelpW) || >> - !lstrcmpiW(argvW[2], slashHW))) >> + if (argc < 3 || (argc > 3 && option_help)) >> + return invalid_syntax(argvW[1]); >> + else if (option_help) >> { > >This doesn't feel like much of an improvement. You could probably come >up with more useful helper functions. Ideally, I'd like to move all of that logic out of the 'if' block string comparisons. One major issue I see is that users may pass invalid operation names, e.g. abc, so we need to ensure that we only continue with valid strings. I believe this will also cause problems when functions like sane_path() are moved into wmain() as well, so it's better to deal with this now. One solution is to iterate over an array of WCHAR * and return a BOOL indicating whether the string is valid or not. As for passing output_message() the correct help string ID, leaving that code where it is now is probably best, particularly if I can use the BOOL option_help. If not, we'd have to look up the message ID information in a function or a struct. I'm not if you think this change would have any benefit.

May 25, 2016

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v5)

by Aaryaman Vasishta

On Tue, May 24, 2016 at 8:32 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 24 May 2016 at 16:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > Hi, > > > > Now that the first 5 patches in the series are committed, I was > wondering if > > there's any changes required in this patch (and 7/7) ? > > > Possibly, but this one is a bit more complicated than the 5 that came > before, and I haven't reviewed it in detail yet. > Sure, I will wait for your review :) Cheers, Aaryaman

May 24, 2016

Re: [PATCH] jscript: Date.parse: make "UTC"/"GMT" optional before the timezone offset

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

May 24, 2016

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v5)

by Henri Verbeet

On 24 May 2016 at 16:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > Hi, > > Now that the first 5 patches in the series are committed, I was wondering if > there's any changes required in this patch (and 7/7) ? > Possibly, but this one is a bit more complicated than the 5 that came before, and I haven't reviewed it in detail yet.

May 24, 2016

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v5)

by Aaryaman Vasishta

Hi, Now that the first 5 patches in the series are committed, I was wondering if there's any changes required in this patch (and 7/7) ? Cheers, Aaryaman On Mon, May 23, 2016 at 8:58 PM, Marvin <testbot(a)winehq.org> wrote: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Assigned". > > This means that the patch has been assigned to a reviewer. If the > reviewer signs off on the patch, it will be committed, otherwise > you'll receive advice on how to improve it. If you don't hear anything > after a couple of weeks, please resend the patch. >

May 24, 2016

Re: [PATCH 5/5] reg: Simplify syntax and help logic

by Alexandre Julliard

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -907,19 +915,16 @@ int wmain(int argc, WCHAR *argvW[]) > return 0; > } > > + option_help = (!lstrcmpW(argvW[2], slashHelpW) || !lstrcmpiW(argvW[2], slashHW)); You should check argc first. > - if (argc < 3) > - { > - output_message(STRING_INVALID_SYNTAX); > - output_message(STRING_FUNC_HELP, struprW(argvW[1])); > - return 1; > - } > - else if (argc == 3 && (!lstrcmpW(argvW[2], slashHelpW) || > - !lstrcmpiW(argvW[2], slashHW))) > + if (argc < 3 || (argc > 3 && option_help)) > + return invalid_syntax(argvW[1]); > + else if (option_help) > { This doesn't feel like much of an improvement. You could probably come up with more useful helper functions. -- Alexandre Julliard julliard(a)winehq.org

May 24, 2016

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

Re: include: Fix a typo in IDirect3D9Ex method

by Henri Verbeet

On 22 May 2016 at 14:30, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > - STDMETHOD(GetAdapterLUID)(THIS_ UINT Adatper, LUID *pLUID) PURE; > + STDMETHOD(GetAdapterLUID)(THIS_ UINT Adapter, LUID *pLUID) PURE; If you're touching it anyway, "Adapter" => "adapter" and "pLUID" => "luid".

May 22, 2016

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

by Henri Verbeet

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. 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.

May 22, 2016

Re: [PATCH v2 09/12] d3d10core/tests: Add a geometry shader test.

by Henri Verbeet

On 20 May 2016 at 19:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#if 0 > +struct gs_data > +{ > + float4 pos : SV_POSITION; > + float4 color : COLOR; > +}; > + > +[maxvertexcount(4)] > +void main(point struct gs_data vin[1], inout TriangleStream<gs_data> vout) > +{ > + float offset = 0.2 * vin[0].pos.w; > + gs_data v; > + > + v.color = vin[0].color; > + > + v.pos = float4(vin[0].pos.x - offset, vin[0].pos.y - offset, vin[0].pos.z, 1.0); > + vout.Append(v); > + v.pos = float4(vin[0].pos.x - offset, vin[0].pos.y + offset, vin[0].pos.z, 1.0); > + vout.Append(v); > + v.pos = float4(vin[0].pos.x + offset, vin[0].pos.y - offset, vin[0].pos.z, 1.0); > + vout.Append(v); > + v.pos = float4(vin[0].pos.x + offset, vin[0].pos.y + offset, vin[0].pos.z, 1.0); > + vout.Append(v); > +} > +#endif > + static const DWORD gs_code[] = > + { > + 0x43425844, 0x5c14d638, 0x1089a334, 0x4103d097, 0x218e3173, 0x00000001, 0x00000428, 0x00000005, > + 0x00000034, 0x0000008c, 0x000000e0, 0x00000134, 0x000003ac, 0x46454452, 0x00000050, 0x00000000, > + 0x00000000, 0x00000000, 0x0000001c, 0x47530400, 0x00000100, 0x0000001c, 0x7263694d, 0x666f736f, > + 0x52282074, 0x4c482029, 0x53204c53, 0x65646168, 0x6f432072, 0x6c69706d, 0x31207265, 0x2e302e30, > + 0x31303031, 0x36312e31, 0x00343833, 0x4e475349, 0x0000004c, 0x00000002, 0x00000008, 0x00000038, > + 0x00000000, 0x00000001, 0x00000003, 0x00000000, 0x00000f0f, 0x00000044, 0x00000000, 0x00000000, > + 0x00000003, 0x00000001, 0x00000f0f, 0x505f5653, 0x5449534f, 0x004e4f49, 0x4f4c4f43, 0xabab0052, > + 0x4e47534f, 0x0000004c, 0x00000002, 0x00000008, 0x00000038, 0x00000000, 0x00000001, 0x00000003, > + 0x00000000, 0x0000000f, 0x00000044, 0x00000000, 0x00000000, 0x00000003, 0x00000001, 0x0000000f, > + 0x505f5653, 0x5449534f, 0x004e4f49, 0x4f4c4f43, 0xabab0052, 0x52444853, 0x00000270, 0x00020040, > + 0x0000009c, 0x05000061, 0x002010f2, 0x00000001, 0x00000000, 0x00000001, 0x0400005f, 0x002010f2, > + 0x00000001, 0x00000001, 0x02000068, 0x00000001, 0x0100085d, 0x0100285c, 0x04000067, 0x001020f2, > + 0x00000000, 0x00000001, 0x03000065, 0x001020f2, 0x00000001, 0x0200005e, 0x00000004, 0x0f000032, > + 0x00100032, 0x00000000, 0x80201ff6, 0x00000041, 0x00000000, 0x00000000, 0x00004002, 0x3e4ccccd, > + 0x3e4ccccd, 0x00000000, 0x00000000, 0x00201046, 0x00000000, 0x00000000, 0x05000036, 0x00102032, > + 0x00000000, 0x00100046, 0x00000000, 0x06000036, 0x00102042, 0x00000000, 0x0020102a, 0x00000000, > + 0x00000000, 0x05000036, 0x00102082, 0x00000000, 0x00004001, 0x3f800000, 0x06000036, 0x001020f2, > + 0x00000001, 0x00201e46, 0x00000000, 0x00000001, 0x01000013, 0x05000036, 0x00102012, 0x00000000, > + 0x0010000a, 0x00000000, 0x0e000032, 0x00100052, 0x00000000, 0x00201ff6, 0x00000000, 0x00000000, > + 0x00004002, 0x3e4ccccd, 0x00000000, 0x3e4ccccd, 0x00000000, 0x00201106, 0x00000000, 0x00000000, > + 0x05000036, 0x00102022, 0x00000000, 0x0010002a, 0x00000000, 0x06000036, 0x00102042, 0x00000000, > + 0x0020102a, 0x00000000, 0x00000000, 0x05000036, 0x00102082, 0x00000000, 0x00004001, 0x3f800000, > + 0x06000036, 0x001020f2, 0x00000001, 0x00201e46, 0x00000000, 0x00000001, 0x01000013, 0x05000036, > + 0x00102012, 0x00000000, 0x0010000a, 0x00000000, 0x05000036, 0x00102022, 0x00000000, 0x0010001a, > + 0x00000000, 0x06000036, 0x00102042, 0x00000000, 0x0020102a, 0x00000000, 0x00000000, 0x05000036, > + 0x00102082, 0x00000000, 0x00004001, 0x3f800000, 0x06000036, 0x001020f2, 0x00000001, 0x00201e46, > + 0x00000000, 0x00000001, 0x01000013, 0x05000036, 0x00102032, 0x00000000, 0x00100086, 0x00000000, > + 0x06000036, 0x00102042, 0x00000000, 0x0020102a, 0x00000000, 0x00000000, 0x05000036, 0x00102082, > + 0x00000000, 0x00004001, 0x3f800000, 0x06000036, 0x001020f2, 0x00000001, 0x00201e46, 0x00000000, > + 0x00000001, 0x01000013, 0x0100003e, 0x54415453, 0x00000074, 0x00000019, 0x00000001, 0x00000000, > + 0x00000004, 0x00000002, 0x00000000, 0x00000000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, > + 0x00000000, 0x00000000, 0x00000004, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, > + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000001, 0x00000005, 0x00000004, 0x00000000, > + 0x00000000, 0x00000000, > + }; That looks like it still contains debug info.

May 22, 2016

Re: [PATCH v3 01/12] wined3d: Alpha test emulation for core profile contexts.

by Henri Verbeet

On 20 May 2016 at 19:55, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void shader_glsl_generate_alpha_test(struct wined3d_string_buffer *buffer, > + const struct wined3d_gl_info *gl_info, enum wined3d_cmp_func alpha_func) > +{ > + /* alpha_func is the PASS condition, not the DISCARD condition. Instead of > + * flipping all the operators here, just negate the comparison below. */ > + static const char * const comparison_operator[] = > + { > + "", /* WINED3D_CMP_NEVER */ > + "<", /* WINED3D_CMP_LESS */ > + "==", /* WINED3D_CMP_EQUAL */ > + "<=", /* WINED3D_CMP_LESSEQUAL */ > + ">", /* WINED3D_CMP_GREATER */ > + "!=", /* WINED3D_CMP_NOTEQUAL */ > + ">=", /* WINED3D_CMP_GREATEREQUAL */ > + "" /* WINED3D_CMP_ALWAYS */ > + }; > + > + if (alpha_func == WINED3D_CMP_ALWAYS) > + return; > + > + if (alpha_func != WINED3D_CMP_NEVER) > + shader_addline(buffer, "if (!(%s[0].a %s alpha_test_ref))\n", > + get_fragment_output(gl_info), comparison_operator[alpha_func - WINED3D_CMP_NEVER]); > + shader_addline(buffer, " discard;\n"); > +} I'm calling this good enough for a start. In case of WINED3D_CMP_EQUAL and WINED3D_CMP_NOTEQUAL in particular there may come a point where we'll have to do a range check like for color keys though.

May 22, 2016

Re: [PATCH] d3d11: Honor render state FrontCounterClockwise.

by Józef Kucia

On Sun, May 22, 2016 at 1:32 PM, Johannes Brandstätter <jbrandst(a)2ds.eu> wrote: > This fixes geometry flickering in Unigine's Valley and Heaven bechmarks. > The user interface would at least show some parts, but using this patch > it completly vanishes as well as the credits image upon closing. > > Signed-off-by: Johannes Brandstätter <jbrandst(a)2ds.eu> > --- > dlls/d3d11/device.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3d11/device.c b/dlls/d3d11/device.c > index 7fb28ac..d54f81f 100644 > --- a/dlls/d3d11/device.c > +++ b/dlls/d3d11/device.c > @@ -808,10 +808,11 @@ static void STDMETHODCALLTYPE d3d11_immediate_context_RSSetState(ID3D11DeviceCon > > desc = &device->rasterizer_state->desc; > wined3d_device_set_render_state(device->wined3d_device, WINED3D_RS_FILLMODE, desc->FillMode); > - wined3d_device_set_render_state(device->wined3d_device, WINED3D_RS_CULLMODE, desc->CullMode); > /* glFrontFace() */ > if (desc->FrontCounterClockwise) > - FIXME("Ignoring FrontCounterClockwise %#x.\n", desc->FrontCounterClockwise); > + wined3d_device_set_render_state(device->wined3d_device, WINED3D_RS_CULLMODE, WINED3D_CULL_CCW); > + else > + wined3d_device_set_render_state(device->wined3d_device, WINED3D_RS_CULLMODE, desc->CullMode); > /* OpenGL style depth bias. */ > if (desc->DepthBias || desc->SlopeScaledDepthBias) > FIXME("Ignoring depth bias.\n"); > -- > 2.8.1 > > > This patch doesn't make sense. The FrontCounterClockwise field needs to be mapped to glFrontFace(). The best what you can get using the current wined3d API is to invert the cull mode when FrontCounterClockwise is true. if (desc->FrontCounterClockwise) { switch (desc->CullMode) { default: case D3D11_CULL_NONE: cullmode = WINED3D_CULL_NONE; break; case D3D11_CULL_FRONT: cullmode = WINED3D_CULL_CCW; break; case D3D11_CULL_BACK: cullmode = WINED3D_CULL_CW; break; } This still is not a proper solution because the front face property can be read in shaders, see the SV_IsFrontFace system-value semantic. The proper solution is to introduce a rasterizer state object in wined3d API. You could probably start with a rasterizer state object containing a single property for FrontCounterClockwise.

May 22, 2016

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

by Józef Kucia

Actually, I've written the original patch. The patch won't be necessary if we ensure that a GL texture is never allocated for the WINED3DFMT_NULL format. On Sat, May 21, 2016 at 4:17 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > My sense is that a D3DFMT_NULL texture should hever have a GL texture allocated, so going through the final else path should be ok - surface_get_texture_name returns 0, and context_attach_surface_fbo ignores the other fields if object is 0. Can you check if object is != 0 in the case where it fails, and see where the value comes from? I can imagine that the game manually calls PreLoad on a NULL texture as a possible cause. In our draw and clear code we're skipping the GL texture allocation for NULL resources. Yes, the handling of WINED3DFMT_NULL textures could be improved. We should ensure that WINED3DFMT_NULL won't ever have a GL texture allocated. In the case of CS:GO, it seems that a GL texture is allocated when a draw call is issued with the D3DFMT_NULL texture attached to the texture stage 0. If I recall correctly, this happens when the loading screen is shown. The game for some reasons iterates over a set of textures, attaches each of them to the texture stage 0 and issues a draw call with a single triangle. > If the GL texture is not 0 I expect that you get a GL error before context_set_fbo_key_for_surface is run. If it is indeed 0 and something goes wrong at a later point then my reasoning above must be wrong in some way. That's accurate. The first GL error occurs when Wine tries to allocate the texture storage by calling glTexImage2D(). The error is reported because the internal format is 0 for WINED3DFMT_NULL.

May 22, 2016

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

by Max Qian

On 2016-05-21 9:17 am, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > Hi, > > Thanks for catching this bug. You'll have to submit your patch with > your real name, and as Aaryaman stated, a signed off line. > > Am 2016-05-21 um 10:46 schrieb contrib(a)maxqia.com: >> - if (!surface) >> + if (!surface || surface->container->resource.format->id == >> WINED3DFMT_NULL) >> { >> key->objects[idx].object = 0; >> key->objects[idx].target = 0; > My sense is that a D3DFMT_NULL texture should hever have a GL texture > allocated, so going through the final else path should be ok - > surface_get_texture_name returns 0, and context_attach_surface_fbo > ignores the other fields if object is 0. Can you check if object is != > 0 in the case where it fails, and see where the value comes from? I > can imagine that the game manually calls PreLoad on a NULL texture as > a possible cause. In our draw and clear code we're skipping the GL > texture allocation for NULL resources. > > If the GL texture is not 0 I expect that you get a GL error before > context_set_fbo_key_for_surface is run. If it is indeed 0 and > something goes wrong at a later point then my reasoning above must be > wrong in some way. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXQG4IAAoJEN0/YqbEcdMwQOQP/20p3/P+Ej25ABqMh83F9l1/ > OlhCUM3BdjYxYaZacopDInmudVALgTLaQe28dlKMw181XSqQ1op9acwHXSvXkNKM > ZyvNIsqtLxenX37ZWu0I22xqV+DFU07D4TbzrQMAlgMd9XUK2713PhNVKRuYSLpS > LazcTMldRoiHOxrJF7spbAr0Nn2JPGwHV/4NA0baQdIycnVQqztFQHPmdRVSP/eO > 9zOacv0AKDaPt3GXgJV0+S7QuDW9EEsXI6nkytDJpazBnfSrJRCVQIGhPiokf9ik > dlFkwYKuZe/fSTgSfyxyB0IhQoaOsfM4LTSJymQpneADRLhbmPORORMdzFMW/GrN > qKPgK28U2oES3u3YF6u5/2YgfrSUvJvvqPe8077Tyl60uG5W7lBWeMQ4HUDaDHgW > vWcDbvX1vYh+BG5zIvvVzGvmRKoKYnnEj65iqGqpi/vcJMz2f4ff/vmAiT1y23Hl > 0Y50ZUxTWXpUVi4uzoQlKgpmXbny2je0P2K12zbA13J3kJ/LxoHqefm1RW9VJ1w4 > VxYD94lbk4zchO0AQwbLK83b7f8QoTZH2quqyzbgyFoAynXv0RDhQ2ZjtRN66Jh+ > HmFOprGcCEmOnFs9c0JS8c9MSBVc8g1i6XmnnnccO3wyaw7vrNQbNmnqPRhkpPEV > ELMYspnFGK8apZ7633Dq > =QeKV > -----END PGP SIGNATURE----- It seems like surface_get_texture_name isn't returning 0. Code Added : diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c index e741969..27f1d04 100644 --- a/dlls/wined3d/context.c +++ b/dlls/wined3d/context.c @@ -424,6 +424,12 @@ static inline void context_set_fbo_key_for_surface(const struct wined3d_context break; } } + if (key->objects[idx].object != 0 && surface->container->resource.format->id == WINED3DFMT_NULL) + ERR("WINED3DFMT_NULL object is %i at %x\n", key->objects[idx].object, location); + if (key->objects[idx].target != 0 && surface->container->resource.format->id == WINED3DFMT_NULL) + ERR("WINED3DFMT_NULL target is %i at %x\n", key->objects[idx].target, location); + if (key->objects[idx].level != 0 && surface->container->resource.format->id == WINED3DFMT_NULL) + ERR("WINED3DFMT_NULL level is %i at %x\n", key->objects[idx].level, location); } static void context_generate_fbo_key(const struct wined3d_context *context, Snippet from Console : (10 is WINED3D_LOCATION_TEXTURE_RGB) err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL object is 105 at 10 err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL target is 3553 at 10 err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL object is 105 at 10 err:d3d:context_set_fbo_key_for_surface WINED3DFMT_NULL target is 3553 at 10 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_dump_fbo_attachment GL_DEPTH_ATTACHMENT: 2d texture 104, 2048x2048, format 0x81a6. fixme:d3d:context_dump_fbo_attachment GL_STENCIL_ATTACHMENT: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT0: 2d texture 105, 0x0, format 0x1. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT1: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT2: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT3: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT4: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT5: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT6: NONE. fixme:d3d:context_dump_fbo_attachment GL_COLOR_ATTACHMENT7: NONE. err:d3d:wined3d_debug_callback 0x1dd038: "GL_INVALID_FRAMEBUFFER_OPERATION error generated. Operation is not valid because a bound framebuffer is not framebuffer complete.". err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ ../../../source/dlls/wined3d/device.c / 509

May 22, 2016

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

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Thanks for catching this bug. You'll have to submit your patch with your real name, and as Aaryaman stated, a signed off line. Am 2016-05-21 um 10:46 schrieb contrib(a)maxqia.com: > - if (!surface) > + if (!surface || surface->container->resource.format->id == WINED3DFMT_NULL) > { > key->objects[idx].object = 0; > key->objects[idx].target = 0; My sense is that a D3DFMT_NULL texture should hever have a GL texture allocated, so going through the final else path should be ok - surface_get_texture_name returns 0, and context_attach_surface_fbo ignores the other fields if object is 0. Can you check if object is != 0 in the case where it fails, and see where the value comes from? I can imagine that the game manually calls PreLoad on a NULL texture as a possible cause. In our draw and clear code we're skipping the GL texture allocation for NULL resources. If the GL texture is not 0 I expect that you get a GL error before context_set_fbo_key_for_surface is run. If it is indeed 0 and something goes wrong at a later point then my reasoning above must be wrong in some way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXQG4IAAoJEN0/YqbEcdMwQOQP/20p3/P+Ej25ABqMh83F9l1/ OlhCUM3BdjYxYaZacopDInmudVALgTLaQe28dlKMw181XSqQ1op9acwHXSvXkNKM ZyvNIsqtLxenX37ZWu0I22xqV+DFU07D4TbzrQMAlgMd9XUK2713PhNVKRuYSLpS LazcTMldRoiHOxrJF7spbAr0Nn2JPGwHV/4NA0baQdIycnVQqztFQHPmdRVSP/eO 9zOacv0AKDaPt3GXgJV0+S7QuDW9EEsXI6nkytDJpazBnfSrJRCVQIGhPiokf9ik dlFkwYKuZe/fSTgSfyxyB0IhQoaOsfM4LTSJymQpneADRLhbmPORORMdzFMW/GrN qKPgK28U2oES3u3YF6u5/2YgfrSUvJvvqPe8077Tyl60uG5W7lBWeMQ4HUDaDHgW vWcDbvX1vYh+BG5zIvvVzGvmRKoKYnnEj65iqGqpi/vcJMz2f4ff/vmAiT1y23Hl 0Y50ZUxTWXpUVi4uzoQlKgpmXbny2je0P2K12zbA13J3kJ/LxoHqefm1RW9VJ1w4 VxYD94lbk4zchO0AQwbLK83b7f8QoTZH2quqyzbgyFoAynXv0RDhQ2ZjtRN66Jh+ HmFOprGcCEmOnFs9c0JS8c9MSBVc8g1i6XmnnnccO3wyaw7vrNQbNmnqPRhkpPEV ELMYspnFGK8apZ7633Dq =QeKV -----END PGP SIGNATURE-----

May 21, 2016

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

by Aaryaman Vasishta

Hi, Thanks for the contribution! I noticed that you're missing something: On Sat, May 21, 2016 at 4:14 PM, Maxqia <contrib(a)maxqia.com> wrote: > This fixes https://bugs.winehq.org/show_bug.cgi?id=40624 > --- > dlls/wined3d/context.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > You need to sign-off on this patch. FWIW, Use git commit --amend -s to add a signed-off by field to your patch and resend it. Cheers, Aaryaman

May 21, 2016

Re: [PATCH] jscript: Date.parse: make "UTC"/"GMT" optional before the timezone offset

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=23146 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

May 21, 2016

Re: [PATCH 1/6] wined3d: Add wined3d creation flag for selecting unbound resource color.

by Henri Verbeet

On 20 May 2016 at 11:47, Józef Kucia <jkucia(a)codeweavers.com> wrote: > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index 8429bea..79ac440 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -1237,6 +1237,7 @@ enum wined3d_display_rotation > #define WINED3D_PIXEL_CENTER_INTEGER 0x00000080 > #define WINED3D_LEGACY_FFP_LIGHTING 0x00000100 > #define WINED3D_SRGB_READ_WRITE_CONTROL 0x00000200 > +#define WINED3D_UNBOUND_RESOURCE_COLOR_ZERO 0x00000400 > We generally try to make the "reasonable" behaviours the defaults, and only have flags for extra functionality or more quirky behaviours. In this case it's perhaps arguable what the default should be, but all zeroes seems like the more reasonable default to me.

May 20, 2016

Re: dnsapi: add DnsGetCacheDataTable stub

by Sebastian Lackner

On 20.05.2016 06:27, Austin English wrote: > +/****************************************************************************** > + * DnsGetCacheDataTable [DNSAPI.@] > + * > + */ > +DNS_GET_CACHE_DATA_TABLE WINAPI DnsGetCacheDataTable( DNSCACHEENTRY *cache ) I'm pretty sure it should not return a function pointer here. Also, you might want to move the struct to header file so that it can be used in tests later.

May 20, 2016

Re: ntdll: add WinSqmEndSession/WinSqmStartSession stubs

by Michael Müller

Am 20.05.2016 um 06:15 schrieb Austin English: > +NTSTATUS WINAPI WinSqmStartSession(GUID *sessionguid, DWORD sessionid, DWORD unknown1) > +{ Your usage example indicates that the function returns a HANDLE and not a NTSTATUS value. Returning INVALID_HANDLE_VALUE would therefore be the most suitable value for a stub. The linked code also handles this case. > +@ stdcall WinSqmEndSession(ptr) The parameter is a handle, so you should mark it as long instead of ptr. Btw, the remaining functions seems to be sorted alphabetically, so you also might want to correctly insert this function.

May 20, 2016

Re: [PATCH] mshtml/tests: Use todo_wine_if() in tests.

by Jacek Caban

Hi Hadrien, Please resend with your sign off. Other than that, the patch looks good. Thanks, Jacek

May 20, 2016

Re: [PATCH 3/7] d3drm: Implement IDirect3DRMTexture{2-3}_InitFromImage. (v6 resend)

by Henri Verbeet

On 19 May 2016 at 12:55, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 583dbec..1f57058 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1705,6 +1705,11 @@ static void test_Texture(void) > TRUE, 2 * sizeof(DWORD), NULL, NULL, > 0x000000ff, 0x0000ff00, 0x00ff0000, 0xff000000, 0, NULL > }, *d3drm_img = NULL; > + D3DRMIMAGE testimg = { Formatting. (Yeah, the existing test is like that as well.) > + 0, 0, 0, 0, 0, > + TRUE, 0, (void *)0xcafebabe, NULL, > + 0x000000ff, 0x0000ff00, 0x00ff0000, 0, 0, NULL > + }; > DWORD pixel[4] = { 20000, 30000, 10000, 0 }; > DWORD size; > CHAR cname[64] = {0}; > @@ -1853,22 +1858,95 @@ static void test_Texture(void) > ok(ref4 == ref1, "expected ref4 == ref1, got ref1 = %u, ref4 = %u.\n", ref1, ref4); > > /* InitFromImage tests */ > - d3drm_img = NULL; > + > + /* Tests for validation of D3DRMIMAGE struct */ > + hr = IDirect3DRM2_CreateObject(d3drm2, &CLSID_CDirect3DRMTexture, NULL, &IID_IDirect3DRMTexture2, (void **)&texture2); Line length. > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMTexture2 interface (hr = %x).\n", hr); It's not a huge issue, but %#x, please.

May 20, 2016

Re: [PATCH 2/7] d3drm: Introduce d3drm_texture_destroy helper (v4 resend).

by Henri Verbeet

On 19 May 2016 at 12:55, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -44,6 +44,14 @@ static inline struct d3drm_texture *impl_from_IDirect3DRMTexture3(IDirect3DRMTex > return CONTAINING_RECORD(iface, struct d3drm_texture, IDirect3DRMTexture3_iface); > } > > +static void d3drm_texture_destroy(struct d3drm_texture *texture) > +{ > + TRACE("texture %p is being destroyed.\n", texture); > +···· Trailing whitespace.

May 20, 2016

Re: [PATCH 1/7] d3drm: Use CreateObject in IDirect3DRM*::LoadTexture. (v3)

by Henri Verbeet

On 19 May 2016 at 13:00, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > static HRESULT WINAPI d3drm1_LoadTexture(IDirect3DRM *iface, > const char *filename, IDirect3DRMTexture **texture) > { > - struct d3drm_texture *object; > HRESULT hr; > > FIXME("iface %p, filename %s, texture %p stub!\n", iface, debugstr_a(filename), texture); > > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM_CreateObject(iface, &CLSID_CDirect3DRMTexture, NULL, > + &IID_IDirect3DRMTexture, (void **)texture))) > return hr; > > - *texture = &object->IDirect3DRMTexture_iface; > - > return D3DRM_OK; > } Actually, after thinking it through for a bit, I don't think you need to use CreateObject() here at all. You can just add an extra parameter to d3drm_texture_create() in patch 3/7 and avoid going through all the COM stuff. (Of course at that point you'll also notice load_mesh_data() is broken...) > @@ -857,17 +855,19 @@ static HRESULT WINAPI d3drm2_CreateUserVisual(IDirect3DRM2 *iface, > static HRESULT WINAPI d3drm2_LoadTexture(IDirect3DRM2 *iface, > const char *filename, IDirect3DRMTexture2 **texture) > { > - struct d3drm_texture *object; > + struct d3drm *d3drm = impl_from_IDirect3DRM2(iface); > + IDirect3DRMTexture3 *texture3; > HRESULT hr; > > FIXME("iface %p, filename %s, texture %p stub!\n", iface, debugstr_a(filename), texture); > > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM3_LoadTexture(&d3drm->IDirect3DRM3_iface, filename, &texture3))) > return hr; This change isn't necessarily wrong, but it's something different from what the rest of the patch does. Note that if things were ordered so that the newest version of the interface came first, you could call d3drm3_LoadTexture() here directly. The file is the way it is of course, but perhaps we should consider fixing that at some point.

May 20, 2016

Re: [PATCH] dwrite: Resolve BNs and embedding and override formatting characters to preceding level

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=23120 Your paranoid android. === wvistau64 (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w2008s64 (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w7u (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w7pro64 (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w8 (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w864 (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w1064 (32 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === wvistau64 (64 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w2008s64 (64 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w7pro64 (64 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w864 (64 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057 === w1064 (64 bit analyzer) === analyzer.c:2238: Test failed: got 0x80070057

May 20, 2016

Re: dnsapi: add DnsGetCacheDataTable stub

by Hans Leidekker

On Thu, 2016-05-19 at 23:27 -0500, Austin English wrote: > +typedef int (*DNS_GET_CACHE_DATA_TABLE)(PDNSCACHEENTRY); You don't need this. > +DNS_GET_CACHE_DATA_TABLE WINAPI DnsGetCacheDataTable( DNSCACHEENTRY *cache ) > +{ > + FIXME( "(%p) stub\n", cache); > + return ERROR_SUCCESS; > +} It should probably return DNS_STATUS and the parameter might actually be DNSCACHEENTRY **. Some tests would be helpful here.

May 20, 2016

Re: user32: Also change rcUpdate when scrolling by more than the window size.

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=23115 Your paranoid android. === wvistau64 (32 bit win) === win.c:8207: Test failed: WindowFromPoint returned 00040170, expected 000201FC win.c:8214: Test failed: WindowFromPoint returned 000601BA, expected 000301FA

May 19, 2016

[PATCH] local debugging help

by Fabian Maurer

Please ignore my patch 122481 dubbed "local debugging help", I sent that by mistake.

May 19, 2016

Re: [PATCH 07/11] wininet: Removed maximum URL length assumption from get_proxy_autoconfig_url.

by Jacek Caban

On 05/18/16 23:00, Sebastian Lackner wrote: > On 17.05.2016 19:16, Jacek Caban wrote: >> Also use correct encoding. >> >> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> >> --- >> dlls/wininet/internet.c | 33 +++++++++++++++++++-------------- >> 1 file changed, 19 insertions(+), 14 deletions(-) >> >> >> >> 0007-wininet-Removed-maximum-URL-length-assumption-from-ge.diff >> >> >> diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c >> index 371c3d0..78bea7c 100644 >> --- a/dlls/wininet/internet.c >> +++ b/dlls/wininet/internet.c >> @@ -2307,13 +2307,14 @@ BOOL WINAPI InternetReadFileExW(HINTERNET hFile, LPINTERNET_BUFFERSW lpBuffer, >> return res == ERROR_SUCCESS; >> } >> >> -static BOOL get_proxy_autoconfig_url( char *buf, DWORD buflen ) >> +static WCHAR *get_proxy_autoconfig_url(void) >> { >> #if defined(MAC_OS_X_VERSION_10_6) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6 >> >> CFDictionaryRef settings = CFNetworkCopySystemProxySettings(); >> + WCHAR *ret = NULL; >> + SIZE_T len; >> const void *ref; >> - BOOL ret = FALSE; >> >> if (!settings) return FALSE; >> >> @@ -2322,16 +2323,20 @@ static BOOL get_proxy_autoconfig_url( char *buf, DWORD buflen ) >> CFRelease( settings ); >> return FALSE; > You forgot to replace FALSE -> NULL at a couple of places in this patch. Good catch, thanks. I will send a fix. Thanks, Jacek

May 19, 2016

Re: [PATCH 1/7] d3drm: Use CreateObject in IDirect3DRM*::LoadTexture. (v2)

by Aaryaman Vasishta

On Thu, May 19, 2016 at 4:25 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > v2: Thunk 2->3 for LoadTexture. > > Signed-off-by: Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > --- > dlls/d3drm/d3drm.c | 21 +++++++++------------ > 1 file changed, 9 insertions(+), 12 deletions(-) > > diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c > index edb46df..bc16b6f 100644 > --- a/dlls/d3drm/d3drm.c > +++ b/dlls/d3drm/d3drm.c > @@ -413,16 +413,13 @@ static HRESULT WINAPI > d3drm1_CreateUserVisual(IDirect3DRM *iface, > static HRESULT WINAPI d3drm1_LoadTexture(IDirect3DRM *iface, > const char *filename, IDirect3DRMTexture **texture) > { > - struct d3drm_texture *object; > HRESULT hr; > > FIXME("iface %p, filename %s, texture %p stub!\n", iface, > debugstr_a(filename), texture); > > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM_CreateObject(iface, > &CLSID_CDirect3DRMTexture, NULL, &IID_IDirect3DRMTexture, (void > **)texture))) > return hr; > This line is too long, I'm resending v3 of this patch. Cheers, Aaryaman

May 19, 2016

Re: [v2 PATCH] user32/scroll: Move GetDCEx to stop DC leak

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/user32/scroll.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Since it can't happen there's no leak to fix. You could replace the return by an assert(0) if you want to make it clearer. -- Alexandre Julliard julliard(a)winehq.org

May 19, 2016

Re: [v3 PATCH] wined3d: Add missing WINED3DUSAGE flags to debug_d3dusage

by Henri Verbeet

On 18 May 2016 at 12:33, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > const char *debug_d3dusage(DWORD usage) > { > - char buf[333]; > + char buf[512]; 512 is insufficient, how did you arrive at that number?

May 19, 2016

Re: configure: Fix a typo in comments

by Nikolay Sivov

On 19.05.2016 12:13, Andrey Gusev wrote: > > --- a/configure > +++ b/configure > @@ -371,7 +371,7 @@ as_fn_executable_p () > # ---------------------- > # Append the text in VALUE to the end of the definition contained in VAR. Take > # advantage of any shell optimizations that allow amortized linear growth over > -# repeated appends, instead of the typical quadratic growth present in naive > +# repeated appends, instead of the typical quadratic growth present in native > # implementations. This is a generated part, if it had a typo it should be fixed in tools, not in Wine. For this patch, comment looks correct to me as it is.

May 19, 2016

Re: [PATCH 4/4] d3d9: Allow to pass NULL pointers to IDirect3DDevice9_GetRenderTargetData().

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

May 19, 2016

Re: comctl32: Fix a typo in comment

by Huw Davies

On Thu, May 19, 2016 at 11:42:11AM +0300, Andrey Gusev wrote: > diff --git a/dlls/comctl32/trackbar.c b/dlls/comctl32/trackbar.c > index 8c99ad0..ba4cec3 100644 > --- a/dlls/comctl32/trackbar.c > +++ b/dlls/comctl32/trackbar.c > @@ -920,7 +920,7 @@ TRACKBAR_Refresh (TRACKBAR_INFO *infoPtr, HDC hdcDst) > > GetClientRect (infoPtr->hwndSelf, &rcClient); > > - /* try to render offscreen, if we fail, carrry onscreen */ > + /* try to render offscreen, if we fail, carry onscreen */ > hdc = CreateCompatibleDC(hdcDst); > if (hdc) { > hOffScreenBmp = CreateCompatibleBitmap(hdcDst, rcClient.right, rcClient.bottom); Apart from the fact that this comment still doesn't make sense (it should probably have an additional 'on'), I'm not sure why we have this fallback in the first place. If the dc or bitmap creation fails then we've probably got bigger problems. I'd suggest just returning early in those cases (with the appropriate cleanup). Huw.

May 19, 2016

Re: [PATCH 07/11] wininet: Removed maximum URL length assumption from get_proxy_autoconfig_url.

by Sebastian Lackner

On 17.05.2016 19:16, Jacek Caban wrote: > Also use correct encoding. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/wininet/internet.c | 33 +++++++++++++++++++-------------- > 1 file changed, 19 insertions(+), 14 deletions(-) > > > > 0007-wininet-Removed-maximum-URL-length-assumption-from-ge.diff > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > index 371c3d0..78bea7c 100644 > --- a/dlls/wininet/internet.c > +++ b/dlls/wininet/internet.c > @@ -2307,13 +2307,14 @@ BOOL WINAPI InternetReadFileExW(HINTERNET hFile, LPINTERNET_BUFFERSW lpBuffer, > return res == ERROR_SUCCESS; > } > > -static BOOL get_proxy_autoconfig_url( char *buf, DWORD buflen ) > +static WCHAR *get_proxy_autoconfig_url(void) > { > #if defined(MAC_OS_X_VERSION_10_6) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6 > > CFDictionaryRef settings = CFNetworkCopySystemProxySettings(); > + WCHAR *ret = NULL; > + SIZE_T len; > const void *ref; > - BOOL ret = FALSE; > > if (!settings) return FALSE; > > @@ -2322,16 +2323,20 @@ static BOOL get_proxy_autoconfig_url( char *buf, DWORD buflen ) > CFRelease( settings ); > return FALSE; You forgot to replace FALSE -> NULL at a couple of places in this patch.

May 18, 2016

Re: user32: Fix a typo in a comment

by Ken Thomases

On May 18, 2016, at 2:46 PM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > > Signed-off-by: Frédéric Delanoy <frederic.delanoy(a)gmail.com> > --- > dlls/user32/combo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/user32/combo.c b/dlls/user32/combo.c > index c9b969f..143d992 100644 > --- a/dlls/user32/combo.c > +++ b/dlls/user32/combo.c > @@ -416,7 +416,7 @@ static void CBCalcPlacement( > > /* > * In the case of a dropdown, the popup listbox is offset to the right. > - * so, we want to make sure it's flush with the right side of the > + * so, we want to make sure it's flushed with the right side of the > * combobox > */ > if( CB_GETTYPE(lphc) == CBS_DROPDOWN ) The original is actually correct English. "Flush" is an adjective meaning aligned. Cheers, Ken

May 18, 2016

Re: [PATCH 1/5] usp10: Resolve BNs and explicit formatting characters to the preceding level in resolveResolved().

by Henri Verbeet

On 18 May 2016 at 18:51, Marvin <testbot(a)winehq.org> wrote: > === w1064 (32 bit usp10) === > usp10.c:1433: Test failed: 0: uJustification incorrect (0) > usp10.c:1433: Test failed: 1: uJustification incorrect (0) > usp10.c:1433: Test failed: 2: uJustification incorrect (0) > usp10.c:1433: Test failed: 3: uJustification incorrect (0) > usp10.c:1433: Test failed: 4: uJustification incorrect (0) > usp10.c:1433: Test failed: 5: uJustification incorrect (0) > usp10.c:1433: Test failed: 6: uJustification incorrect (0) > usp10.c:1433: Test failed: 7: uJustification incorrect (0) > usp10.c:1433: Test failed: 8: uJustification incorrect (0) > usp10.c:1433: Test failed: 9: uJustification incorrect (0) > usp10.c:1449: Test failed: 3: uJustification incorrect (0) > usp10.c:1449: Test failed: 5: fDiacritic incorrect (1) > usp10.c:1449: Test failed: 5: fZeroWidth incorrect (1) > usp10.c:1449: Test failed: 15: fDiacritic incorrect (1) > usp10.c:1449: Test failed: 15: fZeroWidth incorrect (1) > > === w1064 (64 bit usp10) === > usp10.c:1433: Test failed: 0: uJustification incorrect (0) > usp10.c:1433: Test failed: 1: uJustification incorrect (0) > usp10.c:1433: Test failed: 2: uJustification incorrect (0) > usp10.c:1433: Test failed: 3: uJustification incorrect (0) > usp10.c:1433: Test failed: 4: uJustification incorrect (0) > usp10.c:1433: Test failed: 5: uJustification incorrect (0) > usp10.c:1433: Test failed: 6: uJustification incorrect (0) > usp10.c:1433: Test failed: 7: uJustification incorrect (0) > usp10.c:1433: Test failed: 8: uJustification incorrect (0) > usp10.c:1433: Test failed: 9: uJustification incorrect (0) > usp10.c:1449: Test failed: 3: uJustification incorrect (0) > usp10.c:1449: Test failed: 5: fDiacritic incorrect (1) > usp10.c:1449: Test failed: 5: fZeroWidth incorrect (1) > usp10.c:1449: Test failed: 15: fDiacritic incorrect (1) > usp10.c:1449: Test failed: 15: fZeroWidth incorrect (1) > Those are existing failures as far as I'm aware.

May 18, 2016

Re: [PATCH 1/5] usp10: Resolve BNs and explicit formatting characters to the preceding level in resolveResolved().

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=23083 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1433: Test failed: 0: uJustification incorrect (0) usp10.c:1433: Test failed: 1: uJustification incorrect (0) usp10.c:1433: Test failed: 2: uJustification incorrect (0) usp10.c:1433: Test failed: 3: uJustification incorrect (0) usp10.c:1433: Test failed: 4: uJustification incorrect (0) usp10.c:1433: Test failed: 5: uJustification incorrect (0) usp10.c:1433: Test failed: 6: uJustification incorrect (0) usp10.c:1433: Test failed: 7: uJustification incorrect (0) usp10.c:1433: Test failed: 8: uJustification incorrect (0) usp10.c:1433: Test failed: 9: uJustification incorrect (0) usp10.c:1449: Test failed: 3: uJustification incorrect (0) usp10.c:1449: Test failed: 5: fDiacritic incorrect (1) usp10.c:1449: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1449: Test failed: 15: fDiacritic incorrect (1) usp10.c:1449: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1433: Test failed: 0: uJustification incorrect (0) usp10.c:1433: Test failed: 1: uJustification incorrect (0) usp10.c:1433: Test failed: 2: uJustification incorrect (0) usp10.c:1433: Test failed: 3: uJustification incorrect (0) usp10.c:1433: Test failed: 4: uJustification incorrect (0) usp10.c:1433: Test failed: 5: uJustification incorrect (0) usp10.c:1433: Test failed: 6: uJustification incorrect (0) usp10.c:1433: Test failed: 7: uJustification incorrect (0) usp10.c:1433: Test failed: 8: uJustification incorrect (0) usp10.c:1433: Test failed: 9: uJustification incorrect (0) usp10.c:1449: Test failed: 3: uJustification incorrect (0) usp10.c:1449: Test failed: 5: fDiacritic incorrect (1) usp10.c:1449: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1449: Test failed: 15: fDiacritic incorrect (1) usp10.c:1449: Test failed: 15: fZeroWidth incorrect (1)

May 18, 2016

Re: [PATCH 3/6] wininet: Use compose_request_url in INTERNET_OPTION_URL implementation.

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

May 18, 2016

Re: [PATCH] msvcr120/tests: Add critical section test.(resend)

by Piotr Caban

Hi, On 05/18/16 15:25, YongHao Hu wrote: > +#if _MSVCR_VER >= 110 _MSVCR_VER is not defined in tests. (I didn't look on rest of the patch yet) Thanks, Piotr

May 18, 2016

Re: [PATCH] msvcr120/tests: Add critical section test.(resend)

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=23080 Your paranoid android. === w2008s64 (64 bit msvcr120) === Found no trace of the test summary line or of a crash

May 18, 2016

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

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > 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. -- Alexandre Julliard julliard(a)winehq.org

May 18, 2016

Re: [PATCH] user32/scroll: Move GetDCEx to stop DC leak

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -920,9 +919,12 @@ static void SCROLL_HandleScrollEvent( HWND hwnd, INT nBar, UINT msg, POINT pt) > break; > > default: > + WARN("unsupported msg %s\n", SPY_GetMsgName(msg,hwnd)); > return; /* Should never happen */ > } > > + hdc = GetDCEx( hwnd, 0, DCX_CACHE | ((nBar == SB_CTL) ? 0 : DCX_WINDOW)); The function is only called for the messages it supports, so there's no need to add handling for other cases. -- Alexandre Julliard julliard(a)winehq.org

May 18, 2016

Re: ddraw/tests: Fix a typo in an ok() call

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=23075 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

May 18, 2016

Re: [PATCH] oleaut32 todo: formatting 0 with "000#"

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

May 18, 2016

Re: [PATCH] msxml3/tests: Simplify refcount checks

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=23060 Your paranoid android. === w1064 (32 bit httpreq) === httpreq.c:1628: Test failed: got 0x80070057, expected 0x00000000 === w1064 (64 bit httpreq) === httpreq.c:1628: Test failed: got 0x80070057, expected 0x00000000

May 17, 2016