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

Re: [PATCH v4 5/7] wined3d: Implement readback from 2D array textures using glGet[Compressed]TexImage().

by Henri Verbeet

On 22 April 2016 at 11:18, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (surface->texture_target == GL_TEXTURE_2D_ARRAY) > + { > + /* We don't expect to ever need to emulate NP2 textures when we have EXT_texture_array. */ > + if (texture->flags & WINED3D_TEXTURE_COND_NP2_EMULATED) > + { > + FIXME("Cannot download surface %p, level %u, layer %u.\n", > + surface, surface->texture_level, surface->texture_layer); > + return; > + } Note that you can enforce that in texture_init(). It currently checks for WINED3DUSAGE_LEGACY_CUBEMAP, but it would be easy to check the layer count instead.

April 22, 2016

Re: [PATCH] qedit: List parameters in order in create function traces.

by Andrew Eikum

Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> Thanks. Just for my own information, are you working in this area? I'm working on video embedding in Office 2010 (Bug 40179) at the moment. Andrew On Fri, Apr 22, 2016 at 12:18:00AM -0600, Alex Henrie wrote: > Cc: Andrew Eikum <aeikum(a)codeweavers.com> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/qedit/mediadet.c | 2 +- > dlls/qedit/samplegrabber.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/qedit/mediadet.c b/dlls/qedit/mediadet.c > index 9098223..53ab75a 100644 > --- a/dlls/qedit/mediadet.c > +++ b/dlls/qedit/mediadet.c > @@ -640,7 +640,7 @@ static const IMediaDetVtbl IMediaDet_VTable = > HRESULT MediaDet_create(IUnknown * pUnkOuter, LPVOID * ppv) { > MediaDetImpl* obj = NULL; > > - TRACE("(%p,%p)\n", ppv, pUnkOuter); > + TRACE("(%p,%p)\n", pUnkOuter, ppv); > > obj = CoTaskMemAlloc(sizeof(MediaDetImpl)); > if (NULL == obj) { > diff --git a/dlls/qedit/samplegrabber.c b/dlls/qedit/samplegrabber.c > index e9e4906..946dba9 100644 > --- a/dlls/qedit/samplegrabber.c > +++ b/dlls/qedit/samplegrabber.c > @@ -1262,7 +1262,7 @@ HRESULT SampleGrabber_create(IUnknown *pUnkOuter, LPVOID *ppv) > ISeekingPassThru *passthru; > HRESULT hr; > > - TRACE("(%p,%p)\n", ppv, pUnkOuter); > + TRACE("(%p,%p)\n", pUnkOuter, ppv); > > obj = CoTaskMemAlloc(sizeof(SG_Impl)); > if (NULL == obj) { > -- > 2.8.0 >

April 22, 2016

Re: [PATCH] dwrite: Implement newer version of CreateFontFromLOGFONT()

by Jacek Caban

Hi Nikolay, On 04/21/16 19:48, Nikolay Sivov wrote: > + hr = IDWriteFontCollection_FindFamilyName(collection, logfont->lfFaceName, &index, &exists); > + if (FAILED(hr)) { > + IDWriteFontCollection_Release(collection); > + goto done; > + } You release collection twice in error path. Cheers, Jacek

April 22, 2016

Re: Wine's forked version of fontforge

by Alexandre Julliard

Jens Reyer <jre.winesim(a)gmail.com> writes: > Wine and Debian are both using the quite old fontforge version > 20120731-b, the patches apply cleanly in Debian. > But upstream is actively developing and in Debian someone is working on > packaging a recent version (not sure with what outcome, e.g. afaik there > is at least one upstream regression blocking an update). > Are there any plans in Wine to update to a newer version? No plans currently, but I can certainly look into it if it helps. > 1. Various hacks to avoid putting timestamps in generated files (AJ). > > No relevant changes upstream, but there is some work going to allow one > to specify the timestamp in order to get the build > deterministic/reproducible. Would this make this patch obsolete? > > I don't know why upstream wants timestamps at all, nor what problems > these cause for Wine. Is this Wine specific, or would it make sense to > drop timestamping upstream, too? I don't know why they'd want timestamps either; an option to set the timestamp could certainly work, though getting rid of them would be even better IMO. It's needed in Wine because the files are in git (to avoid requiring fontforge at build time), and I don't want spurious diffs every time I run make. > 2. - Avoid outputting trailing spaces in sfd files (AJ). > > About a third seems to be applied in 20160404. I assume the rest would > still be relevant if Wine updated its fontforge version. > > Is this patch only relevant for creating fonts/glyphs, but not for > building the TrueType fonts? > Looks like a good candidate for forwarding to upstream. Same here, it's to avoid spurious diffs, especially since git will then remove the spaces again when applying patches etc. It should make no difference when building the ttf files. > 3. Enable the width of individual bitmap strikes to be altered (Huw Davies). > > Since the import of upstream version 20120731-b this patch only has a > third of its original size. Are the remaining Wine changes still > necessary, or are they cruft? If still needed, I guess they should be > pushed upstream. > > In 20160404 not much seems to have changed, but the containing file > bitmapview.c was moved ("splitting ui code from fontforge/ to > fontforgeexe/"). > > Same as above: is this only needed when creating fonts? Looks like a > candidate for upstream. I believe it's still needed, I'm not sure why that part didn't get upstream. > 4. Don't save the selected state. (Huw Davies) > > I found no relevant changes upstream. > No idea about this. I believe this is also to avoid diffs when working on the files. There are other things like the fontforge window size that are saved in the sfd files. Currently I remove them from the diff manually, but it would certainly be nice to fix that upstream too. -- Alexandre Julliard julliard(a)winehq.org

April 22, 2016

Re: [04/10] webservices: Add support for reading double values.

by Hans Leidekker

On Fri, 2016-04-22 at 09:42 +0200, Hans Leidekker wrote: Please disregard this patch, Henri pointed out a problem with the use of strtod.

April 22, 2016

Re: kernel32/tests: Add initial tests for GetConsoleFontInfo

by Hugh McMaster

On Thursday, 21 April 2016 11:51 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=22421 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 851146013 console.c:1445: Test failed: [15] Expected output count to be 0, got 851146013 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 851146013 console.c:1689: Test failed: [13] Expected output count to be 0, got 851146013 console.c:1689: Test failed: [15] Expected output count to be 0, got 851146013 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 851146013 === w864 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 844049133 console.c:1445: Test failed: [15] Expected output count to be 0, got 844049133 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 844049133 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 844049133 console.c:1689: Test failed: [15] Expected output count to be 0, got 844049133 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 844049133 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 3107847202 console.c:1445: Test failed: [15] Expected output count to be 0, got 3107847202 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 3107847202 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 3107847202 console.c:1689: Test failed: [15] Expected output count to be 0, got 3107847202 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 3107847202 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w864 (64 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 These are existing failures.

April 22, 2016

Re: [PATCH] wined3d: Add detection for NVIDIA GTX TITAN Series

by Henri Verbeet

On 22 April 2016 at 09:55, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > @@ -1764,7 +1768,9 @@ cards_nvidia_binary[] = > {"GeForce 830M", CARD_NVIDIA_GEFORCE_830M}, /* GeForce 800 - mobile */ > {"GeForce 820M", CARD_NVIDIA_GEFORCE_820M}, /* GeForce 800 - mobile */ > {"GTX 780 Ti", CARD_NVIDIA_GEFORCE_GTX780TI}, /* Geforce 700 - highend */ > - {"GTX TITAN Black", CARD_NVIDIA_GEFORCE_GTXTITAN}, /* Geforce 700 - highend */ > + {"GTX TITAN", CARD_NVIDIA_GEFORCE_GTXTITAN}, /* Geforce 700 - highend */ > + {"GTX TITAN Black", CARD_NVIDIA_GEFORCE_GTXTITANB}, /* Geforce 700 - highend */ > + {"GTX TITAN Z", CARD_NVIDIA_GEFORCE_GTXTITANZ}, /* Geforce 700 - highend */ That doesn't work. The strings are matched in order, so once "GTX TITAN" is matched, "GTX TITAN Black" and "GTX TITAN Z" won't even be tried.

April 22, 2016

Re: Use todo_wine_if() 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=22441 Your paranoid android. === w7u (32 bit capture) === capture.c:181: Test failed: Position 1719 expected 0 capture.c:231: Test failed: Position 3063 expected 2167 capture.c:262: Test failed: Position 3063 expected 2167 capture.c:324: Test failed: Position 4407 gap 1792 capture.c:348: Test failed: Position 5751 expected 4855 capture.c:373: Test failed: Position 7095 expected 5303 === w7pro64 (32 bit capture) === capture.c:424: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 === w8 (32 bit capture) === capture.c:231: Test failed: Position 2167 expected 567 capture.c:262: Test failed: Position 2167 expected 567 capture.c:324: Test failed: Position 3191 gap 2176 capture.c:328: Test failed: GCP 13440 vs. BufferSize 21996 capture.c:348: Test failed: Position 4279 expected 3639 capture.c:373: Test failed: Position 5303 expected 4087 capture.c:374: Test failed: flags 1 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:262: Test failed: Position 2167 expected 1463 capture.c:324: Test failed: Position 3191 gap 1280 capture.c:328: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:348: Test failed: Position 4343 expected 3639 capture.c:349: Test failed: flags 1 capture.c:373: Test failed: Position 4791 expected 4087 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:262: Test failed: Position 2167 expected 1527 capture.c:324: Test failed: Position 4151 gap 2176 capture.c:328: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:348: Test failed: Position 5239 expected 4599 capture.c:349: Test failed: flags 1 capture.c:373: Test failed: Position 5687 expected 5047 === w864 (64 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:262: Test failed: Position 2167 expected 1463 capture.c:324: Test failed: Position 3127 gap 1216 capture.c:348: Test failed: Position 4215 expected 3575 capture.c:373: Test failed: Position 5303 expected 4023 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1143 expected 0 capture.c:231: Test failed: Position 2167 expected 1591 capture.c:262: Test failed: Position 2167 expected 1591 capture.c:324: Test failed: Position 4215 gap 2176 capture.c:328: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:348: Test failed: Position 5303 expected 4663 capture.c:349: Test failed: flags 1 capture.c:373: Test failed: Position 7287 expected 5111 capture.c:374: Test failed: flags 1

April 22, 2016

Re: [1/2] shell32: Check IsWow64Process() before calling Wow64 functions.

by Alexandre Julliard

"Olivier F. R. Dierick" <o.dierick(a)piezo-forte.be> writes: > Ok, the patch does not fix bug 36838. I'll follow your recommandation > and make another one. > > Still, I found code that generates errors for no purpose on 32 bit wine > and made a patch to fix it, avoiding possible error leaks and side > effects. Will it be considered? In general, errors generated in internal code paths don't matter. If the function fails in the end, it should set a proper error code. If it doesn't fail, the error code is irrelevant and isn't supposed to be checked by the app. In cases where an app mistakenly does check it, again we have to set it explicitly. Complicating internal code paths to avoid changing last error is not worth the trouble; in many cases the same thing happens on Windows anyway. -- Alexandre Julliard julliard(a)winehq.org

April 21, 2016

Wine's forked version of fontforge

by Jens Reyer

Hi, in Debian we're currently moving to enable the maintainer mode to e.g. rebuild Wine's TrueType fonts. AJ already warned us that this is risky: On 04/01/2016 04:54 AM, wine-bugs(a)winehq.org wrote: > https://bugs.winehq.org/show_bug.cgi?id=40391 > > --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- > There is definitely a risk too, particularly for fonts. They are supposed to be > built with our forked version of fontforge > (https://source.winehq.org/git/fontforge.git) that contains a couple of fixes > compared to the upstream version. I really appreciate that warning, thanks again! See a "short" explanation at the end of the mail, why we want to do this anyway. I'd like to figure out how to improve the resulting situation by getting the Wine changes to fontforge applied upstream (and/or in Debian). With "upstream" I mean github.com/fontforge. I will contact them in a later step. Wine and Debian are both using the quite old fontforge version 20120731-b, the patches apply cleanly in Debian. But upstream is actively developing and in Debian someone is working on packaging a recent version (not sure with what outcome, e.g. afaik there is at least one upstream regression blocking an update). Are there any plans in Wine to update to a newer version? Wine's fontforge has 4 changes. I recreated them based on AJ's merge for 20120731-b and by myself for 20160404 to get a *rough* picture of their current state (not tested and I'm absolutely no expert in this): 1. Various hacks to avoid putting timestamps in generated files (AJ). No relevant changes upstream, but there is some work going to allow one to specify the timestamp in order to get the build deterministic/reproducible. Would this make this patch obsolete? I don't know why upstream wants timestamps at all, nor what problems these cause for Wine. Is this Wine specific, or would it make sense to drop timestamping upstream, too? 2. - Avoid outputting trailing spaces in sfd files (AJ). About a third seems to be applied in 20160404. I assume the rest would still be relevant if Wine updated its fontforge version. Is this patch only relevant for creating fonts/glyphs, but not for building the TrueType fonts? Looks like a good candidate for forwarding to upstream. 3. Enable the width of individual bitmap strikes to be altered (Huw Davies). Since the import of upstream version 20120731-b this patch only has a third of its original size. Are the remaining Wine changes still necessary, or are they cruft? If still needed, I guess they should be pushed upstream. In 20160404 not much seems to have changed, but the containing file bitmapview.c was moved ("splitting ui code from fontforge/ to fontforgeexe/"). Same as above: is this only needed when creating fonts? Looks like a candidate for upstream. 4. Don't save the selected state. (Huw Davies) I found no relevant changes upstream. No idea about this. Why are we doing this? ---------------------- The Debian Free Software Guidelines [DFSG] (which are the fundamental basis for the Debian project) mandate that binaries must be accompanied by their source (which is usually ensured by building from source), and that you must be able to modify and redistribute the package with only the software available in Debian. The reasons for these are e.g. philosophical (empowering the user), QA (rebuilding if there was an issue in the build tools), reproducibility (recreate byte-by-byte-identically, e.g. to rule out attacks at a build machine or do QA) or security (a build from correct source code may be manipulated by specific compilers). The TrueType fonts are pre-built with a forked fontforge, which isn't (and very unlikely will ever be) in Debian. To package the pre-built fonts imo we would have to remove Wine from official Debian (main), and move it to the non/semi-official contrib section. For the same reason (AFAIK, I'm not the author of these changes) we're also regenerating opengl files, request code and unicode. This problem was ignored/missed in the past for the Debian Wine packages, yet this is no argument against fixing them now. We definitely don't want Wine removed from Debian, instead keep it in and get it there as good as possible. btw, we're also adding a patch (based on wine staging) to append '(Debian)' to the version string now. btw2, can you recommend some alternative free fonts to install (either as partial replacement or as extension to the Wine fonts)? Greets, and thanks in advance jre [DFSG] https://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg, see also the following chapter "The main archive area".

April 21, 2016