November 2014 - Wine-Devel - list.winehq.org

Re: Update dmFormName when changing paper size in print ui. (resend)

by Nikolay Sivov

On 20.11.2014 10:42, Ralf Habacker wrote: > - if(Sel != CB_ERR) > + if(Sel != CB_ERR) { > lpdm->u1.s1.dmPaperSize = SendDlgItemMessageW(hDlg, cmb2, > CB_GETITEMDATA, > Sel, 0); > + GetDlgItemTextW(hDlg, cmb2, lpdm->dmFormName, sizeof(lpdm->dmFormName)); > + } This looks wrong, this function takes character length, not byte length.

Nov. 20, 2014

Re: [PATCH 4/5] wined3d: Don't minimize hidden Windows.

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=10357 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2476: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2481: Test failed: The focus window is active. device.c:2489: Test failed: Got unexpected hr 0x88760869. device.c:2495: Test failed: Got unexpect screen size 800x600. device.c:2510: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2519: Test failed: Got unexpect screen size 800x600. device.c:2532: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2539: Test failed: Got unexpect width 640. device.c:2540: Test failed: Got unexpect height 480.

Nov. 19, 2014

Re: [PATCH 2/5] wined3d: Set the device window size on focus window activation.

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=10354 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2454: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2459: Test failed: The focus window is active. device.c:2467: Test failed: Got unexpected hr 0x88760869. device.c:2473: Test failed: Got unexpect screen size 800x600. device.c:2488: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2497: Test failed: Got unexpect screen size 800x600. device.c:2633: Test failed: Expected foreground window 000500F6, got 0002004C. device.c:3009: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3013: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3036: Test failed: Failed to reset device, hr 0x88760868. device.c:3040: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3044: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3058: Test failed: Failed to set foreground window. device.c:3062: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:3066: Test failed: Expected device window extended style 0x108, got 0x100.

Nov. 19, 2014

Re: d3dcompiler_43: Remove a no-op statement (PVS-Studio)

by Henri Verbeet

On 19 November 2014 17:34, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > As you wish, I'll drop the patch. But IMHO D3DSRO_POSITION is not a flag but > just the default when no flag is set. > It's an index / offset.

Nov. 19, 2014

Re: d3dcompiler_43: Remove a no-op statement (PVS-Studio)

by Michael Stefaniuc

On 11/19/2014 03:21 PM, Matteo Bruni wrote: > 2014-11-19 9:10 GMT+01:00 Michael Stefaniuc <mstefani(a)redhat.de>: >> D3DSRO_POSITION is 0. > > Yes, it is 0, but I still feel like it should stay there for > consistency with the other cases. As you wish, I'll drop the patch. But IMHO D3DSRO_POSITION is not a flag but just the default when no flag is set. > What I mean is that if that line is removed I'm pretty sure I'd be > like "oh wow, this is clearly broken" every time I happen to look at > that piece of code. But maybe that's just me. For a split second I was thinking to replace it with a comment but that wouldn't have increased the acceptance probability. bye michael > >> --- >> dlls/d3dcompiler_43/bytecodewriter.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/dlls/d3dcompiler_43/bytecodewriter.c b/dlls/d3dcompiler_43/bytecodewriter.c >> index 46187f9..71ee6c1 100644 >> --- a/dlls/d3dcompiler_43/bytecodewriter.c >> +++ b/dlls/d3dcompiler_43/bytecodewriter.c >> @@ -855,7 +855,6 @@ static DWORD map_vs_output(struct bc_writer *This, DWORD regnum, DWORD mask, DWO >> *has_components = TRUE; >> if(regnum == This->oPos_regnum) { >> token |= (D3DSPR_RASTOUT << D3DSP_REGTYPE_SHIFT) & D3DSP_REGTYPE_MASK; >> - token |= D3DSRO_POSITION & D3DSP_REGNUM_MASK; /* No shift */ >> return token; >> } >> if(regnum == This->oFog_regnum && mask == This->oFog_mask) { >> -- >> 1.9.3 > > Cheers, > Matteo. > -- Michael Stefaniuc Tel.: +49-711-96437-199 Supervisor, APAC/EMEA IT Network Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters

Nov. 19, 2014

Re: [PATCH 1/2] mmdevapi: allow GetPropValue function in audio drivers (try 2)

by Andrew Eikum

Looks good, just one small note below. On Wed, Nov 19, 2014 at 02:35:14PM +0000, Mark Harmstone wrote: > + if (!drvs.pGetPropValue) > + { > + TRACE("Driver does not implement GetPropValue\n"); > + return E_NOTIMPL; > + } > + This makes the drivers without GetPropValue pretty noisy during loading. I don't think anything needs to be printed, since we'll see the TRACEs from the driver if the function is present. Andrew

Nov. 19, 2014

Re: [PATCH 2/2] winealsa: implement GetPropValue and return device path (try 2)

by Andrew Eikum

Looking pretty good. Couple notes below. On Wed, Nov 19, 2014 at 02:35:39PM +0000, Mark Harmstone wrote: > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index 5ad72f9..c21fd0c 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -3823,3 +3823,107 @@ HRESULT WINAPI AUDDRV_GetAudioSessionManager(IMMDevice *device, > > return S_OK; > } > + > +enum AudioDeviceConnectionType { > + AudioDeviceConnectionType_Unknown = 0, > + AudioDeviceConnectionType_PCI, > + AudioDeviceConnectionType_USB > +}; > + > +HRESULT WINAPI AUDDRV_GetPropValue(GUID *guid, const PROPERTYKEY *prop, PROPVARIANT *out) > +{ > + static const PROPERTYKEY devicepath_key = { /* undocumented? - {b3f8fa53-0004-438e-9003-51a46e139bfc},2 */ > + {0xb3f8fa53, 0x0004, 0x438e, {0x90, 0x03, 0x51, 0xa4, 0x6e, 0x13, 0x9b, 0xfc}}, 2 > + }; > + > + static const char dev_info[] = "/sys/class/sound/card%u/device/uevent"; > + I'd prefer "const char *" and actually, is there any reason not to just put this string straight in the sprintf? > + TRACE("%s, (%s,%u), %p\n", wine_dbgstr_guid(guid), wine_dbgstr_guid(&prop->fmtid), prop->pid, out); > + > + if(IsEqualGUID(&prop->fmtid, &devicepath_key.fmtid) && prop->pid == devicepath_key.pid) > + { I think you can use IsEqualPropertyKey here. > + char name[256], uevent[MAX_PATH]; > + EDataFlow flow; > + FILE *fuevent; > + int card, device; > + > + if(!get_alsa_name_by_guid(guid, name, sizeof(name), &flow)) > + { > + WARN("Unknown interface %s\n", debugstr_guid(guid)); > + return E_NOINTERFACE; > + } > + > + /* only implemented for identifiable devices, i.e. not "default" */ > + if(!sscanf(name, "plughw:%u,%u", &card, &device)) > + return E_NOTIMPL; > + > + sprintf(uevent, dev_info, card); > + fuevent = fopen(uevent, "r"); > + > + if(fuevent){ > + enum AudioDeviceConnectionType connection = AudioDeviceConnectionType_Unknown; > + USHORT vendor_id = 0, product_id = 0; > + char *line = NULL; > + > + while (!feof(fuevent)) { > + char *val; > + size_t val_len, len = 0; > + > + getline(&line, &len, fuevent); > + We should probably break on failure here. > + if((val = strchr(line, '='))) { > + val[0] = 0; > + val++; > + > + val_len = strlen(val); > + if (val_len > 0 && val[val_len - 1] == '\n') { val[val_len - 1] = 0; } > + > + if(!strcmp(line, "PCI_ID")){ > + connection = AudioDeviceConnectionType_PCI; > + sscanf(val, "%hX:%hX", &vendor_id, &product_id); > + }else if (!strcmp(line, "DEVTYPE") && !strcmp(val,"usb_interface")) > + connection = AudioDeviceConnectionType_USB; > + else if (!strcmp(line, "PRODUCT")) > + sscanf(val, "%hx/%hx/", &vendor_id, &product_id); > + } > + } Can we do anything sane on sscanf failure here? Maybe dump a WARN and revert back to AudioDeviceConnectionType_Unknown. Is that preferable to falling back on 0 for one or more of the IDs? Andrew

Nov. 19, 2014

Re: [2/2] vssapi: Add stub implementations for a couple of functions.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/vssapi/main.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/vssapi/vssapi.spec | 10 +++--- > include/Makefile.in | 1 + > include/vss.idl | 31 ++++++++++++++++++ > include/vswriter.h | 47 ++++++++++++++++++++++++++++ > 5 files changed, 167 insertions(+), 5 deletions(-) > create mode 100644 include/vss.idl > create mode 100644 include/vswriter.h It doesn't build on Mingw: ../../../wine/dlls/vssapi/main.c:33:0: warning: "__thiscall" redefined [enabled by default] <built-in>:0:0: note: this is the location of the previous definition main.o:main.c:(.text+0x14): undefined reference to `_VSSAPI_CVssWriter_Initialize(a)36' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed -- Alexandre Julliard julliard(a)winehq.org

Nov. 19, 2014

Re: [2/2] wined3d: Take abs() of vertex z coordinate as FFP fog coordinate (try 7)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-14 22:40, schrieb Joachim Priesner: > Take the absolute value of vertex.z as fog coordinate instead of > just the z coordinate. This fixes e.g. fog for applications that > use right-handed projection matrices. > > Also test the clamp behavior of the oFog vertex shader output. Fwiw, the start / end tests look good to me, and the results match what I expected. However I think Henri still disagrees with this patch. Henri, I'd appreciate if you would say what you want. Without that I can offer Joachim only guesswork. My guess is that the test is too complex. There are some parts that are technically not required to demonstrate the correctness of the abs(), but I see some value in the additional checks: *) The "interrupted" quad with extra vertices at z = 0. It shows that the fully fogged other quad is not a result of the interpolation failing entirely and producing INF or NaN. *) The foggy shader test: It shows how negative values coming from vertex shaders are treated. It's just logical to test this considering the behavior of the fixed function pipeline. *) The manual fog coord / unfogged shader tests: Those could be removed I guess, although at least the manual fog coord test shows that there isn't some unexpected interference with negative depth values. Joachim, I can offer you that I try to simplify those tests. If you're still motivated to work on this I'm happy to leave this up to you though. Some ideas for simplifying the test, but I don't know yet if they'll work: *) Split the shader and fixed function tests into separate tests. *) Remove the interpolation tests from the fixed function tests. fog_interpolation_test shows that the fog equation is evaluated in the vertex pipeline in the affected cases, and the fogstart = -1, fogend = 0 test shows that the abs() happens before the fog equation. So I think removing this part of the test for the fixed function part is safe. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUbK/nAAoJEN0/YqbEcdMworwP/2OytnoHiSrHWoFK9YPUvEGQ XIyIDZhe/PoMKaBGRdgqFWd4EjoVr9haUmCcPWb1BK/0R2MVSTIK0TS88RlotiMx ZIBcJJWCiiBvhNrydAW5Qqg/80h5UOgaumkWdi2qF4SfkvP/A3jLXvulXZaOU88k rmnlWXxiQun0EIMzShzms0OZmKxmyKkhm84CXAAr3hIh3k9anXVsr0Nsgi2UXTBl ey55rNaE/NBZdNMP/in/5kEq76f0WA7bx1CV2zfCds5p34thQPQLjuvYQ0mqz3Qg zo24W/J52m70W1GmqD/J2+4g5XPO2Gf3xIjV0NyJW988hsCoHIyQHFXZbRkZQpbQ ULdhBq6VgW6O9d1f9H1hy18HxVwlGPFjnu7gniMTWqtBLzyC3b6pppSqQfg1zRhj X/Njp/JBhSUWe8is4sP2R7sHl2fqMi5ROWQyXVpca/rUdoiu6dAH8zYo3IqepGDW P1RoSiwQXXDEh0tV/gzW7pVnk7nNRtcL6el0R5C7aqrytWi3xLXYfdsug6sluKK6 onN/Iz0PpBDsokaTFUMua1JgZ8fx7+Av/S/2xfPvMpSFyrp+q/Q4fw5HdQEKfCIb +JtA03sG0ZfKLjCWL3JRW2kt3G3TxQTOdaJ+Dic5S50xMjs04Ze2Ie3BzbY4FEn0 ZqXciJ+kIVCN4+LD5aJp =RHD+ -----END PGP SIGNATURE-----

Nov. 19, 2014

Re: d3dcompiler_43: Remove a no-op statement (PVS-Studio)

by Matteo Bruni

2014-11-19 9:10 GMT+01:00 Michael Stefaniuc <mstefani(a)redhat.de>: > D3DSRO_POSITION is 0. Yes, it is 0, but I still feel like it should stay there for consistency with the other cases. What I mean is that if that line is removed I'm pretty sure I'd be like "oh wow, this is clearly broken" every time I happen to look at that piece of code. But maybe that's just me. > --- > dlls/d3dcompiler_43/bytecodewriter.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/dlls/d3dcompiler_43/bytecodewriter.c b/dlls/d3dcompiler_43/bytecodewriter.c > index 46187f9..71ee6c1 100644 > --- a/dlls/d3dcompiler_43/bytecodewriter.c > +++ b/dlls/d3dcompiler_43/bytecodewriter.c > @@ -855,7 +855,6 @@ static DWORD map_vs_output(struct bc_writer *This, DWORD regnum, DWORD mask, DWO > *has_components = TRUE; > if(regnum == This->oPos_regnum) { > token |= (D3DSPR_RASTOUT << D3DSP_REGTYPE_SHIFT) & D3DSP_REGTYPE_MASK; > - token |= D3DSRO_POSITION & D3DSP_REGNUM_MASK; /* No shift */ > return token; > } > if(regnum == This->oFog_regnum && mask == This->oFog_mask) { > -- > 1.9.3 Cheers, Matteo.

Nov. 19, 2014