September 2015 - Wine-devel

Re: gdi32/tests: Avoid excessive traces for fonts with OS/2 version 4 tables
by Marvin 10 Sep '15

10 Sep '15

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=16629 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 6/8] wined3d: replace wined3d_surface_preload with wined3d_texture_preload
by Henri Verbeet 10 Sep '15

10 Sep '15

On 9 September 2015 at 12:23, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static void WINAPI d3d9_surface_PreLoad(IDirect3DSurface9 *iface) > { > struct d3d9_surface *surface = impl_from_IDirect3DSurface9(iface); > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; > + > wined3d_mutex_lock(); > - wined3d_surface_preload(surface->wined3d_surface); > + wined3d_texture_preload(texture->wined3d_texture); > wined3d_mutex_unlock(); > } > This isn't necessarily wrong, but it may be too complicated. In particular, at some point we'll have to do maps for e.g. off-screen plain surfaces as well, and then you can't avoid getting the wined3d texture from somewhere. That probably means either creating an implicit d3d9 texture for those surfaces, or just storing a pointer to the wined3d texture in the d3d9 surface. So I'd like to see map()/unmap() before preload().

2 1

Re: po: Update Lithuanian translation
by Nikolay Sivov 10 Sep '15

10 Sep '15

Not specific to Lithuanian, I just want to mention context this new translatable string is in, that could help translators: > #: oledlg.rc:36 > -#, fuzzy > -#| msgid "&Object" > msgid "%1 %2 &Object" > -msgstr "&Objektas" > +msgstr "%1 %2 &objektas" %1 here is a verb that application provides - an action performed on Object (e.g. Open), %2 is for application provided object name/type action is performed on. So for English it could be something like "Open Bitmap Object". Some locales use different word order, that's why I used indexed argument format, see for example Korean https://bugs.winehq.org/show_bug.cgi?id=39243: > "test \ac1c\ccb4 verb(&O)" 'test' is object type, and 'verb' is a string for verb.

1 0

Re: [PATCH 5/8] ddraw/tests: add test for surface preload
by Marvin 10 Sep '15

10 Sep '15

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=16604 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7: unhandled exception c0000005 at 68084F1E

1 0

Re: [PATCH 4/8] d3d9/tests: add test for surface preload
by Marvin 10 Sep '15

10 Sep '15

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=16603 Your paranoid android. === w2000pro (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wxppro (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w2003std (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wvistau64 (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w2008s64 (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w7u (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wvistau64 (64 bit device) === device: unhandled exception c0000005 at 0000000000419CD8 === w2008s64 (64 bit device) === device: unhandled exception c0000005 at 0000000000419CD8

1 0

Re: msi: Check HKLM/Software/Classes/Installer/Components path while looking for components
by Marvin 09 Sep '15

09 Sep '15

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=16596 Your paranoid android. === w2008s64 (32 bit action) === action.c:5915: Test failed: MsiProvideQualifiedCompontent returned 1607

1 0

Re: [PATCH 4/8] d3d9/tests: add test for surface preload
by Stefan Dösinger 09 Sep '15

09 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have some nitpicky style comments. I don't demand that they are addressed, I'm ok with the patch as it is if Henri accepts it. > + IDirect3DSurface9 *backbuffer, *stencilsurface, *offscreensurface, *rendertarget, *rendertarget2; You shouldn't need the two rendertarget variables. In fact, one common surface variable should do, and I don't think it would make the test more difficult to read. > + hr = IDirect3DDevice9_GetRenderTarget(device, 0, &rendertarget); > + ok(SUCCEEDED(hr), "GetRenderTarget failed, hr %#x.\n", hr); > + IDirect3DSurface9_PreLoad(rendertarget); > + IDirect3DSurface9_Release(rendertarget); We already know from other tests that on device creation backbuffer 0 is the render target. I don't think it's necessary to explicitly test render target 0. > + hr = IDirect3DDevice9_GetBackBuffer(device, 0, 0, 0, &backbuffer); "D3DBACKBUFFER_TYPE_MONO" would be better than "0". Yeah, I know many other tests use 0, and I just sent a patch that shows that this parameter is just ignored... Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8JlBAAoJEN0/YqbEcdMwNCkP/2aqOA8gTfOb1kE4GkaiKRYk L6sks0mVbtu0nDG/futVUEFniYzQEJNNOabBi/2vcIWFKIOpGALlKGFxbXc3MRC/ +TEIMYq9p1iOsDL1T3tMx+tR39vfG3nFh+FNcZe0nDzT1PmWU5egAdp+IXzY/rR1 qPMQiyFF3ppbvgPi16WAWvnDqHao4+YGoAUFtiiZEBKF8+xA3LiUimuyJnaHYUWj 6caXL1e/DLE/6o7dlJr1YbDmA6IDUYAi029ANv45Upyhf8VCBknpQ1YShRJ+Wt6m g96I/lRtLCpYq8Y8lLTrE6ZD9/8eRkUIxt8jzw8s+gpGtg1wwaR4Y+pzUkrqSRfR OyTzXAFDTI7hNbHfeUHw1EkrT/Ef2H66g9eoMZYVgDJM9ZmfHvgwENPjClTRO2nZ 5jCt14lhZD3Cpdw8+K6AqgPZVtZGyVs4Z0pkO9w7pcfLHTtuWAKh7NfikzXqzyAE zBJ/PtOxdY5BooCZ7ZPuQ0Dblz7wt11m+t6Y7+Jkni0qeH+EetDXDaL4G+ZbmV4V 1gZu5QOaFwNDTIrOU8W94R66oCeAx2YryQgejk4PmHN3UHO3GuQ5irUQlfOGZi/z WO2YZcU3+wCAdZXopgE7kIkaBE+Y2VWKtBUgLGPeiglApaq5SfKncALa5iPACpzN bmSeigvhzA2FKICkLYil =9uRC -----END PGP SIGNATURE-----

1 0

Re: [PATCH 5/8] ddraw/tests: add test for surface preload
by Stefan Dösinger 09 Sep '15

09 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-09 um 19:02 schrieb Riccardo Bortolato: > + hr = IDirectDraw7_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + if (FAILED(IDirectDraw7_QueryInterface(ddraw, &IID_IDirect3D7, (void **)&d3d))) > + { > + skip("D3D interface is not available, skipping test.\n"); > + goto done; > + } > + > + hr = IDirect3D7_EnumDevices(d3d, enum_devtype_cb, &hal_ok); > + ok(SUCCEEDED(hr), "Failed to enumerate devices, hr %#x.\n", hr); > + if (hal_ok) > + devtype = &IID_IDirect3DTnLHalDevice; > + > + memset(&z_fmt, 0, sizeof(z_fmt)); > + hr = IDirect3D7_EnumZBufferFormats(d3d, devtype, enum_z_fmt, &z_fmt); > + if (FAILED(hr) || !z_fmt.dwSize) > + { > + skip("No depth buffer formats available, skipping test.\n"); > + goto done; > + } > ... There is a helper function called create_device for this. > + IDirect3DDevice7_PreLoad(device, surface); This incarnation of PreLoad returns a value. It's probably always D3D_OK, but please test it for success / failure. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8JT4AAoJEN0/YqbEcdMw4zQP/23zlgm39IW26Wga1gKx4gmJ 2nCC01cpnjsr6TxOH/TYdWNxbXncmG45UlPbCe3H2TU57Aro/dcDAAG4epswuhNU 0rd7TMgkwhUJ+6PDgiYUGdhab30Oem0IvWdS+Z8RNZAdwarpcsbQgIvvpMDMiRgF sNkpCdr2aFVJbjUU9c0sgswumQxOCgok1Z4s6cSOHDK8UmRMRDob1E9U/3QQ77d2 JdsZYeAsTjxWzznX4S77+SklIUaF+ga2noTqOzUf4IHZhJc/2KgMW/r2ZmRYAHxH FyP6E02aVhnhD+PjH3lCBQXGvdQ+oE40Bvtt8ZMMvWP9JkS4ZtkLOC24UYD4jt03 4zPVt1WvqZ7LQFEKjKSfEZMG9wRkMYu/69YVxy5A+QgBiVPLyW2cNTk8FbKRG9mU C5ctjIwhgWVzldSv2kLNeuSDgFr+ybo9BuvBySjzHSabvXaJ8jAsj30zG5UwPOmV e/FjZUzhrK+oAFGPSeZvHauoE14gskPR2V0jNV7h3gXfwvy2thwYWOksS6QihpA1 Rx67RgS8uxre7VfxsqCQsFl8irE/wmKYsGIpqMGYiAFNETCigFuz8nmDBx0I4Oqo ZGmOYATtU09Ap8WVEtcwSLdHbVRy9UF/aStRI1dAeWcFcXxXdEZvop7jWaNMaEmZ V90SEh1KkRgOew5ZkDXp =RHsN -----END PGP SIGNATURE-----

1 0

Re: [PATCH] xaudio2: Use ffmpeg to convert non-PCM formats
by Henri Verbeet 09 Sep '15

09 Sep '15

On 9 September 2015 at 17:26, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > I've discussed other options with people on IRC, including: > > Build and distribute our own Windows FFmpeg package, or ask the user to > install a Windows FFmpeg package in their wineprefix, instead of relying > on the system FFmpeg. Maybe a workable solution, but we'd have to build > and distribute yet another package, or rely on a 3rd party to do so. > There may also be optimization concerns with a package built for Windows > instead of natively on Linux/OSX. > > Find a different WMA decoding library. While one exists (libwmapro), it > is simply pulled out of FFmpeg and converted for use on iPods. It's > several years of out date with FFmpeg's WMA decoder. No other open > source WMA decoder exists that I'm aware of. > > Pull FFmpeg's WMA code out and use it in Wine directly. This would > require a significant amount of effort and ongoing work to pull in > updates. I'm not convinced this is worth the effort. > Mostly for completeness, I think "fix gstreamer" was also mentioned as an option at some point.

1 0

Re: dwrite/tests: Some tests for TranslateColorGlyphRun()
by Marvin 09 Sep '15

09 Sep '15

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=16598 Your paranoid android. === build (build) === Could not copy the patch to the VM: Timed out in create_socket while connecting to testnet.winehq.org:22001:10.42.42.130:4242

1 0