June 2024 - Wine-GitLab - list.winehq.org

[PATCH v3 0/1] MR5658: winevulkan: Make device memory wrapper available in callbacks.
by Arek Hiler (＠ivyl) June 21, 2024

June 21, 2024

With [`VK_EXT_device_address_binding_report`](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_device_address_binding_report.html) we can get [debug_util](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/ht… callbacks used to track memory bindings. Since it's the host's implementation that starts the callback we have to be sure that we have a way of converting it to the client side's variant before it's added to the handle map - i.e. we don't know the host handle at that time yet. This is [used by vkd3d-proton](https://github.com/HansKristian-Work/vkd3d-proton/pull/1962). Requires Mesa with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28649. before (note the missing BIND for VkDevice which actually means `VkDeviceMemory`): ``` vkd3d-proton % VKD3D_TEST_FILTER=create_placed_resource_size VKD3D_CONFIG=fault VKD3D_DEBUG=trace ~/src/wine/build/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800100200000 || size 000000000019a000. trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800100200000 || size 000000000019a000. trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. :trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. ``` after: ``` % VKD3D_TEST_FILTER=create_placed_resource_size VKD3D_CONFIG=fault VKD3D_DEBUG=trace ~/src/wine/build/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback 232338.036:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.036:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800100200000 || size 000000000019a000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800100200000 || size 000000000019a000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. ``` [The spec guarantees](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/v… the following: > An application can receive multiple callbacks if multiple VkDebugUtilsMessengerEXT objects are created. A callback will always be executed in the same thread as the originating Vulkan call. As of TLS I went with a suggestion from IRC: ``` <ivyl_> There's an issue with how we handle callbacks related to VK_EXT_debug_utils and VK_EXT_debug_report. In wine_vkAllocateMemory() we call device->funcs.p_vkAllocateMemory() which may execute callback. <ivyl_> At this point we still don't have handle mapping added because we don't know what host_memory handle will be. <ivyl_> AFAIU there's a spec guarantee that callback will be executed in the same thread as the call causing it, so I was thinking about maybe keeping `memory` in a tls (if enable_wrapper_list) and using that? <ivyl_> but that's I don't see any precedent of using thread local storage on the unix side <ivyl_> tls value would be short-lived in such case - only for the duration of the call to `device->funcs.p_vkAllocateMemory()` <jacekc_> we usually use teb on unix side, see ntuser_thread_info ``` -- v3: winevulkan: Make device memory wrapper available in callbacks. https://gitlab.winehq.org/wine/wine/-/merge_requests/5658

2 1

[PATCH 0/1] MR5901: profapi: Add stub dll.
by Zhiyi Zhang (＠zhiyi) June 21, 2024

June 21, 2024

Required by React Native apps. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5901

3 2

Re: [PATCH v5 0/7] MR5319: winemac.drv keyboard layout/dead key fixes
by Rémi Bernon June 21, 2024

June 21, 2024

Rémi Bernon (@rbernon) commented about dlls/winemac.drv/keyboard.c: > if (!len) > break; > > + if (status == noErr && len == 1) > + { > + CFStringRef stringRef = CFStringCreateWithCharacters(kCFAllocatorDefault, buffer, len); > + CFMutableStringRef mutableStringRef = CFStringCreateMutableCopy(kCFAllocatorDefault, 0, stringRef); > + > + CFStringUppercase(mutableStringRef, CFLocaleGetSystem()); > + if (CFStringGetLength(mutableStringRef) == 1) > + CFStringGetCharacters(mutableStringRef, CFRangeMake(0, 1), buffer); > + CFRelease(stringRef); > + CFRelease(mutableStringRef); > + } Does we need to support unicode? What about: ```suggestion:-10+0 if (status == noErr && len == 1 && buffer[0] >= 'a' && buffer[0] <= 'z') buffer[0] += 'A' - 'a'; ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5319#note_73911

1 0

Re: [PATCH v5 0/7] MR5319: winemac.drv keyboard layout/dead key fixes
by Rémi Bernon June 21, 2024

June 21, 2024

Rémi Bernon (@rbernon) commented about dlls/winemac.drv/keyboard.c: > if (!len) > break; > > + if (status == noErr && deadKeyState) > + { > + for (i = 0; i < ARRAY_SIZE(dead_key_names); i++) > + { > + if (dead_key_names[i].wchar == buffer[0]) > + { > + len = min(strlen(vkey_names[i].name) + 1, size); ```suggestion:-0+0 len = min(strlen(dead_key_names[i].name) + 1, size); ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5319#note_73912

1 0

Re: [PATCH v5 0/7] MR5319: winemac.drv keyboard layout/dead key fixes
by Rémi Bernon June 21, 2024

June 21, 2024

Rémi Bernon (@rbernon) commented about dlls/winemac.drv/keyboard.c: > done: > /* Null-terminate the buffer, if there's room. MSDN clearly states that the > caller must not assume this is done, but some programs (e.g. Audiosurf) do. */ > - if (1 <= ret && ret < bufW_size) > - bufW[ret] = 0; > + if (0 <= len && len < bufW_size) ```suggestion:-0+0 if (len < bufW_size) ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5319#note_73910

1 0

Re: [PATCH v5 0/7] MR5319: winemac.drv keyboard layout/dead key fixes
by Rémi Bernon June 21, 2024

June 21, 2024

Rémi Bernon (@rbernon) commented about dlls/winemac.drv/keyboard.c: > &savedDeadKeyState, bufW_size, &len, bufW); > if (status != noErr) > { > - ERR_(key)("Couldn't translate keycode 0x%04x, status %d\n", keyc, status); > + ERR_(key)("Couldn't translate dead keycode 0x%04x, status %d\n", keyc, status); > goto done; > } > > + if (len >= 1) Same, doesn't seem to be necessary? If len is 0, and dead = TRUE, we just return 0 anyway? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5319#note_73909

1 0

Re: [PATCH v5 0/7] MR5319: winemac.drv keyboard layout/dead key fixes
by Rémi Bernon June 21, 2024

June 21, 2024

Rémi Bernon (@rbernon) commented about dlls/winemac.drv/keyboard.c: > UInt32 modifierKeyState; > OptionBits options; > UInt32 deadKeyState, savedDeadKeyState; > - UniCharCount len; > + UniCharCount len = 0; Doesn't seem to be needed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5319#note_73908

1 0

[PATCH 0/3] MR5898: winex11, winemac, winewayland: Move surface code to the window surface source file.
by Rémi Bernon June 21, 2024

June 21, 2024

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

2 5

[PATCH 0/5] MR5903: Cmd engine rewrite (part VIII)
by eric pouech (＠epo) June 21, 2024

June 21, 2024

This is part VIII of cmd engine rewrite. It covers: - introduction of a token based parser. For now, it produces the same (degenerated) list of commands as we currently do. Note: I opted for a pull mode for the parser while the lexer is in push mode. Long term plan is to move the lexer into pull mode too (and also converge the two different current methods of argument/token access). - introduction of return codes. It's not obvious from current tests that lots of these codes are actually the kernel32 ones, but tests in later MRs will clearly show it. - starting changing 'exit' and 'goto' builtin implementations to use return code. All builtins will have to adopt that scheme for command chaining to be properly supported. - add delayed expansion for IF command. That's not needed for now (as single command execution already takes care of it), but will be needed when we move IF and FOR commands out of single command in yet to come MR. Includes some test to cover that part. (in case someone asks, it was needed in previous MR regarding the FOR command, as the delayed expansion was only called on the body of the FOR command, not the control block) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5903

2 5

[PATCH v2 0/1] MR5658: winevulkan: Make device memory wrapper available in callbacks.
by Arek Hiler (＠ivyl) June 21, 2024

June 21, 2024

With [`VK_EXT_device_address_binding_report`](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_device_address_binding_report.html) we can get [debug_util](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/ht… callbacks used to track memory bindings. Since it's the host's implementation that starts the callback we have to be sure that we have a way of converting it to the client side's variant before it's added to the handle map - i.e. we don't know the host handle at that time yet. This is [used by vkd3d-proton](https://github.com/HansKristian-Work/vkd3d-proton/pull/1962). Requires Mesa with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28649. before (note the missing BIND for VkDevice which actually means `VkDeviceMemory`): ``` vkd3d-proton % VKD3D_TEST_FILTER=create_placed_resource_size VKD3D_CONFIG=fault VKD3D_DEBUG=trace ~/src/wine/build/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800100200000 || size 000000000019a000. trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800100200000 || size 000000000019a000. trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. :trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. ``` after: ``` % VKD3D_TEST_FILTER=create_placed_resource_size VKD3D_CONFIG=fault VKD3D_DEBUG=trace ~/src/wine/build/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback 232338.036:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.036:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800100200000 || size 000000000019a000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800100200000 || size 000000000019a000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. ``` [The spec guarantees](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/v… the following: > An application can receive multiple callbacks if multiple VkDebugUtilsMessengerEXT objects are created. A callback will always be executed in the same thread as the originating Vulkan call. As of TLS I went with a suggestion from IRC: ``` <ivyl_> There's an issue with how we handle callbacks related to VK_EXT_debug_utils and VK_EXT_debug_report. In wine_vkAllocateMemory() we call device->funcs.p_vkAllocateMemory() which may execute callback. <ivyl_> At this point we still don't have handle mapping added because we don't know what host_memory handle will be. <ivyl_> AFAIU there's a spec guarantee that callback will be executed in the same thread as the call causing it, so I was thinking about maybe keeping `memory` in a tls (if enable_wrapper_list) and using that? <ivyl_> but that's I don't see any precedent of using thread local storage on the unix side <ivyl_> tls value would be short-lived in such case - only for the duration of the call to `device->funcs.p_vkAllocateMemory()` <jacekc_> we usually use teb on unix side, see ntuser_thread_info ``` -- v2: winevulkan: Make device memory wrapper available in callbacks. https://gitlab.winehq.org/wine/wine/-/merge_requests/5658

4 4