- wine-gitlab - winehq.org

[PATCH 0/1] MR7240: po: Update Georgian translation
by Ekaterine Papava (＠EkaterinePapava) 02 Feb '25

02 Feb '25

Hello, Small updates for Georgian translation. BR, Ekaterine -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7240

1 0

[PATCH v2 0/5] MR7167: windowscodecs/metadatahandler: Implement GetPersistOptions().
by Nikolay Sivov (＠nsivov) 01 Feb '25

01 Feb '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: windowscodecs/metadata: Add initial implementation of the App1 reader. windowscodecs/metadata: Add registration information for the Exif reader. windowscodecs/metadata: Add registration information for the Gps reader. windowscodecs/metadatahandler: Implement GetStream(). windowscodecs/metadatahandler: Implement GetPersistOptions(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7167

3 6

[PATCH 0/2] MR7211: windowscodecs: Implement IWICBitmapFlipRotator(WICBitmapTransformRotate90) for bitmaps with bpp >= 8.
by Dmitry Timoshkov (＠dmitry) 01 Feb '25

01 Feb '25

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

4 8

[PATCH 0/2] MR7239: user32/tests: Account for a couple of frequent failures.
by Esme Povirk (＠madewokherd) 01 Feb '25

01 Feb '25

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

3 3

[PATCH v6 0/5] MR6889: threadpoolwinrt: Implement IAsyncAction and IAsyncInfo.
by Vibhav Pant (＠vibhavp) 01 Feb '25

01 Feb '25

This MR adds an implementation for the `IAsyncAction` and `IAsyncInfo` interfaces exported by `Windows.System.Threading`, including support for setting `IAsyncActionCompletedHandler` values for an `IAsyncAction`. It also re-writes (or factors?) the `IAsyncOperation<boolean>` implementation in dlls/cryptowinrt to use `ThreadPoolStatics::RunAsync`, by introducing a type-punning variant of `AsyncOperationCompletedHandler<T>` (similar to `WineAsyncOperationCompletedHandler`), which is a wrapper around the `IAsyncAction` returned by `RunAsync`. The new `IAsyncOperation<T>` implementation is simpler, and if merged, can be exported to other dlls (windows.gaming.input and windows.security.credentials.ui.userconsentverifier for now). -- v6: cryptowinrt: Rewrite IAsyncOperation using Windows.System.Threading. https://gitlab.winehq.org/wine/wine/-/merge_requests/6889

3 9

[PATCH v5 0/3] MR7237: Draft: include: Fix ReadNoFence64 on i386.
by Jinoh Kang (＠iamahuman) 01 Feb '25

01 Feb '25

64-bit volatile accesses are not atomic on i386. Both i686-w64-mingw32-gcc and x86 MSVC splits 64-bit loads into a pair of load/store ops. Fix this by using a FILD/FISTP pair, which is also used to implement C11 atomics by i686-w64-mingw32-gcc. Fixes: f82b1c1fcf770a5d6fa02c3f286282be79a201b8 -- v5: include: Prevent misuse of __WINE_ATOMIC_* helper macros for non-atomic large accesses. server: Fix incorrect usage of __WINE_ATOMIC_STORE_RELEASE in SHARED_WRITE_BEGIN/SHARED_WRITE_END. include: Fix ReadNoFence64 on i386. https://gitlab.winehq.org/wine/wine/-/merge_requests/7237

2 4

[PATCH 0/1] MR7238: winebus,mmdevapi: implement audio device container id
by Harald Sitter (＠sitter) 01 Feb '25

01 Feb '25

This is a bit convoluted because of the amount of pieces involved. I'll try to untangle things a bit. The container id is meant to be globally unique and stable. We therefore need a suitable amount of stable entropy that we can feed into a hash function to get a stable and unique output. This happens in winebus. The corner stone of hash inputs is the linux device topology (sysfs path) obtained via udev. Along with all other possible data we feed this into a hash function to obtain our container id. A bunch of extra wine-specific keys needed to be added to carry the necessary metadata from the driver into the ntoskrnl (where it gets written to the property registry of the relevant device). Separate from this we also ingest the linux device topology (sysfs path) in the winepulse driver. In mmdevapi we then use winepulse's sysfs path to find the matching device in the setupapi and query its container id. We now have the same container id in both the device and the MMDevice, allowing applications (in particular Games) to find the MMDevice for a given device. For practical reasons we always resolve the sysfs path to the root device as early as possible. Container ids are meant to be equal for sub devices inside a "container" anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7238

3 2

[PATCH v3 0/6] MR7233: wineswmidi: Add SW Synth MIDI driver part 0.
by Anton Baskanov (＠baskanov) 01 Feb '25

01 Feb '25

-- v3: wineswmidi: Initialize DirectMusic when opening the device. wineswmidi: Handle MODM_OPEN and MODM_CLOSE. https://gitlab.winehq.org/wine/wine/-/merge_requests/7233

3 8

[PATCH v2 0/6] MR7233: wineswmidi: Add SW Synth MIDI driver part 0.
by Anton Baskanov (＠baskanov) 01 Feb '25

01 Feb '25

-- v2: wineswmidi: Initialize DirectMusic when opening the device. wineswmidi: Handle MODM_OPEN and MODM_CLOSE. https://gitlab.winehq.org/wine/wine/-/merge_requests/7233

3 8

[PATCH v4 0/2] MR7237: include: Fix ReadNoFence64 on i386.
by Jinoh Kang (＠iamahuman) 01 Feb '25

01 Feb '25

64-bit volatile accesses are not atomic on i386. Both i686-w64-mingw32-gcc and x86 MSVC splits 64-bit loads into a pair of load/store ops. Fix this by using a FILD/FISTP pair, which is also used to implement C11 atomics by i686-w64-mingw32-gcc. Fixes: f82b1c1fcf770a5d6fa02c3f286282be79a201b8 -- v4: include: Prevent misuse of __WINE_ATOMIC_* helper macros for non-atomic large accesses. include: Fix ReadNoFence64 on i386. https://gitlab.winehq.org/wine/wine/-/merge_requests/7237

4 6

2025

2024

2023

2022

wine-gitlab