November 2022 - Wine-GitLab

[PATCH 0/3] MR1534: vbscript: Handle another variant of LTE/GTE tokens.
by Nikolay Sivov (＠nsivov) Nov. 24, 2022

Nov. 24, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53670 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1534

7 11

[PATCH 0/6] MR1535: windows.gaming.input: Implement IForceFeedbackMotor_get_SupportedAxes + some fixes.
by Ivo Ivanov (＠logos128) Nov. 24, 2022

Nov. 24, 2022

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

3 9

[PATCH 0/10] MR1537: Draft: windows.media: Partially implement caption properties.
by Mohamad Al-Jaf (＠maljaf) Nov. 24, 2022

Nov. 24, 2022

As Wine currently does not have a way to set captions, returning the default value should suffice for most applications. It looks like Windows does not do error checking for the *value parameter. For the computed properties, they return E_INVALIDARG when all the captions are set as Default. But they return S_OK if any of the caption settings have been modified, regardless of whether a valid *value parameter is passed. I expected it to at least return the computed values for the default properties but this does not appear to be the case. I guess there's no reason to keep the checks for each member of the computed color struct? Perhaps keep the checks for E_INVALIDARG and S_OK? I haven't come across an application that uses the functions so I didn't implement them. For the rest of the properties, the if (0) test was added just to show that it crashes with a NULL value. Also, if the wrong type is passed, the function does not crash on Windows and the value remains unchanged, but it returns S_OK. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1537

3 12

[PATCH 0/2] MR1529: winegstreamer: Implement media_object_SetInputType for WMV decoder.
by Ziqing Hui (＠zhui) Nov. 24, 2022

Nov. 24, 2022

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

3 3

[PATCH v2 0/4] MR1502: Draft: winevulkan: wow64 memory mapping using VK_EXT_external_memory_host
by Jacek Caban (＠jacek) Nov. 24, 2022

Nov. 24, 2022

This MR implements memory mapping for wow64 using VK_EXT_external_memory_host. This has some problems (more below), but overall, it looks promising as a stopgap. It passes D3D tests and works fine in general. For proper solution, we'd need a new Vulkan extension. I experimented with a prototype extension https://github.com/KhronosGroup/Vulkan-Docs/pull/1906 and it looks like we can make it work, my WIP implementation is here https://gitlab.winehq.org/jacek/wine/-/tree/vulkan-map-placed. However, it would be nice to have a fallback working on existing drivers as well. The main problem of this MR is that it breaks Vulkan spec. The main rule it breaks is that according to spec, we should explicitly specify that we plan to use external memory when creating VkBuffer or VkImage. The problem is that we don't know if we will until we bind memory to the buffer. I tried some workarounds for that (delaying actual buffer creation, recreating buffer when needed). I got it mostly working and passing tests without validation errors, but it was more invasive than I'd like and still had other problems. I'd rather avoid that if possible. After looking at Mesa sources, I think that the way this MR breaks the spec should be harmless for its drivers. I don't have the hardware to test with Nvidia. If it works there, I'm tempted to ignore spec violation for now, given that the right path forward is VK_EXT_map_memory_placed anyway. Performance-wise, this MR is sub-optimal because we're limited in what memory types we can use. However, I ran Unigine benchmarks on radv and the difference was marginal. In case of Heaven, it was even slightly faster on wow64, which could be explained by 64-bit Vulkan driver being generally slightly faster, but the difference is too small to draw any conclusion. The last patch is not meant for (eventual) merge, but it's nice for testing the concept. It makes it possible to force using external memory in any kind of Wine build to experiment with its effects without need for wow64. To test that, just set `WINEVULKAN_EXTERNAL_MEMORY` environment variable. -- v2: winevulkan: Introduce debugging environment variables. winevulkan: Use VK_EXT_external_memory_host extension to map memory on wow64. winevulkan: Wrap VkDeviceMemory. winevulkan: Don't try to unwrap missing optional handle struct members. https://gitlab.winehq.org/wine/wine/-/merge_requests/1502

2 5

[PATCH 0/1] MR52: configure: Allow linking against static SPIRV-Tools.
by Zebediah Figura (＠zfigura) Nov. 24, 2022

Nov. 24, 2022

Shared SPIRV-Tools is not shipped by Debian Bullseye, and is broken if built manually. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/52

5 6

Re: [PATCH v2 0/2] MR1508: winevulkan: Union conversion and 1.3.235 spec update.
by Georg Lehmann (＠DadSchoorse) Nov. 24, 2022

Nov. 24, 2022

On Wed Nov 23 15:16:07 2022 +0000, Jacek Caban wrote: > FWIW, this will not do the right thing on wow64 when the address is > meant to be device address. It will override the upper part of > deviceAddress. It was broken in a different way before that commit by > not zeroing upper 32 bits when host address should be used, so it > essentially depended on caller to initialize that part. Unfortunately, I > don't see a good way of solving it properly. Yeah this is a bit unfortunate. Maybe we should just not support 32bit ray tracing for now, if I recall correctly nvidia doesn't even support it with their driver. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1508#note_17321

1 0

[PATCH 0/3] MR1502: Draft: winevulkan: wow64 memory mapping using VK_EXT_external_memory_host
by Jacek Caban (＠jacek) Nov. 24, 2022

Nov. 24, 2022

This MR implements memory mapping for wow64 using VK_EXT_external_memory_host. This has some problems (more below), but overall, it looks promising as a stopgap. It passes D3D tests and works fine in general. For proper solution, we'd need a new Vulkan extension. I experimented with a prototype extension https://github.com/KhronosGroup/Vulkan-Docs/pull/1906 and it looks like we can make it work, my WIP implementation is here https://gitlab.winehq.org/jacek/wine/-/tree/vulkan-map-placed. However, it would be nice to have a fallback working on existing drivers as well. The main problem of this MR is that it breaks Vulkan spec. The main rule it breaks is that according to spec, we should explicitly specify that we plan to use external memory when creating VkBuffer or VkImage. The problem is that we don't know if we will until we bind memory to the buffer. I tried some workarounds for that (delaying actual buffer creation, recreating buffer when needed). I got it mostly working and passing tests without validation errors, but it was more invasive than I'd like and still had other problems. I'd rather avoid that if possible. After looking at Mesa sources, I think that the way this MR breaks the spec should be harmless for its drivers. I don't have the hardware to test with Nvidia. If it works there, I'm tempted to ignore spec violation for now, given that the right path forward is VK_EXT_map_memory_placed anyway. Performance-wise, this MR is sub-optimal because we're limited in what memory types we can use. However, I ran Unigine benchmarks on radv and the difference was marginal. In case of Heaven, it was even slightly faster on wow64, which could be explained by 64-bit Vulkan driver being generally slightly faster, but the difference is too small to draw any conclusion. The last patch is not meant for (eventual) merge, but it's nice for testing the concept. It makes it possible to force using external memory in any kind of Wine build to experiment with its effects without need for wow64. To test that, just set `WINEVULKAN_EXTERNAL_MEMORY` environment variable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1502

3 4

[PATCH 0/2] MR1528: winhttp: Improve WinHttpGetProxyForUrl() execution time when wpad is not available
by Paul Gofman (＠gofman) Nov. 24, 2022

Nov. 24, 2022

Fixes Marvel Snap being unable to connect to servers (part of it, another part is wmic patches), and maybe improves wait times in many other apps. Typically "http://wpad/..." (which is commonly requested as lpszAutoConfigUrl for WinHttpGetProxyForUrl) is not available and WinHttpGetProxyForUrl() is hanging for a really long time resolving this name in download_script(). On Windows 10 here the name resolution timeout is about 9sec (and I could not find a way to configure it for a longer timeout). On Linux default DNS timeouts are typically longer. Yet, while WinHttpGetProxyForUrl() execution time is not consistent here, when I run it right after reboot or after network interface reconnection it typically takes ~4-7 seconds to complete on the first run. Then, testing it again shortly after yields no noticeable timeout. I suppose Windows caches and manages that globally in some service, so maximum possible 9 seconds name resolution timeout is rarely hit. Since proxy config URL, if available, is supposed to be in the local network, having the timeout of 5 seconds for name resolution looks more than enough to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1528

3 4

[PATCH 0/5] MR1538: ntdll: Rename some heap constants and small refactoring.
by Rémi Bernon Nov. 24, 2022

Nov. 24, 2022

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

2 6