March 2016 - Wine-devel - list.winehq.org

Re: [v3 resend 2/6] d3dx9: add preshaders to effect.
by Matteo Bruni 17 Mar '16

17 Mar '16

2016-03-10 19:50 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> Looks pretty good to me in general. I also like d3dx_param_eval and related names. > + for (i = 0; i < param->element_count; i++) > + { > + if (param->members[i].type != param->type) > + { > + FIXME("Unexpected member parameter type %u (need %u).\n", param->members[i].type, param->type); I would use "expected" or something similar instead of "need" in this message. > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > new file mode 100644 > index 0000000..409c00f > --- /dev/null > +++ b/dlls/d3dx9_36/preshader.c > @@ -0,0 +1,688 @@ > +/* > + * FX preshader parsing & execution, setting shader constants > + * from effect parameters. > + * > + * Copyright 2016 Paul Gofman > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "config.h" > +#include "wine/port.h" > + > +#include "windef.h" > +#include "wingdi.h" Not your fault but those shouldn't be there. wingdi.h is already included by d3dx9_36_private.h, while windef.h is not but still it's necessary to avoid errors when including d3dx9_36_private.h. I'm sending a patch cleaning up the includes in d3dx9 (and renaming d3dx9_36_private.h to d3dx9_private.h while at it), please update this patch accordingly. > +static const struct > +{ > + unsigned int value_size; > + unsigned int reg_value_cnt; Just my preference, I would go with component_size and component_count (or maybe reg_component_count). > + {sizeof(float), 4, PRES_VT_FLOAT } /* PRES_REGTAB_REG */ I think I had tested this in the past and it turned out temporaries are stored as doubles. I'll see if I can find something. > +static const char *table_symbol[] = > +{ > + "(null)", "imm", "c", "v", "oc", "ob", "oi", "r" > +}; > + > +static const char *xyzw_str = "xyzw"; I haven't checked but maybe you can put those directly in the function using them. > + > +#define OFFSET2REG(table, offset) ((offset) / table_info[table].reg_value_cnt) > + > +static const enum PRES_REG_TABLES pres_regset2table[] = > +{ > + PRES_REGTAB_OBCONST, /* D3DXRS_BOOL */ > + PRES_REGTAB_OICONST, /* D3DXRS_INT4 */ > + PRES_REGTAB_CONST, /* D3DXRS_FLOAT4 */ > + PRES_REGTAB_NONE, /* D3DXRS_SAMPLER */ > +}; > + > +static const enum PRES_REG_TABLES shad_regset2table[] = > +{ > + PRES_REGTAB_OBCONST, /* D3DXRS_BOOL */ > + PRES_REGTAB_OICONST, /* D3DXRS_INT4 */ > + PRES_REGTAB_OCONST, /* D3DXRS_FLOAT4 */ > + PRES_REGTAB_NONE, /* D3DXRS_SAMPLER */ > +}; > + > +struct d3dx_pres_operand > +{ > + enum PRES_REG_TABLES table; > + /* offset is value index, not register index, e. g. > + offset for value c3.y is 17 (3 * 4 + 1) */ As I mentioned already, I would refer to "components" instead of "values". > + unsigned int offset; > +}; > + > +struct d3dx_pres_ins > +{ > + enum PRES_OPS op; > + /* first input argument is scalar, > + scalar component is propagated */ > + BOOL scalar_op; > + unsigned int ncomps; > + unsigned int ninp_args; Something like "component_count" and "operands_count" (or "input_count", or whatever) seems nicer. Similarly for the other counts. > + > +struct d3dx_param_eval > +{ > + enum param_eval_type peval_type; I feel like I might have already asked this, sorry if that's the case: do you really need this field? At least for what I can see at the moment you can do without since it's used only in d3dx_create_param_eval(), which is where you set the field, and in d3dx_param_eval_set_shader_constants(), where you don't really need it. > + D3DXPARAMETER_TYPE param_type; This one can also probably be avoided (e.g. by passing it down the call chain from the d3dx_parameter struct) although it's probably a bit more useful so I don't mind. > + > + struct d3dx_preshader pres; > + struct d3dx_const_tab shader_inputs; > +}; > + > +static HRESULT regstore_alloc_table(struct d3dx_regstore *rs, unsigned int table) > +{ > + unsigned int sz; > + > + sz = rs->table_sizes[table] * table_info[table].reg_value_cnt * table_info[table].value_size; > + if (sz) > + { > + rs->tables[table] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sz); > + rs->table_value_set[table] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*rs->table_value_set[table]) * > + ((rs->table_sizes[table] + PRES_VS_BITS_PER_WORD - 1) / PRES_VS_BITS_PER_WORD)); > + if (!rs->tables[table] || !rs->table_value_set[table]) > + return E_OUTOFMEMORY; > + } > + return D3D_OK; > +} > + > +static void regstore_free_tables(struct d3dx_regstore *rs) > +{ > + unsigned int i; > + > + for (i = PRES_REGTAB_IMMED; i < PRES_REGTAB_MAX; i++) Maybe add a couple of enum PRES_REGTAB_FIRST and PRES_REGTAB_LAST and use them here? > + for (j = 0; j < n; j++) > + TRACE("0x%08X,", words[i + j]); Please use lowercase hexadecimals. > + if (ninp_args != pres_op_info[i].ninp_args) > + { > + FIXME("Actual input args %u, expected %u, instruction %s.\n", ninp_args, > + pres_op_info[i].ninp_args, pres_op_info[i].mnem); > + return NULL; > + } > + ins->ninp_args = ninp_args; It shouldn't be necessary to store the number of arguments in the instruction structure at the moment, although maybe there is some variable-arguments opcode? > + hr = E_FAIL; This seems unnecessary. > + > -- git am complains about that empty line at the end of the file.

2 2

Re: TestBot job 21484 results: winhttp/tests: Fix test failures.
by Hans Leidekker 17 Mar '16

17 Mar '16

On Thu, 2016-03-17 at 04:21 -0500, Marvin wrote: > === w864 (32 bit winhttp) === > > winhttp: > winhttp.c:1030: Test failed: failed to send request 2148074273 > winhttp.c:1034: Test failed: failed to retrieve certificate context 12019 > winhttp.c:1039: Test failed: failed to retrieve key bitness 4317 > winhttp.c:1043: Test failed: failed to retrieve certificate info 12019 > winhttp.c:1056: Test failed: failed to receive response 12019 > winhttp.c:1060: Test failed: failed to query available data 12019 > winhttp.c:1061: Test failed: available_size = 0 > winhttp.c:1066: Test failed: failed unexpectedly 12019 > winhttp.c:1067: Test failed: request failed unexpectedly 3735928559 > winhttp.c:1078: Test failed: WinHttpReadData failed: 12019. Here's a clean run: https://testbot.winehq.org/JobDetails.pl?Key=21483 In this test run without my patch the same error occurs only on that VM, but in a different test: https://testbot.winehq.org/JobDetails.pl?Key=21482 I don't remember seeing this failure before, so it looks like an unrelated issue that was also introduced with the upgrade.

1 0

Re: winhttp/tests: Fix test failures.
by Marvin 17 Mar '16

17 Mar '16

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=21484 Your paranoid android. === w864 (32 bit winhttp) === winhttp.c:1030: Test failed: failed to send request 2148074273 winhttp.c:1034: Test failed: failed to retrieve certificate context 12019 winhttp.c:1039: Test failed: failed to retrieve key bitness 4317 winhttp.c:1043: Test failed: failed to retrieve certificate info 12019 winhttp.c:1056: Test failed: failed to receive response 12019 winhttp.c:1060: Test failed: failed to query available data 12019 winhttp.c:1061: Test failed: available_size = 0 winhttp.c:1066: Test failed: failed unexpectedly 12019 winhttp.c:1067: Test failed: request failed unexpectedly 3735928559 winhttp.c:1078: Test failed: WinHttpReadData failed: 12019.

1 0

Home Stretch for the New Wiki
by Kyle Auble 17 Mar '16

17 Mar '16

Hi everybody, I just wanted to update you all on the state of the wiki. This email may seem long but it isn't too dense; feel free to skip the numbers, but for anyone that might appreciate some figures, the old wiki had... Total pages: 841 (Less) system pages: ~150 Actual pages by us: ~690 These consisted of... Redirects ~45 Homepages ~150 Categories ~25 Content pages: ~470 Of the content pages, we had... English pages: 384 Translations: ~86 Of the translations, between 20-26 were immediately disqualified (either as less than 50% actually translated or a translation of an English page we rejected). Alex H mentioned that most of the translations probably weren't worth migrating, but we thought we should leave that up to potential translators. For those remaining English pages... Already ported in some way: 153 Rejected as not worth porting: 169 Still unfinished: 62 Of these last 62, we actually have relatively clear plans for how to port ~25 of them, leaving just 35 or so as truly up for grabs. Furthermore, we've tried to leave a quick note on http://oldwiki.winehq.org/PageMigration for every page that still needs a decision. And of course, people are free to override our rejections if they really want to keep a page (we left an explanation for every rejection at the top of the relevant page) While some of those last 35 pages are really just a matter of policy (e.g. do we want a page for every command, even if it's a stub?), many of them have at least one or two technical notes that seem to supplement the API documentation. These are the ones where we would really appreciate input or decisions from developers, particularly whether anything is worth moving to the Developers' docs. Finally, as Rosanne and I made alternating edits, we discussed a few points that we think are worth keeping in mind for the future: 1. If a page is experimental / dev-oriented, try to make that clear from the name, text, and possibly a bold note (for example, a lot of users were apparently misinterpreting "WineOnWindows" as a stable feature they could use) 2. If you're using a distro/OS with its own wiki page, keeping an eye on its page for incorrect or outdated info would be great, even if only every few months. I updated several of them last year, testing what I could and researching docs on and outside WineHQ for changes, but it's no substitute for someone that knows first-hand what each one requires. 3. If you don't agree with a change, don't be afraid to revert it and start a discussion for the page, especially now that we have the talk pages. 4. The wiki is a natural place for things like to-do lists and transient notes, but if the same information can be easily written so that it's just as useful 5 years from now, aim for timelessness. If more of the wiki ages well, it should be easier to keep track of the things that may bit-rot. 5. Finally, if you want to start a new page, check to see if you could somehow add your info to existing pages first. Obviously we don't want the pages to get too long and it's totally subjective in the end, but it seems the more the pages spread out wildly, the more likely they are to wind up orphaned and abandoned. Have a good start to your spring everybody, Kyle

1 0

Re: [PATCH 1/2] d3drm: Change signature of d3drm_texture_create.
by Henri Verbeet 16 Mar '16

16 Mar '16

The subject line is pretty vague. On 15 March 2016 at 22:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -193,8 +194,16 @@ static HRESULT WINAPI d3drm1_CreateTexture(IDirect3DRM *iface, > D3DRMIMAGE *image, IDirect3DRMTexture **texture) > { > FIXME("iface %p, image %p, texture %p partial stub.\n", iface, image, texture); > + struct d3drm_texture *object; > + HRESULT hr; You mix declarations and code here. The compiler should have warned about that. > + hr = d3drm_texture_create(&object); > + if (FAILED(hr)) > + return hr; We would generally write that as if (FAILED(hr = d3drm_texture_create(&object))) return hr; not a big deal though. > +IDirect3DRMTexture *IDirect3DRMTexture_from_impl(struct d3drm_texture *texture) > +{ > + return &texture->IDirect3DRMTexture_iface; > +} > + > +IDirect3DRMTexture2 *IDirect3DRMTexture2_from_impl(struct d3drm_texture *texture) > +{ > + return &texture->IDirect3DRMTexture2_iface; > +} > + > +IDirect3DRMTexture3 *IDirect3DRMTexture3_from_impl(struct d3drm_texture *texture) > +{ > + return &texture->IDirect3DRMTexture3_iface; > +} I don't think these are an improvement, I'd prefer them just written out. > -HRESULT Direct3DRMTexture_create(REFIID riid, IUnknown **out) > +HRESULT d3drm_texture_create(struct d3drm_texture **out) I think "texture" would be a more appropriate name than "out" here.

2 2

Re: dsound: Avoid implicit cast of interface pointer. [RFC]
by Henri Verbeet 16 Mar '16

16 Mar '16

On 16 March 2016 at 05:46, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > To catch errors like http://source.winehq.org/patches/data/120308 easier in the future, > I would like to propose, that we replace CONTAINING_RECORD and similar macros with a > typesafe definition (on compilers where this is possible). The linux kernel source > contains an example how to do that, but there are multiple solutions available: > > #define container_of(ptr, type, member) ({ \ > const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > (type *)( (char *)__mptr - offsetof(type,member) );}) > > One disadvantage is that we'll have to add explicit casts to a couple of places, like below. > Other dlls which would require explicit casts at a couple of places: > > amstream, d2d1, d3d11, d3d8, d3d9, ddraw, dwrite, msxml3, oleaut32, quartz, rpcrt4, vbscript > That implies you've tried the change. Did you find any issues other than the one in 120308? If not, I think this is rarely an issue in practice and not worth making legitimate cases uglier for.

2 1

Re: ddraw/tests: Fix function name in multiple ok() messages. (resend)
by Henri Verbeet 16 Mar '16

16 Mar '16

On 7 March 2016 at 08:40, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > I assume this patch was missed somehow, resending. > No, the patch is just not very useful.

3 3

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture.
by Henri Verbeet 16 Mar '16

16 Mar '16

On 15 March 2016 at 22:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > dlls/d3drm/Makefile.in | 2 +- > dlls/d3drm/d3drm.c | 35 +++++-- > dlls/d3drm/d3drm_private.h | 6 ++ > dlls/d3drm/tests/d3drm.c | 22 ++++- > dlls/d3drm/texture.c | 224 ++++++++++++++++++++++++++++++++++++++++++++- > 5 files changed, 273 insertions(+), 16 deletions(-) > I briefly looked at this, and it has some issues, some perhaps more obvious than others. But let's work on the first patch in the series first.

1 0

Re: [PATCH] shell32: Implement NIM_SETVERSION in Shell_NotifyIcon()
by Roman Pišl 16 Mar '16

16 Mar '16

Hello, thank you for paying attention to this patch. Please, give me a hint how should I split the patch. Should I create three separate patches - shell32, explorer and winex11? I'm ready to do what is necessary. Best regards Roman Pišl On Tuesday 15 of March 2016 10:12:31 you 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 "Needs splitting". > > This means that the patch needs to be split, either because it > contains unrelated changes that should be their own separate patch, or > because it's too large for review. You need to find a way to resend > the changes in smaller chunks. > > If you do not understand the reason for this status, disagree with our > assessment, or are simply not sure how to proceed next, please ask for > clarification by replying to this email.

2 1

[RFC] winex11: Don't put a default icon on modal dialogs.
by Alex Henrie 16 Mar '16

16 Mar '16

Fixes https://bugs.winehq.org/show_bug.cgi?id=29336 when using the xfwm4 window manager. Could some other developers take a look at this patch? It passes the test program attached to the bug report, but I am not sure that it is the right way. --- dlls/winex11.drv/window.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c index 4789f98..63d256a 100644 --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -274,7 +274,7 @@ static unsigned long get_mwm_decorations( struct x11drv_win_data *data, if ((style & WS_CAPTION) == WS_CAPTION) { ret |= MWM_DECOR_TITLE | MWM_DECOR_BORDER; - if (style & WS_SYSMENU) ret |= MWM_DECOR_MENU; + if ((style & WS_SYSMENU) && data->icon_pixmap) ret |= MWM_DECOR_MENU; if (style & WS_MINIMIZEBOX) ret |= MWM_DECOR_MINIMIZE; if (style & WS_MAXIMIZEBOX) ret |= MWM_DECOR_MAXIMIZE; } @@ -603,7 +603,8 @@ static void fetch_icon_data( HWND hwnd, HICON icon_big, HICON icon_small ) { icon_big = (HICON)SendMessageW( hwnd, WM_GETICON, ICON_BIG, 0 ); if (!icon_big) icon_big = (HICON)GetClassLongPtrW( hwnd, GCLP_HICON ); - if (!icon_big) icon_big = LoadIconW( 0, (LPWSTR)IDI_WINLOGO ); + if (!icon_big && !(GetWindowLongW( hwnd, GWL_EXSTYLE ) & WS_EX_DLGMODALFRAME)) + icon_big = LoadIconW( 0, (LPWSTR)IDI_WINLOGO ); } if (!icon_small) { @@ -611,7 +612,7 @@ static void fetch_icon_data( HWND hwnd, HICON icon_big, HICON icon_small ) if (!icon_small) icon_small = (HICON)GetClassLongPtrW( hwnd, GCLP_HICONSM ); } - if (!GetIconInfo(icon_big, &ii)) return; + if (!GetIconInfo(icon_small, &ii) && !GetIconInfo(icon_big, &ii)) return; hDC = CreateCompatibleDC(0); bits = get_bitmap_argb( hDC, ii.hbmColor, ii.hbmMask, &size ); -- 2.7.3

1 0