November 2024 - Wine-GitLab

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

Nov. 25, 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. -- v3: 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 vulkan_(device|instance)_funcs in wine/vulkan.h. win32u: Use PFN_* typedefs for vulkan function pointers. winevulkan: Add missing wine_vkGetPhysicalDeviceSurfaceFormatsKHR manual wrapper. https://gitlab.winehq.org/wine/wine/-/merge_requests/6427

1 9

[PATCH v2 0/1] MR6893: msi: Use mybool instead of bool as variable name.
by Gerald Pfeifer (＠gerald) Nov. 25, 2024

Nov. 25, 2024

bool is a reserved identifier in C23 and would break with GCC 15 moving to -std=gnu23 (based on C23). Use mybool instead, along the line of myint in the same context. -- v2: msi: Use mybool instead of bool as variable name. https://gitlab.winehq.org/wine/wine/-/merge_requests/6893

3 2

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

Nov. 24, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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 Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

-- 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ė Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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) Nov. 23, 2024

Nov. 23, 2024

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