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

FOSDEM and Wineconf
by Jeremy White July 8, 2014

July 8, 2014

Hey Folks, The FOSDEM call for rooms is out for next year: https://fosdem.org/2015/news/2014-07-01-call-for-participation/ I left FOSDEM this year feeling that it was a great two years, but not something that made sense for 2015, at least not in the same form (a dedicated dev room). I had the sense that a table like the distros had, maybe with a few talks in the general tracks, made more sense. But the bottom line is that I'm not going to go in 2015, and as such, it doesn't make sense for me to do the coordination of it. Is anyone else willing to pick this up? Anyone else have ideas for if and/or how we should participate in FOSDEM 2015? Cheers, Jeremy

2 1

Wine development questions
by Rui Caridade July 8, 2014

July 8, 2014

Hello all, Some software i use has been negatively affected by some patches, namely Ken's work on WGL My question's are: - If a patch/commit has a bad impact for users why not remove it, especially if a possible solution is not accepted? -This summer sale i bought Tomb Raider 2013 on steam just to find the game playable only with a patch on bugzilla. Is it only a case of the patch not having come through the correct channels.Can it be accepted ? Its not a single case. All the best everyone.

2 3

Re: [PATCH 3/4] ddraw/tests: Add tests for lost P8 primaries.
by Alexandre Julliard July 8, 2014

July 8, 2014

Stefan Dösinger <stefan(a)codeweavers.com> writes: > The explicit request of DDSCAPS_VIDEOMEMORY is needed to work around two > bugs in Wine's ddraw that are not the concern of this test: If neither > SYSTEMMEMORY nor VIDEOMEMORY are requested we use SYSTEMMEMORY for P8 > surfaces because check_device_format fails. The next patch addresses > this. The second problem is that we do not lose system memory surfaces > on SetCooperativeLevel even though we should. (We should at least lose > primaries. I haven't checked offscreen or texture surfaces.) > > I don't feel strongly about having this test included. I'm happy with > just sending it as a documentation that SetCooperativeLevel does not > have to restore the palette. If the DDSCAPS_VIDEOMEMORY is considered > ugly, or the fix in the next patch wrong just ignore the patches. I do > not know any game that depends on the behavior tested here or the > behavior changed in the next patch. > --- > dlls/ddraw/tests/ddraw1.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw4.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 573 insertions(+) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M ddraw.dll -p ddraw_test.exe.so ddraw1 && touch ddraw1.ok ddraw1.c:5694: Test failed: Got unexpected hr 0. ddraw1.c:5696: Test failed: Got unexpected hr 0. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 4/5] d3d8/tests: Add a test for SetPriority / GetPriority.
by Marvin July 8, 2014

July 8, 2014

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=7894 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000801B0, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412cf0, got 0x412cf0.

1 0

Re: kernel32: initialize return value in CreateSemaphoreExW
by Henri Verbeet July 8, 2014

July 8, 2014

This seems like the kind of thing for which writing a test should be easy.

1 0

Re: [PATCH 3/4] ddraw/tests: Add tests for lost P8 primaries.
by Henri Verbeet July 8, 2014

July 8, 2014

On 6 July 2014 18:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + IDirectDraw *ddraw; ... > + hr = IDirectDraw4_CreateSurface(ddraw, &surface_desc, &texture, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); I didn't notice this before, but you'll want to use IDirectDraw_CreateSurface() here.

1 0

Re: kernel32: Partially implement GetGeoInfo()
by Dmitry Timoshkov July 7, 2014

July 7, 2014

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > [0001-kernel32-Partially-implement-GetGeoInfo.patch text/x-patch (32.2KB)] Some of this info already exists in the locale data under dlls/kernel32/nls and returned by GetLocaleInfo(), probably it would be a good idea to add missing geo data there as well (auto-generate from the public source) and use it from inside of GetGeoInfo(). -- Dmitry.

2 5

Re: kernel32: Partially implement GetGeoInfo()
by Alexandre Julliard July 7, 2014

July 7, 2014

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > -INT WINAPI GetGeoInfoW(GEOID GeoId, GEOTYPE GeoType, LPWSTR lpGeoData, > - int cchData, LANGID language) > +struct geoinfo_t { > + char iso2A[3]; > + char iso3A[4]; > + WCHAR iso2W[3]; > + WCHAR iso3W[4]; > + INT uncode; > +}; Surely you don't need both A and W versions of every string. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/6] ntdll: refactor NTDLL_create_struct_sd and NTDLL_free_struct_sd so that other modules are able to use them
by Alexandre Julliard July 7, 2014

July 7, 2014

Joris van der Wel <joris(a)jorisvanderwel.com> writes: > ntdll: refactor NTDLL_create_struct_sd and NTDLL_free_struct_sd so > that other modules are able to use them (extern). New names are > wine_server_create_struct_sd and wine_server_free_struct_sd. That's not used enough to warrant new private exports from ntdll. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH 4/4] ddraw: Test if P8 primaries can be converted to RGB.
by Henri Verbeet July 7, 2014

July 7, 2014

On 6 July 2014 18:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 3d61e61..7367c01 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -5838,6 +5838,7 @@ HRESULT ddraw_surface_create(struct ddraw *ddraw, const DDSURFACEDESC2 *surface_ > { > enum wined3d_resource_type rtype; > DWORD usage = 0; > + enum wined3d_format_id adapter_format = mode.format_id; > > if (desc->ddsCaps.dwCaps2 & DDSCAPS2_CUBEMAP) > rtype = WINED3D_RTYPE_CUBE_TEXTURE; > @@ -5851,8 +5852,11 @@ HRESULT ddraw_surface_create(struct ddraw *ddraw, const DDSURFACEDESC2 *surface_ > else if (desc->ddsCaps.dwCaps & DDSCAPS_3DDEVICE) > usage = WINED3DUSAGE_RENDERTARGET; > > + if (desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE) > + adapter_format = WINED3DFMT_B8G8R8X8_UNORM; > + > if (SUCCEEDED(hr = wined3d_check_device_format(ddraw->wined3d, WINED3DADAPTER_DEFAULT, > - WINED3D_DEVICE_TYPE_HAL, mode.format_id, usage, rtype, wined3d_desc.format))) > + WINED3D_DEVICE_TYPE_HAL, adapter_format, usage, rtype, wined3d_desc.format))) I don't think this fix is quite correct either. The drawable format is a wined3d internal thing, ddraw shouldn't have to know about it. In principle it wouldn't necessarily need to be WINED3DFMT_B8G8R8X8_UNORM either, for example if we ever get around to supporting 10 bpc display modes. So I think the fix for this would need to be in wined3d_check_device_format(), or its utility functions.

2 2