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

Re: Assorted comment, trace and ok() message spelling fixes.

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=22082 Your paranoid android. === w1064 (64 bit chain) === The test timed out

April 11, 2016

Re: Assorted comment, trace and ok() message spelling fixes.

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=22080 Your paranoid android. === w864 (32 bit security) === security.c:3964: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0xa != 0x0) === w1064 (32 bit security) === security.c:3964: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

April 11, 2016

Re: Assorted comment, trace and ok() message spelling fixes.

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=22074 Your paranoid android. === 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.

April 11, 2016

Re: Assorted comment, trace and ok() message spelling fixes.

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=22072 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 === w1064 (64 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

April 11, 2016

Re: [PATCH 7/7] d3d8/tests: Add a system memory miptree layout test.

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=22069 Your paranoid android. === w8 (32 bit device) === device.c:1372: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1417: Test failed: Reset failed, hr 0x88760868. device.c:1419: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1423: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1430: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1431: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1432: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1433: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1434: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1435: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1440: Test failed: Screen width is 640, expected 800. device.c:1441: Test failed: Screen height is 480, expected 600. device.c:1447: Test failed: Back buffer width is 640, expected 800. device.c:1449: Test failed: Back buffer height is 480, expected 600. device.c:1479: Test failed: Screen width is 640, expected 1024. device.c:1480: Test failed: Screen height is 480, expected 768. device.c:2725: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2730: Test failed: The focus window is active. device.c:2738: Test failed: Got unexpected hr 0x88760869. device.c:2742: Test failed: Got unexpect screen size 800x600. device.c:2757: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2766: Test failed: Got unexpect screen size 800x600. device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2787: Test failed: Got unexpect width 640. device.c:2788: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:1372: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1417: Test failed: Reset failed, hr 0x88760868. device.c:1419: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1423: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1430: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1431: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1432: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1433: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1434: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1435: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1440: Test failed: Screen width is 640, expected 800. device.c:1441: Test failed: Screen height is 480, expected 600. device.c:1447: Test failed: Back buffer width is 640, expected 800. device.c:1449: Test failed: Back buffer height is 480, expected 600. device.c:1479: Test failed: Screen width is 640, expected 1024. device.c:1480: Test failed: Screen height is 480, expected 768. device.c:2725: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2730: Test failed: The focus window is active. device.c:2738: Test failed: Got unexpected hr 0x88760869. device.c:2742: Test failed: Got unexpect screen size 800x600. device.c:2757: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2766: Test failed: Got unexpect screen size 800x600. device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2787: Test failed: Got unexpect width 640. device.c:2788: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2725: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2730: Test failed: The focus window is active. device.c:2738: Test failed: Got unexpected hr 0x88760869. device.c:2742: Test failed: Got unexpect screen size 800x600. device.c:2757: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2766: Test failed: Got unexpect screen size 800x600. device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2787: Test failed: Got unexpect width 640. device.c:2788: Test failed: Got unexpect height 480.

April 11, 2016

Re: [PATCH 6/7] d3d9/tests: Add a system memory miptree layout test.

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=22068 Your paranoid android. === 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.

April 11, 2016

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Paul Gofman

On 04/11/2016 08:05 PM, Paul Gofman wrote: > On 04/11/2016 07:52 PM, Matteo Bruni wrote: >> 2016-04-07 17:41 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> >> >>> +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, >>> + D3DXHANDLE hc, struct d3dx_parameter *param) >>> +{ >>> + ID3DXConstantTable *ctab = const_tab->ctab; >>> + D3DXCONSTANT_DESC desc; >>> + unsigned int const_count, param_count, i, j, n, table, start_offset; >>> + unsigned int minor, major, major_stride, param_offset; >>> + BOOL transpose, get_element; >>> + >>> + ID3DXConstantTable_GetConstantDesc(ctab, hc, &desc, &const_count); >> This isn't correct, although it currently works. const_count is >> supposed to be an inout parameter for GetConstantDesc() (you could >> potentially have multiple instances of the same constant in different >> register sets). The current implementation of GetConstantDesc() >> doesn't check the parameter and blindly returns only the first >> descriptor, also setting const_count to 1 (actually the following >> descriptors aren't even parsed currently by the constant table code >> IIRC) so this ends up working, although that's a bug and at some point >> it might get fixed which would in turn break this. >> Also it's a bit of an "overload" to use the same variable here and as >> the count of constant elements / members in the following lines, it's >> probably nicer to use two separate variables. >> >> BTW you're using GetConstantDesc() correctly in get_constants_desc(). >> > I was looking into GetConstantsDesc() implementation to get the idea how > constants count can be > 1 there, and saw there that the count is > ultimately 1, that's why left it like that. Do you think it is OK just > to set count to 1 prior to the call? As I get MSDN text for this count > > 1 is possible only for samplers and we should not get here for samplers > anyway. > > Oh, please ignore this, actually the value type constant may also appear multiple types if it is used in different register index. So I suggest to initialize count to 1 before the call and put a FIXME if count != 1 on return. Making the real implementation for > 1 will be just a dead code for now until GetConstantsDesc actually support this.

April 11, 2016

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Paul Gofman

On 04/11/2016 07:52 PM, Matteo Bruni wrote: > 2016-04-07 17:41 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > > >> +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, >> + D3DXHANDLE hc, struct d3dx_parameter *param) >> +{ >> + ID3DXConstantTable *ctab = const_tab->ctab; >> + D3DXCONSTANT_DESC desc; >> + unsigned int const_count, param_count, i, j, n, table, start_offset; >> + unsigned int minor, major, major_stride, param_offset; >> + BOOL transpose, get_element; >> + >> + ID3DXConstantTable_GetConstantDesc(ctab, hc, &desc, &const_count); > This isn't correct, although it currently works. const_count is > supposed to be an inout parameter for GetConstantDesc() (you could > potentially have multiple instances of the same constant in different > register sets). The current implementation of GetConstantDesc() > doesn't check the parameter and blindly returns only the first > descriptor, also setting const_count to 1 (actually the following > descriptors aren't even parsed currently by the constant table code > IIRC) so this ends up working, although that's a bug and at some point > it might get fixed which would in turn break this. > Also it's a bit of an "overload" to use the same variable here and as > the count of constant elements / members in the following lines, it's > probably nicer to use two separate variables. > > BTW you're using GetConstantDesc() correctly in get_constants_desc(). > I was looking into GetConstantsDesc() implementation to get the idea how constants count can be > 1 there, and saw there that the count is ultimately 1, that's why left it like that. Do you think it is OK just to set count to 1 prior to the call? As I get MSDN text for this count > 1 is possible only for samplers and we should not get here for samplers anyway.

April 11, 2016

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

2016-04-07 17:41 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > switch (state->type) > { > case ST_CONSTANT: > + *param_value = param->data; > + *out_param = param; > + return D3D_OK; > case ST_PARAMETER: > + param = param->referenced_param; > *param_value = param->data; > *out_param = param; > return D3D_OK; It doesn't matter (this is perfectly fine) but you could have kept the fallthrough by switching these two cases around. > +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, > + D3DXHANDLE hc, struct d3dx_parameter *param) > +{ > + ID3DXConstantTable *ctab = const_tab->ctab; > + D3DXCONSTANT_DESC desc; > + unsigned int const_count, param_count, i, j, n, table, start_offset; > + unsigned int minor, major, major_stride, param_offset; > + BOOL transpose, get_element; > + > + ID3DXConstantTable_GetConstantDesc(ctab, hc, &desc, &const_count); This isn't correct, although it currently works. const_count is supposed to be an inout parameter for GetConstantDesc() (you could potentially have multiple instances of the same constant in different register sets). The current implementation of GetConstantDesc() doesn't check the parameter and blindly returns only the first descriptor, also setting const_count to 1 (actually the following descriptors aren't even parsed currently by the constant table code IIRC) so this ends up working, although that's a bug and at some point it might get fixed which would in turn break this. Also it's a bit of an "overload" to use the same variable here and as the count of constant elements / members in the following lines, it's probably nicer to use two separate variables. BTW you're using GetConstantDesc() correctly in get_constants_desc(). > + table = const_tab->regset2table[desc.RegisterSet]; > + if (table >= PRES_REGTAB_COUNT) > + { > + FIXME("Unexpected register set %u.\n", desc.RegisterSet); > + return D3DERR_INVALIDCALL; > + } Since regset2table is defined by us ERR() is maybe more appropriate here. It might make sense to also check desc.RegisterSet before accessing the array. > + hc = ID3DXConstantTable_GetConstant(const_tab->ctab, NULL, i); > + if (!hc) > + { > + FIXME("Could not get constant.\n"); > + hr = D3DERR_INVALIDCALL; You could probably also print the value of 'i' in the FIXME. Up to you, but you could switch the then and else branches and drop the '!' in the if condition. > + if (oi->func_all_comps) > + { > + if (oi->input_count * ins->component_count > ARGS_ARRAY_SIZE) > + { > + FIXME("Too many arguments (%u) for one instruction.\n", oi->input_count * ins->component_count); > + return E_FAIL; > + } I think this check should be outside of the if (oi->func_all_comps) block. > + hr = set_constants(&peval->pres.regs, &peval->pres.inputs); > + if (FAILED(hr)) > + return hr; > + > + hr = execute_preshader(&peval->pres); > + if (FAILED(hr)) > + return hr; Not a big deal but since you're there... You could merge the function calls with the respective if, like you're doing in some other patches of the series.

April 11, 2016

Re: EVE using Wine on Mac

by Michael Müller

Am 11.04.2016 um 15:15 schrieb Snorri Sturluson: > experiment is going well – there have been some issues with getting Wine > to run on all the different OS X versions and different hardware > configurations out there, but that has largely been resolved (I think) > with proper configuration of the build machine producing the Wine build. WineHQ provides builds for OS X as tar archive which you could repackage if you don't want to build Wine. All imports are rewritten to be position independent and you could just extract the files wherever you want. However, the builds also support X11 and therefore depend on XQuartz which is most probably a no-go for you. > > My plan is to proactively hunt down and fix any issues our Mac players > run into, whether the fix entails digging into Wine source or our own > codebase. Ideally everything we do in EVE should just work under Wine, > but sometimes a workaround in our code may be easier than hunting down > why Wine behaves different from Windows, but being able to debug both > sides makes finding workarounds easier. Any fixes I come up with I will > contribute to Wine, of course – it remains to be seen if they end up > being very EVE specific, as EVE will of course be my main focus. It is great that you try to help the Wine project. Adding workarounds in EVE has some disadvantages though. You basically remove the possibility for us to debug the issue since we don't have access to the old version any more. If you run into a problem you can't or don't want to fix on your own, it would be better if you could open a bug report with a test executable (or even better some source code to reproduce the issue). This way someone else can fix the issue in Wine and you can remove the work around again. Please also make sure that the Wine specific workarounds also work on Windows. Otherwise you just depend on a bug in Wine which might be fixed any time. There are already some applications which are now broken in Wine because of this. The developers added workarounds that depended on Wine specific behavior, but the the bug was fixed in the mean time and the software didn't receive an update. Anyway, thanks for your work so far. Regards, Michael

April 11, 2016