September 2016 - Wine-Devel

Re: [PATCH 3/7] wined3d: Implement the initial texture data upload on top of wined3d_device_update_sub_resource().

by Henri Verbeet

On 21 September 2016 at 01:26, Michael Müller <michael(a)fds-team.de> wrote: > Didn't this break the initial upload for 3d textures as > wined3d_device_update_sub_resource only supports buffers and 2d textures? > Yeah, it might, in as far that anything that uses that currently works. Shouldn't be terribly hard to fix though.

Sept. 21, 2016

Re: [PATCH 3/7] wined3d: Implement the initial texture data upload on top of wined3d_device_update_sub_resource().

by Michael Müller

Am 20.09.2016 um 11:41 schrieb Henri Verbeet: > - wined3d_texture_upload_data(object, i, context, &addr, data[i].row_pitch, data[i].slice_pitch); > - wined3d_texture_validate_location(object, i, WINED3D_LOCATION_TEXTURE_RGB); > - wined3d_texture_invalidate_location(object, i, ~WINED3D_LOCATION_TEXTURE_RGB); > + wined3d_device_update_sub_resource(device, &object->resource, > + i, NULL, data[i].data, data[i].row_pitch, data[i].slice_pitch); Didn't this break the initial upload for 3d textures as wined3d_device_update_sub_resource only supports buffers and 2d textures?

Sept. 20, 2016

Re: d3d9/tests: Allow D3D_OK for lost device present (Win10)

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=25889 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=1. === w1064 (64 bit d3d9ex) === d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=1.

Sept. 20, 2016

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

by Fabian Maurer

Just to make this clear, this patch was my example on how to implement the dx11 functions with d3dx9 code: > Fabian, if you want to send patches for > D3DX11CreateShaderResourceViewFromFileW "duplicating" the relevant > code for the time being, that is fine to me. It might even be easier > to decide how to share the code at that point. My plan was to pull the code out of of d3dx9, make it generic and put it into a place where both d3dx11 and d3dx9 can use it. Once these helpers worked with d3dx9, I'd implement the d3dx11 functions using them. This patch series was a working implementation - like you wanted to see - which duplicates the relevant code so I would know how to share it between versions. But now we're mostly at "write it from scratch". It's fine if you'd rather want a complete rewrite instead of copy&paste with modifications, but I think I made it pretty clear from the beginning this wasn't my intention. I'd make the generic helpers less "hacky" or rewrite parts of them, but I fear I'm not the person to do a good complete rewrite of all this.

Sept. 20, 2016

Re: Problems with the tooltip controls.

by John Found

On Mon, 19 Sep 2016 21:43:14 +0300 Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Hi, John. > > Please open a bug report and attach sample application code there or at > least a relevant part of it, so we can turn it into a test. Workarounds are > not interesting for Wine. > Bug submitted: #41370; With links to the source code revealing it. Your turn, dear WINE developers. :) Best regards. P.S. I actually found some workaround - simply to not use TTM_GETCURRENTTOOL and to identify the tool only by the NMHDR.idFrom received in the notification. :P -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Sept. 20, 2016

Re: oleaut32: Handle xbuf_get erroring out in deserialize_param (and avoid uninitialized read).

by Dmitry Timoshkov

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > --- a/dlls/oleaut32/tmarshal.c > +++ b/dlls/oleaut32/tmarshal.c > @@ -1078,7 +1078,10 @@ deserialize_param( > if (readit) { > DWORD x; > hres = xbuf_get(buf,(LPBYTE)&x,sizeof(DWORD)); > - if (hres) ERR("Failed to read integer 4 byte\n"); > + if (hres) { > + ERR("Failed to read integer 4 byte\n"); > + x = 0; > + } > memcpy(arg,&x,2); > } > if (debugout) TRACE_(olerelay)("%04x",*arg & 0xffff); > @@ -1088,7 +1091,10 @@ deserialize_param( > if (readit) { > DWORD x; > hres = xbuf_get(buf,(LPBYTE)&x,sizeof(DWORD)); > - if (hres) ERR("Failed to read integer 4 byte\n"); > + if (hres) { > + ERR("Failed to read integer 4 byte\n"); > + x = 0; > + } > memcpy(arg,&x,1); A proper fix would be to avoid a memcpy() if xbuf_get() fails instead of creating bogus input data. -- Dmitry.

Sept. 20, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Henri Verbeet

On 20 September 2016 at 02:59, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > functions. In theory you could even use native d3dx11 on Wine, > although that might give some misleading results e.g. if Wine's d3d11 > isn't quite doing the right thing. > And you'd have to be careful not to look at e.g. +d3d11 traces when doing that, so I'd recommend against it.

Sept. 20, 2016

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

by Matteo Bruni

2016-09-20 2:35 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: >> It was already mentioned but, at the cost of being annoying, let me >> reiterate: d3dx* DLLs can't directly use wined3d data types or APIs. >> They have to go through the respective d3d* client library functions. >> >> I suspect that code sharing between d3dx* versions will eventually >> happen in a somewhat different fashion and trying to build the "final >> solution" from the ground up is going to be hard. Porting the various >> pieces of code to d3d[x]11 as necessary, even at the cost of >> "duplication" in the short term, is probably a better plan. > > I somewhat doubt it. It wasn't too hard to use the d3dx9 parts for d3dx11 And that's exactly the problem. That that's not the proper way of doing it, what your patches do is to take d3dx9 code and hammer it until it works for d3dx11. The result is that it "works" but it isn't pretty, both for the process (you can see the hammering right in the patch series) and the end result (the resulting code in d3dx11 is ugly). BTW, notice that the d3dx9 code isn't particularly nice either, result of years of additions / fixes / changes done by multiple people. It could use a rewrite, if only there was a good reason... For the time being, you have to trust my judgment on the matter (or escalate things, but I'm pretty sure you'll find more of the same). Let me list my main issues with the current patch series: - 2K lines code drop - copying d3dx9 code to d3dx11 while adding a bunch of defines and definitions to make it compile - using wined3d types in d3dx because they happen to match the use case at hand - no tests Each of them is reason enough to reject the series right away. I imagine that it isn't obvious to you why is that and I'm not sure how to convince you in detail, I feel like I'm doing a terrible job at that. I'll try to reply to specific questions (and gladly accept help from other fellow devs). I'll repeat myself to conclude. IMHO the easiest way to generate acceptable patches for this stuff is to follow the "plan" I expressed in my last few emails: start from scratch, adding a small piece at a time, with tests.

Sept. 20, 2016

Re: Getting backtraces from services without crash dialog

by Austin English

On Wed, Sep 7, 2016 at 8:40 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Wed, Sep 7, 2016 at 8:18 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> I haven't tried this, but my suggestion would be to replace the >> WriteFile in dbg_outputA with a call to wine_dbg_printf, something >> like: >> >> wine_dbg_printf("%.*s", i, line_buff); >> >> On Tue, Sep 6, 2016 at 7:18 PM, Austin English <austinenglish(a)gmail.com> wrote: >>> Howdy all, >>> >>> I asked this in #winehackers, but got no reply. >>> >>> I have a program: >>> >>> http://www.cressi.com/software >>> http://www.cressi.com/easyUp/software/CressiPcInterface_2_0_1_37_Installer.… >>> >>> that installs some device drivers that crash when it is starting up. >>> If I have the crash dialog enabled, I can save their backtraces. If I >>> disable it, all I see is something like: >>> wine: Unhandled page fault on write access to 0x0078d000 at address >>> 0x7bc55e7f (thread 00a1), starting debugger... >>> >>> Is there some way for me to get the backtraces to print to a console >>> (either of the first wine process or of the later running programs? If >>> the dialog is enabled, there are several crashes, which makes that >>> inconvenient. >>> >>> Thanks! >>> -- >>> -Austin >>> GPG: 14FB D7EA A041 937B >>> >>> > > Thanks Vincent. > > The backtraces were interspersed with fixme's (not unexpected), but > other than that, worked great, thanks. > > -- > -Austin > GPG: 14FB D7EA A041 937B FYI, I documented this at https://wiki.winehq.org/Winedbg Thanks again! -- -Austin GPG: 14FB D7EA A041 937B

Sept. 20, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Matteo Bruni

2016-09-20 2:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: >> Yeah, that's certainly not acceptable. Also in general introducing >> dead code (i.e. code that's unused until a later patch) is not okay. > > Well I see. It's just that I didn't want to commit the whole thing as single > patch, since that would make it way less understandable. So I split it up to > show where exactly I changed lines. Regarding "introducing dead code", I > thought it was fine if it was part of a patchset? Obviously all patches in this > set depend on the others. They aren't supposed to be on their own, it's just > way more overseeable like that. Well, obviously a single huge patch wouldn't be okay either. The problem is in how you split stuff over multiple patches. More below... >> You can probably start from a simple implementation of >> D3DX11CreateTextureFromMemory(), without any scaling or format >> conversion and without DDS support. Something like >> 258dba1a521cff3226db523b012ef3de2599e578 but for d3dx11. Notice how >> that calls D3DXGetImageInfoFromFileInMemory(); similarly it might make >> sense to implement D3DX11GetImageInfoFromMemory() first. >> >> Then you should introduce the various other pieces incrementally, as >> they become necessary. You don't want to actually duplicate the code >> keeping all the d3d9-isms, you'll have to rewrite those helpers in a >> way that makes sense for d3d11 (incidentally, that's what I meant with >> this being a useful step before figuring out how generic helpers would >> look like). > > Actually, this is my attempt at a generic helper. > "load_imagedata_from_file_in_memory" and "load_imageinfo_from_file_in_memory" > should be usable for both DX9 and DX11. > The point is, that this is mostly C&P from d3dx9 code. I didn't change too > much, so I figured it would be a bad idea to cut out functionality to add it > later again. You aren't actually stripping functionality from anything. You are implementing a new d3dx11 function. The fact that it happens to be very similar to another function which is already implemented is quite tangential. I'd say it's been more confusing than helping up to this point. Try to go implement the d3dx11 functions as I suggest above. You should "automatically" get a much nicer patch series, with each patch adding some small and easily testable piece of functionality or a test for the aforementioned functionality. I'd start with a stub for D3DX11GetImageInfoFromMemory(). Then one or more patches adding flesh to it AND tests. Sharing code should not be a concern at all at this point. Looking at the d3dx9 code and tests for inspiration is okay but you DON'T want to copy it, that's simply going to be worse than starting from scratch. >> Most importantly, you need to write some tests for all the functions >> you are implementing. The related d3dx9 tests are probably a decent >> starting point, although there are a few new bits that should be >> tested as well (e.g. it would be interesting to test various >> combinations of BindFlags, CpuAccessFlags and MiscFlags). You want to >> do that even before starting to work on the implementation, there >> might be some surprising results. > > Yeah, I don't have tests yet. First I wanted to give you an implementation so > we could decide on where to put the helpers. Also, I kinda don't know how to > write a proper test without running windows (except for a VM). Don't worry about sharing code for the time being. Tests are much more important. WRT the tests there is the testbot (http://testbot.winehq.org/) there you can submit patches and run tests against a number of Windows VMs. You just have to ask for an account first. A local Windows VM should also be fine to test for these d3dx11 functions. In theory you could even use native d3dx11 on Wine, although that might give some misleading results e.g. if Wine's d3d11 isn't quite doing the right thing.

Sept. 20, 2016