- Wine-gitlab - list.winehq.org

[PATCH 0/1] MR1688: ddraw: Sync draw textures even for hardware device.
by Paul Gofman (＠gofman) 06 Dec '22

06 Dec '22

Fixes a regression introduced by commit d2d9f713df7932aac4b137ec3bf647d5da7faaef. Fixes black screen in Exceed - Gun Bullet Children. The check in d3d_device_sync_surfaces() assumes that separate draw textures may be created and successfully bound for software device only. This turns out to be not always the case. The case which the game hits is that it creates a surface with DDSCAPS_TEXTURE | DDSCAPS_3DDEVICE, DDSCAPS2_TEXTUREMANAGE. Such surface creation is valid and the resulting surface is bindable as render target of a software device (we have a test for that). Such a texture effectively falls into the case when a separate draw texture is created and that looks correct. However this surface, while cannot be used as a render target on hardware device, can still be used as a texture. So for a general case syncing surfaces for software devices only is wrong (it still looks right for syncing render targets). Just always traversing all the bound textures in d3d_device_sync_surfaces() looks like a waste, while accurately tracking when there are bound textures requiring sync is possible while looks like an unnecessary complication. So triggering the sync by the fact a texture requiring a sync was ever bound (which is in fact not so common case) looks like a reasonable compromise to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1688

7 7

[PATCH v2 0/7] MR1697: localspl: Use print processor + SeekPrinter
by Piotr Caban (＠piotr) 06 Dec '22

06 Dec '22

-- v2: winspool: Add SeekPrinter implementation. localspl: Add partial SeekPrinter implementation. localspl: Use print processor in ScheduleJob. https://gitlab.winehq.org/wine/wine/-/merge_requests/1697

3 14

[PATCH 0/1] MR1699: configure: Use -Wl,-WX for clang configure checks in MSVC mode.
by Jacek Caban (＠jacek) 06 Dec '22

06 Dec '22

LLD by default emits only a warning for unknown arguments. This makes it pass -Wl,--disable-stdcall-fixup check, which is in fact an invalid option (and disabled by default anyway), causing warnings spam during the build. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1699

2 1

[PATCH 0/7] MR1697: localspl: Use print processor + SeekPrinter
by Piotr Caban (＠piotr) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1697

3 8

[PATCH 0/1] MR1696: msi: Use _O_* constants from fcntl.h instead of redefining them.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1696

3 2

[PATCH 0/4] MR1681: uxtheme: Avoid using lstrcmpiW.
by Rémi Bernon 06 Dec '22

06 Dec '22

This is called a huge number of time every time the module is loaded. The function does a lot of things, which I believe aren't necessary for uxtheme string comparison. The impact on process startup is noticeable, and this saves ~1min on the Gitlab CI test run. Instead, convert strings to uppercase beforehand in a locale-independent way, and compare with wcscmp. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1681

3 14

[PATCH v2 0/1] MR1694: setupapi: Move prototypes not in Windows's setupapi.h to setupapi_private.h.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

And delete the ones we don't need. -- v2: setupapi: Move prototypes not in Windows's setupapi.h to setupapi_private.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/1694

2 2

[PATCH 0/1] MR1694: setupapi: Move prototypes not in Windows's setupapi.h to setupapi_private.h.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

And delete the ones we don't need. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1694

3 2

[PATCH 0/1] MR1695: setupapi: Use _S_I(READ|WRITE) from sys/stat.h instead of redefining them.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1695

2 1

[PATCH v6 0/5] MR1588: Add windows.system.profile.systemmanufacturers DLL.
by Mohamad Al-Jaf (＠maljaf) 06 Dec '22

06 Dec '22

The test for ISmbiosInformationStatics_get_SerialNumber is broken on Window 10 testbot VMs, presumably because they don't have a serial number? It results in an HRESULT of E_UNEXPECTED. I added a broken test case for it. I'm assuming that normal installations of Windows return a valid serial number or at least something like "Not Specified" and not NULL. Also, on my Linux OS running cat /sys/class/dmi/id/product_serial returns "To be filled by O.E.M". So I added a fallback to return 0 as the number. Or is it fine to just return whatever string is found? On the Windows 8 VMs, the test crashes at line 75, hr = ISmbiosInformationStatics_get_SerialNumber( smbios_statics, &serial ). Not sure what I should do in this case. I was hoping for a flag that checks if the VM is Windows 8, but there doesn't seem to be one. Should I wrap the test in if (0) or is there an alternative way? Another weird thing is the test fails prematurely on only the 32-bit version of debian11b, saying that the runtimeclass is not registered. I'm assuming it's an issue with the testbot. Debian11 32 bit runs fine. -- v6: windows.system.profile.systemmanufacturers: Implement ISmbiosInformationStatics_get_SerialNumber. windows.system.profile.systemmanufacturers/tests: Add ISmbiosInformationStatics_get_SerialNumber tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/1588

3 10