--
v5: mf: Shutdown all used topologies by media session.
mf/tests: Test how session releases not queued topologies.
mf: Only shutdown current topology when session is shutdown.
mf/tests: Test for topology reuse after session ends.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4443
This is part XXV of command engine rewrite.
This MR tackles three items:
- fixing some corner cases in variable expansion. Note, there's
still todo_wine in the non regression tests, but I don't feel
like fixing them for now (like an un-paired ! within double quotes
when delayed expansion is enabled - which behaves differently
then not within double quotes)
- breaking out of FOR loops with 'EXIT /B'. I'm damn sure I
dealt with this earlier on, it likely fails into the cracks
during some rebase.
- somme builtin commands behave differently when run from .BAT
or .CMD files.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6537
On Wed Sep 18 13:32:52 2024 +0000, Rémi Bernon wrote:
> Maybe, but I don't think it matters so much here. It's just reading
> compressed samples here, so copy size stays relatively small.
Do you intend on also enabling protonvideoconvert through winedmo? If so, wouldn't we have to do it in the demuxer (doesn't mp4 demuxer also require steam://unlockh264), at which point this might be relavant.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6517#note_82731
Virtualizing the swapchain is the better and more general plan and something we'd need to do for Wayland cross-process rendering anyway. Implementing composition on the win32u level will take care of it in a generic way, though we probably want to keep the direct rendering path as a default and best option.
This current approach is a best effort with what we have right now, it unlocks various applications which required VK child window rendering, and is cheap enough and doesn't introduce much problems as it simply does the same as GL.
Both GL and VK would then be addressed the same way for composition, through dma-buf export (or the equivalent macOS primitive) and shared resources.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82704
> > VK_KHR_present_wait isn't equivalent, because it signals the event on first pixel out, which is too soon.
>
> That's unfortunate, I was thinking VK_KHR_present_wait will solve these problems (which are real WRT games too in some cases) until we have a "direct composition" implementation. Are you sure that this is supposed and actual behaviour?
It's the spec behaviour, actually. I didn't test whether it works in practice, and it's not unlikely that it does work in practice.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82702
> VK_KHR_present_wait isn't equivalent, because it signals the event on first pixel out, which is too soon.
That's unfortunate, I was thinking VK_KHR_present_wait will solve these problems (which are real WRT games too in some cases) until we have a "direct composition" implementation. Are you sure that this is supposed and actual behaviour?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82701
I don't think this architecture is going to work. It probably isn't evident from games testing, but there is a synchronization problem here. We can't simply do vkQueuePresent() and then copy from the corresponding X11 drawable, because vkQueuePresent() won't guarantee that the bits have reached the X11 drawable yet.
For GLX this approach is fine, assuming we have GLX_OML_sync_control. In that case waiting for SBC is exactly what we need.
Vulkan doesn't have an equivalent extension. VK_KHR_present_wait isn't equivalent, because it signals the event on first pixel out, which is too soon.
This means we probably need to virtualize the whole swapchain, unfortunately, and either create a Vulkan swapchain on the relevant top-level window, or use DRI3 to interop between Vulkan and X11 without a swapchain. In this case vkQueuePresent() would of course not present directly.
We could also try to invent an extension that lets us do what GLX_OML_sync_control does, but I fear that Mesa and/or Khronos will push back on this, and basically tell us to fix it on our end, by virtualizing the swapchain...
There may be reasons we can't virtualize the swapchain that I'm not thinking of. I also have zero knowledge of Wayland and don't know how to fit that into anything.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82685
Excluding winedump for now, since it has a lot of tricky sprintf calls to replace
--
v2: wrc: Replace sprintf with snprintf to avoid deprecation warnings on macOS.
wmc: Replace sprintf with snprintf to avoid deprecation warnings on macOS.
winebuild: Replace sprintf with snprintf to avoid deprecation warnings on macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6524
Under the HKCU\Software\Wine\X11 Driver global or application-specific HKCU\Software\Wine\AppDefaults\app.exe\X11 Driver registry keys.
This option can be used to restore the old behavior with DPI awareness forced on every application, which some of them handled well enough even if not DPI aware otherwise.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57175
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6521