November 2024 - Wine-gitlab

[PATCH 0/2] MR6885: cmd: Use the console output codepage to read batch files.
by Akihiro Sagawa (＠sgwaki) 25 Nov '24

25 Nov '24

To prevent performance degradation, we will cache the result returned by GetConsoleOutputCP() after executing any external command. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6885

4 6

[PATCH v2 0/1] MR6800: winegstreamer: Lock the media source critical section while using the event queue.
by Conor McCarthy (＠cmccarthy) 25 Nov '24

25 Nov '24

These changes are the documented way to implement IMFMediaEventGenerator for a media source. Avoiding using a destroyed event queue is the only reason to lock the CS that I can find. On top of !6783 it seems to resolve hanging while switching characters in Killsquad (not decisively proven though). -- v2: winegstreamer: Lock the media source critical section while using the event queue. https://gitlab.winehq.org/wine/wine/-/merge_requests/6800

4 21

[PATCH 0/2] MR6897: dplayx: Support DPMESSAGEQUEUE_RECEIVE in GetMessageQueue().
by Anton Baskanov (＠baskanov) 25 Nov '24

25 Nov '24

This allows STAR WARS Galactic Battlegrounds Saga to join and play multiplayer sessions created by native dplay. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6897

4 4

[PATCH 0/1] MR6896: dplayx: Add a few more locks (Coverity)
by Fabian Maurer (＠DarkShadow44) 25 Nov '24

25 Nov '24

It's done like this everywhere else, so add locks everywhere. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6896

3 2

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

25 Nov '24

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) 25 Nov '24

25 Nov '24

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) 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