November 2024 - Wine-gitlab

[PATCH 0/1] MR6877: ntdll: Force redirect all ARM64EC indirect calls until the JIT is ready.
by Billy Laws (＠bylaws) 24 Nov '24

24 Nov '24

Tested by running chrome without no-sandbox successfully. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6877

4 6

[PATCH 0/7] MR4947: winewayland.drv: part 12: Display mode change emulation
by Alexandros Frantzis (＠afrantzis) 24 Nov '24

24 Nov '24

This MR uses the existing compositor side surface scaling in the driver (through wp_viewporter, currently used for Hi-DPI scaling) to emulate display mode changes. This works wonderfully in coordination with fullscreen since the compositor is required non only to scale the surface, but also to position it properly and provide opaque surroundings (note: some compositors don't implement the last two features properly!). Since: 1. Wayland doesn't allow clients to change the actual display configuration, and 2. there is no queryable service that holds the display information in a consistent manner (à la xrandr), the MR uses the win32 device settings as the source of truth for the current display mode. We let win32u handle the display mode change in the default manner (i.e., just updating the registry settings), and provide access to the current mode when updating the display devices through a new `gdi_display_manager.get_adapter()` function. In order to be able to consistently (across all processes) associate an adapter device with its corresponding `wl_output` the MR introduces per-adapter driver data. Note for people trying this out: many modern games don't change the hardware display settings, but rather scale themselves in right way to achieve the visual effect of a mode change (similarly to how this MR works, but they do it on the application side). To exercise most of the functionality in this MR you need an application that actually uses the `ChangeDisplaySettings` win32 API. Thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4947

16 48

[PATCH v4 0/28] MR6207: include: Introduce new COM implementation helper macros.
by Rémi Bernon 23 Nov '24

23 Nov '24

I think it would be very nice to have something like that to reduce the burden of implementing COM interfaces. This shows for instance on the windows.gaming.input module a 30% LoC reduction (from ~6800 to ~4700), even though the module already had a boilerplate helper macros already. The MR introduces macros to automatically implement each IUnknown method, as well as all of them at once. It also includes a helper to implement IInspectable methods at once, as well as macros to forward both interface methods to a base interface or an outer object. Last, it provides higher-level macros to implement a main interface and any number of sub interfaces and generate IUnknown, forwarding and vtables for all of them at once, with IInspectable support when needed. It uses widl to generate additional per-interface macros, for things like inheritance and vtable generation. The rest of the macros are otherwise shared in a Wine-specific header. The implementation is split to show individual macro being used, although they are later replaced by higher-level macros. The individual helpers are still useful in some corner cases where specific behavior needs to be implemented, or for aggregating classes. -- v4: windows.gaming.input: Use the new COM macros everywhere possible. windows.gaming.input: Use the new macros for class implementation. widl: Generate new macros for class implementation. windows.gaming.input: Use the new macros for IInspectable implementation. widl: Generate new macros for IInspectable implementation. windows.gaming.input: Use the new macros for IUnknown implementation. widl: Generate new macros for IUnknown implementation. windows.gaming.input: Use the WIDL_impl_IUnknown_QueryInterface boilerplate macros. widl: Generate some WIDL_impl_IUnknown_QueryInterface boilerplate macros. windows.gaming.input: Use the WIDL_impl_QueryInterface boilerplate macros. widl: Generate some WIDL_impl_QueryInterface boilerplate macros. windows.gaming.input: Use the WIDL_impl_IUnknown_Release boilerplate macros. widl: Generate some WIDL_impl_IUnknown_Release boilerplate macros. windows.gaming.input: Use the WIDL_impl_IUnknown_AddRef macros. widl: Generate some WIDL_impl_IUnknown_AddRef boilerplate macros. windows.gaming.input: Use the WIDL_impl_IInspectable_forwards boilerplate macros. widl: Generate some WIDL_impl_IInspectable_forwards boilerplate macros. windows.gaming.input: Use the WIDL_impl_IUnknown_forwards boilerplate macros. widl: Generate some WIDL_impl_IUnknown_forwards boilerplate macros. windows.gaming.input: Use the new WIDL_impl_from_* boilerplate macros. widl: Generate some WIDL_impl_from_* boilerplate macros. windows.gaming.input: Use the new WIDL_impl_*Vtbl macros. widl: Generate WIDL_impl_*Vtbl boilerplate macros. windows.gaming.input: Use type-prefixed impl_from helpers. windows.gaming.input: Move struct qualifier inside the macro. windows.gaming.input: Use a separate interface for IAgileObject. makedep: Generate some new impl.h headers from the IDLs. widl: Generate some new impl.h headers from the IDLs. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6207

1 1

[PATCH v6 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- v6: dlls/propsys: Implement IPropertyDescription for several known system properties. dlls/propsys: Add IPropertyDescription stub for system defined properties. https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH 0/1] MR6895: mlang: In GetFontCodePages add another null check (Coverity)
by Fabian Maurer (＠DarkShadow44) 23 Nov '24

23 Nov '24

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

3 2

[PATCH v3 0/2] MR6289: dsound: Reject NaN values in some functions.
by Aida Jonikienė 23 Nov '24

23 Nov '24

The tests aren't really tested though (they partially require interactive mode and they caused lag issues on one person's machine). -- v3: dsound/tests: Add NaN tests for floating-point 3D functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/6289

1 5

[PATCH v2 0/3] MR6715: Support separated debug information for PE images.
by eric pouech (＠epo) 23 Nov '24

23 Nov '24

This serie is a first attempt to provide a solution to bug 57308 [1]. Basically, Arch distro is looking for Wine support in distributing debug information for Wine PE modules separated from image. A quick overview of distro (Debian, Fedora, Arch) situation i (I may have missed a couple of items), but: - no distro ship separate debug information for PE modules (they do it for ELF ones though) - at best, they ship unstripped PE modules. IMO, we need to help them pave the way to what should be the best expected situation (in Wine and wrt distros) to support separate debug information for PE images. First, I believe we need to use a (solid) key to bind the stripped image and the file holding the debug information. In ELF format, this is typically done by inserting a .note.gnu.build-id section (in both stripped image and debug information file) which contains the key. This key is used to either search in fixed location (eg /usr/lib/.debug), or as key to download the debug information from a remote server (debuginfod). The key is generally made of a hash of (some sections of) the image file. This allows (esp. in the case of downloading the debug information from a debugger) to discriminate between several versions of the same module. I think we should target this kind of solution instead of storing the debug information alongside the module (usually done as ntdll.dll.debug). This wouldn't let debuggers download the expected debug info upon request. Fortunately, gcc and clang provide a build-id option (when generating PE images) which stores this key in the PE image. What this serie does: - fixes & improves dbghelp in the support of the build-id information from gcc/mingw & clang, - improves Wine's configure script so that clang can be used to generate dwarf debug information and build-id information in PE builds, - adds a couple of additional search locations for debug information files, It takes the following assumptions for the storage: - debug information files for PE images are stored in same hierarchy as debug information files for ELF images (eg /usr/lib/.debug) - naming of such files is done as ELF, ie by using the hex string generated from the binary blob of the key. This is *NOT* the usual way how the GUID will be printed (because the first 3 integers of the GUID are stored in little-endian format). (Note: I had to make a choice here. I don't have strong arguments one way or the other, but we need to agree on the convention here). What distro should do to support separate debug info: - configure Wine with --enable-build-id - adapt at least the packaging tool to extract the key out of unstripped image [2], - if binutils isn't compiled with PE support (this is apparently the Arch case), adapt the scripts to use x86_64-objcopy instead of objcopy (and friends). I marked this MR as draft for now, as: - I still need to polish some items (like the default location for looking up debug information files), - wait for feedback on this proposal (it does make a couple of assumptions that need sharing IMO), Further steps: - the steps above are mainly targetted to have a solution for packaged download of debug information files, - this should be integrated in debuginfod (server side: ingestion of PE files and client side: ensure gdb, lldb are compatible; implement debuginfod in winedbg). Feed back welcomed! [1]: https://bugs.winehq.org/show_bug.cgi?id=57308 [2]: The least invasive readelf replacement (assuming binutils is compiled with PE support). (otherwise, use x86_64-objdump) ``` BUILDID=`objdump -p "$INPUT" | sed -n "/RSDS signature / {s/.*signature //; s/ age.*//p; q;}"` BUILDID=${BUILDID:6:2}${BUILDID:4:2}${BUILDID:2:2}${BUILDID:0:2}${BUILDID:10:2}${BUILDID:8:2}${BUILDID:14:2}${BUILDID:12:2}${BUILDID:16} ``` Additional note: gcc/mingw puts the desired debug entry inside a dedicated section (.buildid), while clangs keeps it in .rdata (as msvc does). So, this invalidates any attempt to get information from the .buildid section (as stated in bug report). -- v2: configure.ac: Improve clang configuration for dwarf as cross debug format. dbghelp: Search debug info with buildid for RSDS debug entry w/o filenames. dbghelp: Extend search for buildid in system directories. https://gitlab.winehq.org/wine/wine/-/merge_requests/6715

5 8

[PATCH v5 0/7] MR6892: dlls/propsys: Implement IPropertyDescription for several known system properties.
by Vibhav Pant (＠vibhavp) 23 Nov '24

23 Nov '24

This MR adds a very basic implementation of `IPropertyDescription` for system defined properties (i.e, the ones in \<propkey.h\>). This is needed to support the [`Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100) method for `IDeviceInformation` in Windows.Devices.Enumeration (!6874). -- v5: dlls/propsys: Implement IPropertyDescription for several known system properties. dlls/propsys: Add IPropertyDescription stub for system defined properties. dlls/propsys/tests: Add conformance tests for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PSGetNameFromPropertyKey. dlls/propsys: Add stubs for PropertySystem. https://gitlab.winehq.org/wine/wine/-/merge_requests/6892

3 8

[PATCH v7 0/5] MR7: Draft: ntdll: Properly track refcount with forwarded exports.
by Jinoh Kang (＠iamahuman) 23 Nov '24

23 Nov '24

This fixes https://bugs.winehq.org/show_bug.cgi?id=52094. -- v7: ntdll: Properly track refcount with forwarded exports. ntdll: Don't re-add a module dependency if it already exists. ntdll: Remove some unnecessary NULL checks for current_importer. ntdll: Set export forwarder DLL as the dynamic importer in LdrGetProcedureAddress(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7

3 8

Re: [PATCH v2 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Rémi Bernon 23 Nov '24

23 Nov '24

On Wed Sep 4 18:06:48 2024 +0000, Jacek Caban wrote: > Actually, depending on other design details, win32u may sometimes need > client handle, but then the same concerns apply as against the host handle. What would you think of an interface in `wine/vulkan_driver.h` like this one: ```c struct vulkan_client_object { /* Special section in each dispatchable object for use by the ICD loader for * storing dispatch tables. The start contains a magical value '0x01CDC0DE'. */ UINT64 loader_magic; UINT64 unix_handle; }; #ifdef WINE_UNIX_LIB struct vulkan_object { UINT64 host_handle; UINT64 client_handle; struct vulkan_object *parent; struct rb_entry entry; }; #define VULKAN_OBJECT_HEADER( type, name, parent_type, parent_name ) \ union { \ struct vulkan_object obj; \ struct { \ union { type name; UINT64 handle; } host; \ union { type name; UINT64 handle; } client; \ parent_type *parent_name; \ }; \ } static inline void vulkan_object_init( struct vulkan_object *obj, struct vulkan_object *parent, UINT64 host_handle, struct vulkan_client_object *client ) { obj->host_handle = (UINT_PTR)host_handle; obj->client_handle = client ? (UINT_PTR)client : (UINT_PTR)obj; obj->parent = parent; if (client) client->unix_handle = (UINT_PTR)obj; } static inline void vulkan_object_init_ptr( struct vulkan_object *obj, struct vulkan_object *parent, void *host_handle, struct vulkan_client_object *client ) { vulkan_object_init( obj, parent, (UINT_PTR)host_handle, client ); } struct vulkan_instance { VULKAN_OBJECT_HEADER( VkInstance, instance, void, unused ); struct vulkan_instance_funcs funcs; void (*p_insert_object)( struct vulkan_instance *instance, struct vulkan_object *obj ); void (*p_remove_object)( struct vulkan_instance *instance, struct vulkan_object *obj ); }; static inline struct vulkan_instance *vulkan_instance_from_handle( VkInstance handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_instance *)(UINT_PTR)client->unix_handle; } struct vulkan_physical_device { VULKAN_OBJECT_HEADER( VkPhysicalDevice, physical_device, struct vulkan_instance, instance ); }; static inline struct vulkan_physical_device *vulkan_physical_device_from_handle( VkPhysicalDevice handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_physical_device *)(UINT_PTR)client->unix_handle; } struct vulkan_device { VULKAN_OBJECT_HEADER( VkDevice, device, struct vulkan_physical_device, physical_device ); struct vulkan_device_funcs funcs; }; static inline struct vulkan_device *vulkan_device_from_handle( VkDevice handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_device *)(UINT_PTR)client->unix_handle; } struct vulkan_queue { VULKAN_OBJECT_HEADER( VkQueue, queue, struct vulkan_device, device ); }; static inline struct vulkan_queue *vulkan_queue_from_handle( VkQueue handle ) { struct vulkan_client_object *client = (struct vulkan_client_object *)handle; return (struct vulkan_queue *)(UINT_PTR)client->unix_handle; } struct vulkan_surface { VULKAN_OBJECT_HEADER( VkSurfaceKHR, surface, struct vulkan_instance, instance ); }; static inline struct vulkan_surface *vulkan_surface_from_handle( VkSurfaceKHR handle ) { return (struct vulkan_surface *)(UINT_PTR)handle; } struct vulkan_swapchain { VULKAN_OBJECT_HEADER( VkSwapchainKHR, swapchain, struct vulkan_surface, surface ); }; static inline struct vulkan_swapchain *vulkan_swapchain_from_handle( VkSwapchainKHR handle ) { return (struct vulkan_swapchain *)(UINT_PTR)handle; } struct vulkan_funcs { /* Vulkan global functions. These are the only calls at this point a graphics driver * needs to provide. Other function calls will be provided indirectly by dispatch * tables part of dispatchable Vulkan objects such as VkInstance or vkDevice. */ PFN_vkGetDeviceProcAddr p_vkGetDeviceProcAddr; PFN_vkGetInstanceProcAddr p_vkGetInstanceProcAddr; /* winevulkan specific functions */ const char *(*p_get_host_surface_extension)(void); }; /* interface between win32u and the user drivers */ struct vulkan_driver_funcs { VkResult (*p_vulkan_surface_create)(HWND, VkInstance, VkSurfaceKHR *, void **); void (*p_vulkan_surface_destroy)(HWND, void *); void (*p_vulkan_surface_detach)(HWND, void *); void (*p_vulkan_surface_update)(HWND, void *); void (*p_vulkan_surface_presented)(HWND, void *, VkResult); VkBool32 (*p_vkGetPhysicalDeviceWin32PresentationSupportKHR)(VkPhysicalDevice, uint32_t); const char *(*p_get_host_surface_extension)(void); }; #endif /* WINE_UNIX_LIB */ ``` It's sharing the minimum required, each object has its own type but the macro is there to ensure a common header layout (mostly to simplify insert_object/remove_object, which can then take a simple object pointer), and the instance exports two function pointers to register object wrappers, regardless of where it is wrapped. With that I can move the surface/swapchain wrappers to win32u, while keeping only one level of indirection, while the other objects are still wrapped in winevulkan. It doesn't seem useful to move other wrappers to win32u for now, especially as some of them are more or less strongly coupled together: wine_instance uses the debug objects, wine_device_memory wrapper needs some info in the wine_phys_dev, etc. Also note that I'm thinking we could have an OpenXR icd upstream, similarly to winevulkan, for host OpenXR integration (and it'd make our life easier with Proton), and OpenXR is also interacting quite deeply with Vulkan, and would probably need to have access to the instance and device wrappers. This would mean either moving them somehow (and maybe all the wrappers) to some VK/XR shared win32u code, or use winevulkan as the XR icd too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_88726

1 0