November 2024 - Wine-GitLab

Re: [PATCH v2 0/3] MR6903: dwrite/tests: Add a test for DrawGlyphRun() bounds. - approved
by Alexandre Julliard (＠julliard) Nov. 26, 2024

Nov. 26, 2024

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6903

1 0

Re: [PATCH v3 0/2] MR6873: dsound: Fix SetNotificationPositions at end of nonlooping buffer - approved
by Alexandre Julliard (＠julliard) Nov. 26, 2024

Nov. 26, 2024

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6873

1 0

[PATCH 0/1] MR5041: ntdll/tests: Unify APC test functions
by Dāvis Mosāns Nov. 26, 2024

Nov. 26, 2024

Currently there are several places that test APC but they use duplicated/similar `apc_func()` so merge all those into single implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5041

2 3

[PATCH v6 0/9] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon Nov. 26, 2024

Nov. 26, 2024

I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting. Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well. After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…) We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface. -- v6: winevulkan: Introduce a new vulkan_physical_device base structure. winevulkan: Introduce a new vulkan_instance base structure. winevulkan: Hoist physical device array and client instance handle. winevulkan: Name wine_instance parameters and variables more consistently. winevulkan: Move vulkan_client_object header to wine/vulkan_driver.h. winevulkan: Generate ALL_VK_(DEVICE|INSTANCE)_FUNCS in wine/vulkan.h. winevulkan: Get rid of the instance/device funcs structs. win32u: Use PFN_* typedefs for vulkan function pointers. winevulkan: Add missing wine_vkGetPhysicalDeviceSurfaceFormatsKHR manual wrapper. https://gitlab.winehq.org/wine/wine/-/merge_requests/6427

2 11

[PATCH v5 0/9] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon Nov. 26, 2024

Nov. 26, 2024

I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting. Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well. After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…) We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface. -- v5: winevulkan: Introduce a new vulkan_physical_device base structure. winevulkan: Introduce a new vulkan_instance base structure. winevulkan: Pass physical device array params to some helpers. winevulkan: Name wine_instance parameters and variables more consistently. winevulkan: Move vulkan_client_object header to wine/vulkan_driver.h. winevulkan: Generate ALL_VK_(DEVICE|INSTANCE)_FUNCS in wine/vulkan.h. winevulkan: Get rid of the instance/device funcs structs. win32u: Use PFN_* typedefs for vulkan function pointers. winevulkan: Add missing wine_vkGetPhysicalDeviceSurfaceFormatsKHR manual wrapper. https://gitlab.winehq.org/wine/wine/-/merge_requests/6427

2 13

[PATCH v2 0/2] MR6900: oleaut32: Make OleCreateFontIndirect return error if font name is missing
by Fabian Maurer (＠DarkShadow44) Nov. 26, 2024

Nov. 26, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57457 -- v2: oleaut32: Remove a new unneeded null checks oleaut32: Make OleCreateFontIndirect return error if font name is missing https://gitlab.winehq.org/wine/wine/-/merge_requests/6900

2 4

[PATCH 0/1] MR6908: win32u: Allow unsetting the user driver.
by Sven Baars (＠sbaars) Nov. 26, 2024

Nov. 26, 2024

The wayland driver does this during initialization. This fixes a regression when running wine without a desktop. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6908

3 2

[PATCH 0/1] MR4851: kernelbase: Add naive SystemTimeToTzSpecificLocalTimeEx implementation
by Russell Greene (＠russelltg) Nov. 26, 2024

Nov. 26, 2024

The cast there seems safe from looking at the struct definitions, and is also used elsewhere in the codebase (dlls/kernelbase/locale.c:5682). It's obviously not a full implementation, but works well enough for my usecase and maybe others as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4851

3 3

[PATCH v4 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon Nov. 26, 2024

Nov. 26, 2024

I'm starting to consider wrapping more vulkan objects in win32u, I think it'll be useful to implement compositing (and incidentally shared resources with interop with the D3DKMT/NtGdi API), starting with nulldrv/offscreen swapchains. Alternatively we could export more functions from win32u and keep all the wrappers in winevulkan, but having access to win32u internals with a generic vulkan object wrapping mechanism seems to be more interesting. Right now this is not very convenient because the vulkan object hierarchy is only available in winevulkan. This introduces shared structures and API between win32u and winevulkan so they can manipulate the wrapped objects from both side. The interface would only expose what is necessary, ie: the object hierarchy and wrapped handles, the instance and device functions, and the objects rbtree for debugging, so win32u can insert its wrapper there as well. After moving the surface and swapchain wrappers to win32u, the interface would look like this: https://gitlab.winehq.org/rbernon/wine/-/blob/65ca1280d46a2dff792e298c22242… (I pushed a complete WIP branch to https://gitlab.winehq.org/rbernon/wine/-/commits/wip/vulkan-win32u-driver?r…) We can also consider moving all the winevulkan wrappers to win32u but it's not clear whether it's necessary or desirable, and we can also do that later using this interface. -- v4: winevulkan: Introduce a new vulkan_physical_device base structure. https://gitlab.winehq.org/wine/wine/-/merge_requests/6427

2 11

Re: [PATCH v24 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by eric pouech (＠epo) Nov. 26, 2024

Nov. 26, 2024

On Tue Nov 26 09:45:58 2024 +0000, Michele Dionisio wrote: > I remove the check as you request. but in my opinion now the test fails > on linux and windows too they fail on linux when run from a unix console, I don't see failure on windows you can add the attached patch to work around this [patch-timeout](/uploads/e311af5c8318f780aad5ff66a714ba26/patch-timeout) I let you fix the remaining failure Note: since MR!6888 has been merged, you don't need to take care of returning STATUS_CONTROL_C_EXIT, it's done by the default handlers now Note2: the SetStdHandle() call between FreeConsole() and AllocConsole() in this patch looks suspicious : it's not needed under Windows, so likely another Wine bug (but it's needed for now, esp. when running the tests under Wine from a unix console) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6869#note_88940

1 0