November 2025 - Wine-GitLab

Re: [PATCH v2 0/1] MR8509: hid: Implement HidP_SetData.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

This has been merged as https://gitlab.winehq.org/wine/wine/-/merge_requests/9495, thank you! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8509#note_122743

1 0

[PATCH 0/3] MR9510: win32u: Implement timeline semaphore rewinding.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

Pretty much the same kind of thing Proton does, this is only for non-shared semaphores for now. This creates timeline events backed by host timeline semaphores, for every wait and signal operation on a client timeline semaphore. Events are host timeline semaphores with monotonically increasing values. One event is a `(host semaphore, value)` unique tuple, and their value is incremented every time they get signaled. They can be reused right away as a different event, with the new value. Signaled events are queued to a per-device event list for reuse, as we cannot safely destroy them [^1] and as creating them might be costly. A thread is spawned for every device that uses timeline semaphores, monitoring the events and semaphore value changes. The semaphore wrapper keeps the current client semaphore value, which is read directly by `vkGetSemaphoreCounterValue`. CPU and GPU waits on the client semaphore are swapped with a wait on a timeline event, and GPU signals with a signal on a timeline event. CPU signals simply update the client semaphore value on the wrapper, signaling the timeline thread to check and notify any waiter. The timeline thread waits on signal events, coming from the GPU, and on a per-device semaphore for CPU notifications (wait/signal list updates, CPU-side signal). It will then signal any pending wait for a client semaphore value that has been reached, and removes timed out waits. --- For shared semaphores my idea is to use the client timeline semaphore host handle itself as a signal to notify other device threads of semaphore value changes, as the host semaphore is what is exported and imported in other devices. The timeline threads would wait on that semaphore too in addition to the signal events and thread notification semaphore. The main issue with shared semaphores actually comes from sharing the client semaphore values, so that they can be read from each device timeline threads as well as from other processes. There's two scenarios to support, one that is for in-process sharing which could perhaps keep the information locally, but we also need to support cross-process sharing so I think there's no other way than to involve wineserver. My idea then is to move shared semaphore client value to wineserver, which will cost a request on every signal and wait (and reading the value for waits could later be moved to a shared memory object). This will also allow us to implement `D3DKMTWaitForSynchronizationObjectFromCpu` which might be useful for D3D12 fence implementation as it'll allow us to translate a timeline semaphore wait to an asynchronous NT event signal. [^1]: Vulkan spec indicates that semaphores may only be destroyed *after* every operation that uses them has fully executed, and it's unclear whether signaling or waiting a semaphore is enough as an indicator for full execution or whether we would need to wait on a submit fence. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9510

1 4

[PATCH 0/1] MR9509: win32u: Avoid crashing if Vulkan is disabled or failed to load.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

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

2 2

Re: [PATCH v3 0/4] MR9493: win32u: Move device and instance wrappers from winevulkan.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

On Tue Nov 18 08:06:53 2025 +0000, Rémi Bernon wrote: > Ah right thanks and sorry about that. It's not very surprising actually, > it probably crashes and breaks everything. https://gitlab.winehq.org/wine/wine/-/merge_requests/9509 should fix it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9493#note_122728

1 0

Re: [PATCH v3 0/4] MR9493: win32u: Move device and instance wrappers from winevulkan.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

On Tue Nov 18 08:06:53 2025 +0000, Martin Storsjö wrote: > This change (in particular, commit "win32u: Use the vulkan instance > wrappers for D3DKMT.") broke builds without Vulkan (e.g. > `--without-vulkan`). Starting up (in a clean prefix) prints: > ``` > 004c:err:vulkan:vulkan_init_once Wine was built without Vulkan support. > [5 minute wait] > 0024:err:environ:run_wineboot boot event wait timed out > wine: could not load kernel32.dll, status c0000135 > ``` > This looks highly surprising, but seems reproducible. I'll skip digging > further and leave it up to you to figure out why this gets broken. Ah right thanks and sorry about that. It's not very surprising actually, it probably crashes and breaks everything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9493#note_122724

1 0

[PATCH v4 0/1] MR9496: shlwapi: make StrFromTimeIntervalA and StrFromTimeIntervalW more like windows xp
by Alanas Tebuev (＠BZZZZ) Nov. 18, 2025

Nov. 18, 2025

<a href="https://mh-nexus.de/en/downloads.php?product=HxD20">hxd</a> <code>Analyzing...</code> dialog calls <code>StrFromTimeIntervalW</code> with <code>lpszStr</code>=0 to get length of <code> 30 sec</code> text and calls <code>StrFromTimeIntervalW</code> with non-0 <code>lpszStr</code> to get <code> 30 sec</code> text <img src="/uploads/6209a82d2aa063d355147034ceccc9ff/hxd.webp" alt="hxd "Analyzing..." dialog showing "Remaining time: 30 sec""> -- v4: shlwapi: make StrFromTimeIntervalA and StrFromTimeIntervalW more like windows xp https://gitlab.winehq.org/wine/wine/-/merge_requests/9496

2 1

Re: [PATCH v3 0/4] MR9493: win32u: Move device and instance wrappers from winevulkan.
by Martin Storsjö Nov. 18, 2025

Nov. 18, 2025

This change (in particular, commit "win32u: Use the vulkan instance wrappers for D3DKMT.") broke builds without Vulkan (e.g. `--without-vulkan`). Starting up (in a clean prefix) prints: ``` 004c:err:vulkan:vulkan_init_once Wine was built without Vulkan support. [5 minute wait] 0024:err:environ:run_wineboot boot event wait timed out wine: could not load kernel32.dll, status c0000135 ``` This looks highly surprising, but seems reproducible. I'll skip digging further and leave it up to you to figure out why this gets broken. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9493#note_122721

1 0

[PATCH 0/4] MR9508: winex11: Track more window state to avoid unnecessary requests.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

We don't track the corresponding property changes, because it seems like they sometimes are different from what was requested [^1], and that would defeat the purpose of this MR. This shouldn't matter and there's actually no reason for the properties to change as these are direct property change requests. [^1]: At least for me on XWayland, the differences seem mostly about x/y position hints, and they might come from XWayland quirks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9508

1 4

[PATCH v2 0/5] MR9506: dmsynth: DLS fixes, part 1
by Anton Baskanov (＠baskanov) Nov. 18, 2025

Nov. 18, 2025

-- v2: dmsynth: Use a factor of 1/10 for modulation LFO x channel pressure -> gain connections. dmsynth: Handle channel pressure events. dmsynth: Don't add 1000 to the sustain modulators. dmsynth: Use 0.1% as the sustain level unit. dmsynth/tests: Add DLS tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9506

3 8

[PATCH 0/1] MR9507: winex11: Avoid unmapping window if it only got layered style.
by Rémi Bernon Nov. 18, 2025

Nov. 18, 2025

Layered window will need to be explicitly hidden, after layered style is added, and we shouldn't hide them ourselves as the style might just get removed right away. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58984 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9507

1 1