June 2015 - Wine-Devel - list.winehq.org

Re: Fix GetRawInputDeviceList() to return ERROR_INSUFFICIENT_BUFFER

by Andrew Eikum

On Wed, May 27, 2015 at 03:23:40PM +0900, Andrew Church wrote: > (Note: I am not subscribed to the list; please CC me on any replies.) > Looks like your patch got stuck in moderation for a week because you aren't subscribed. Bruno Jesus beat you to submitting it: http://source.winehq.org/git/wine.git/commitdiff/e0ba6d8fdb9562810231df8fb0… Thanks for contributing to Wine, Andrew

June 1, 2015

Re: gdi32: Return default palette entries from GetSystemPaletteEntries for non-palette-based devices. (try 2)

by Sebastian Lackner

On 01.06.2015 17:51, Anton Baskanov wrote: > + if (entries && start < 256) > + { > + UINT i; > + const RGBQUAD *default_entries; > + > + if (start + count > 256) count = 256 - start; > + > + default_entries = get_default_color_table( 8 ); > + for (i = 0; i < count; ++i) > + { > + if (i < 10 || i >= 246) > + { That condition is obviously wrong. Feel free to merge the changes and additional tests from my improved patchset which is included in Wine-Staging: https://github.com/wine-compholio/wine-staging/blob/master/patches/gdi32-De… > + entries[i].peRed = default_entries[start + i].rgbRed; > + entries[i].peGreen = default_entries[start + i].rgbGreen; > + entries[i].peBlue = default_entries[start + i].rgbBlue; > + } > + else > + { > + entries[i].peRed = 0; > + entries[i].peGreen = 0; > + entries[i].peBlue = 0; > + } > + entries[i].peFlags = 0; > + }

June 1, 2015

Re: [PATCH] mshtml: add NULL check to avoid crashing due to Gecko bug

by Jacek Caban

On 06/01/15 13:11, Indrek Altpere wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=34808 > > There seems to be a known bug in Gecko engine that causes iframe with display:none contents to return NULL nsstyle from nsIDOMWindow_GetComputedStyle > https://bugzilla.mozilla.org/show_bug.cgi?id=548397 > --- > dlls/mshtml/htmlcurstyle.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/mshtml/htmlcurstyle.c b/dlls/mshtml/htmlcurstyle.c > index 5f6cb35..f0b0d98 100644 > --- a/dlls/mshtml/htmlcurstyle.c > +++ b/dlls/mshtml/htmlcurstyle.c > @@ -1343,6 +1343,11 @@ HRESULT HTMLCurrentStyle_Create(HTMLElement *elem, IHTMLCurrentStyle **p) > return E_FAIL; > } > > + if(!nsstyle) { > + ERR("GetComputedStyle returned NULL nsstyle\n"); > + return E_FAIL; > + } We could try to work around the problem in Gecko, but it's obviously even better if it's fixed in Gecko. Anyway, if it fixes a bug I'm fine with the patch as is. Thanks, Jacek

June 1, 2015

Re: [PATCH] mshtml: add NULL check to get_frame_by_name

by Jacek Caban

On 05/29/15 15:51, Indrek Altpere wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=34982 > --- > dlls/mshtml/htmlwindow.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index 618648e..c53ea16 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -406,6 +406,11 @@ HRESULT get_frame_by_name(HTMLOuterWindow *This, const WCHAR *name, BOOL deep, H > > nsIDOMWindow_Release(nswindow); > > + if(!window_iter) { > + WARN("nsIDOMWindow without HTMLOuterWindow: %p\n", nswindow); > + continue; > + } > + The real question is why there is no HTMLOuterWindow created for given window, but I'm fine with the patch. Thanks, Jacek

June 1, 2015

Re: [PATCH 1/3] ntdll: Implemenent ObjectTypeInformation class support in NtQueryObject.

by Nikolay Sivov

On 01.06.2015 12:52, Qian Hong wrote: > +/* Query object type name information */ > +(a)REQ(get_object_typename) > + obj_handle_t handle; /* handle to the object */ > +(a)REPLY > + data_size_t total; /* needed size for type name */ > + VARARG(typename,unicode_str); /* type name */ > +(a)END > + Also, do we really need to transfer a string? It seems to be that you can use an index and a static array at ntdll side.

June 1, 2015

Re: [PATCH 1/3] ntdll: Implemenent ObjectTypeInformation class support in NtQueryObject.

by Nikolay Sivov

On 01.06.2015 12:52, Qian Hong wrote: > Hi, > > This patch fixed QQ crashing on recent Wine. Thanks Sebastian for > improving my patch. > Tested with wine-staging for weeks. > > --- > dlls/ntdll/om.c | 64 > +++++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/tests/om.c | 28 +++++++++++----------- > server/directory.c | 5 ---- > server/handle.c | 18 +++++++++++++++ > server/object.h | 5 ++++ > server/protocol.def | 9 ++++++++ > 6 files changed, 110 insertions(+), 19 deletions(-) > > + if (!(status = server_get_unix_name( handle, &unix_name ))) > + { > + static const WCHAR type_fileW[] = {'F','i','l','e','\0'}; > + int type_size = sizeof(type_fileW); > + > + if (len < sizeof(*p)) > + status = STATUS_INFO_LENGTH_MISMATCH; > + else if (len < sizeof(*p) + type_size) > + status = STATUS_BUFFER_OVERFLOW; > + else > + { > + p->TypeName.Buffer = (WCHAR *)(p + 1); > + p->TypeName.Length = type_size - sizeof(WCHAR); > + p->TypeName.MaximumLength = type_size; > + memcpy( p->TypeName.Buffer, type_fileW, type_size ); > + > + } > + if (used_len) *used_len = sizeof(*p) + type_size; > + RtlFreeAnsiString( &unix_name ); > + break; > + } Why do you need a separate server call/special case for files?

June 1, 2015

Re: [PATCH] Do not run update-desktop-database on make install/uninstall

by Jerome Leclanche

On 1 June 2015 at 10:50, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Not all of us install Wine through a package manager, and > update-desktop-database is useful in that case. What that Makefile > should probably be doing instead, is calling update-desktop-database > only on the desktop directory where wine.desktop was just installed, > where it will succeed without root privileges, ie.: > -$(UPDATE_DESKTOP_DATABASE) $(DESTDIR)$(datadir)/applications > > Thank you > Damjan > That's technically more correct but even worse, because building a package (make install into a DESTDIR you will merely tarball) will result in desktop db pollution. make install really shouldn't run u-d-d at all - if you do make install and *want* to get desktop associations, you can run it after make install, separately. J. Leclanche

June 1, 2015

Re: [PATCH] Do not run update-desktop-database on make install/uninstall

by Damjan Jovanovic

Not all of us install Wine through a package manager, and update-desktop-database is useful in that case. What that Makefile should probably be doing instead, is calling update-desktop-database only on the desktop directory where wine.desktop was just installed, where it will succeed without root privileges, ie.: -$(UPDATE_DESKTOP_DATABASE) $(DESTDIR)$(datadir)/applications Thank you Damjan On Sun, May 31, 2015 at 8:12 AM, Jerome Leclanche <jerome(a)leclan.ch> wrote: > This causes root invocations of "make install" in a chroot to error > It is the maintainer's or the package manager's job to run it, instead. > > Fixes bug #35191 > > J. Leclanche > > >

June 1, 2015

Re: [PATCH] wined3d: fix color in range comparison

by Nikolay Sivov

On 27.05.2015 20:12, Sergey Isakov wrote: > I think the patch must be accepted because original codes are more wrong. > > Tests will be created when WINED3D_CKEY_COLORSPACE will be implemented. Tests are needed to prove that your patch is correct. > > The game affected is in bug 38581. > > Meanwhile, the policy to reject any patches is not constructive. > If one developer propose not perfect codes then next developer can > correct them and obtain a result. > If you rejected the first developer then you will not have a result. That's not how it works. > > Best wishes! > > > On 27 мая 2015 г., at 10:39, Stefan Dösinger <stefandoesinger(a)gmail.com > <mailto:stefandoesinger(a)gmail.com>> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2015-05-26 um 14:41 schrieb Sergey Isakov: >>> +#define RED_KEY(x) (x & 0xff0000) >>> +#define GREEN_KEY(x) (x & 0x00ff00) >>> +#define BLUE_KEY(x) (x & 0x0000ff) >>> + return ((RED_KEY(color) >= >>> RED_KEY(color_key->color_space_low_value)) && >>> + (RED_KEY(color) <= >>> RED_KEY(color_key->color_space_high_value)) && >>> + (GREEN_KEY(color) >= >>> GREEN_KEY(color_key->color_space_low_value)) && >>> + (GREEN_KEY(color) <= >>> GREEN_KEY(color_key->color_space_high_value)) && >>> + (BLUE_KEY(color) >= >>> BLUE_KEY(color_key->color_space_low_value)) && >>> + (BLUE_KEY(color) <= >>> BLUE_KEY(color_key->color_space_high_value))); >>> +#undef RED_KEY >>> +#undef GREEN_KEY >>> +#undef BLUE_KEY >> The basic idea is most likely right, but it needs tests. Do you have a >> game that needs this behavior? >> >> The way you're extracting individual colors from the key is wrong. The >> bitmasks depend on the texture format. >> >> The code you're modifying is unused on any modern GPU. On GPUs that >> support ARB_fragment_program or GLSL we do the color key comparison in >> the fragment shader nowadays. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBAgAGBQJVZXSWAAoJEN0/YqbEcdMwbEUP/RM4QUsbdSzhSLyIz5j00Epb >> AW1ZcNOg61yrfymjHdhJkqfdNmEiKQFsRshD+ZQAxVHqMsZLTxXtRFfBB14WtmNI >> Ng5jwwiAzDqlmpjftlZ4CmkR1w7DMxH6Nt4e9OQBlDKShSIoGngL6RremV+2Wq+f >> nNC6HfdmUiAIReVvI2aMm5B9C5L624SKLvoAZNI8QW+HJeZeESSGmT9bx4IRVQwl >> QX+aKojT43CJwq6UpZRu7ZkniotrmO9aDC+6S3S0od0ZJWSP5Q9upCNWNcN+iPG7 >> 9kCPwZMsEAxNUjvh/wQx8xE1+wiR7Ugjl/X6yTN8HFesFHChrqC2UeHUAkUKU++L >> WC4kwijfbktKSZnIiSvrTAzWvLOeCZMifFQqm8aqmlOqyvbNwyOJjh6yM/nqZi+c >> 2aEdEIMY5aaoswDIlyGRRN57zeWtqjZVmg7UzVxmZqfiocmUVxgdmdRv8BvFi0RF >> R4A6YTDP5EYb33SvH3qQE5kIrtDdtL8qtanmBsuHnhhwd1rdgeeq/9N0tqSjH1GQ >> s8vsXVmd3qU+mQMzyaxN9Cc9RGxGNgd+g1LkkoPqe+aVUw/JDzvAdMDGpy63zjhM >> QUlfS771f+Zt43wku/20XP1engXXti4m+KfnSOS3nCdKO1xRKOGHAMlUZzd8+jhU >> 2rWKuh42D3mSMDk1OhLR >> =IdO/ >> -----END PGP SIGNATURE----- > > > >

June 1, 2015

Re: [PATCH 2/2] d3d9/test: implemented tests for UpdateTexture method

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=13726 Your paranoid android. === w8 (32 bit visual) === visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 0, 8. visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 1, 8. visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 2, 8.

June 1, 2015