April 2025 - Wine-gitlab - list.winehq.org

Re: [PATCH v4 0/1] MR7870: kernelbase: fix racing condition in GlobalMemoryStatusEx() - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7870

1 0

Re: [PATCH v5 0/2] MR7771: win32u: Make font handle table dynamically growable. - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7771

1 0

Re: [PATCH v2 0/2] MR7892: winewayland: Always check the role to determine whether a surface is a toplevel. - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7892

1 0

Re: [PATCH v6 0/1] MR7781: combase: Add stub for RoOriginateErrorW. - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7781

1 0

Re: [PATCH v3 0/1] MR7859: gdi32/tests: Remove one test for NtGdiMakeFontDir. - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7859

1 0

Re: [PATCH v2 0/1] MR7891: winewayland: Support building with older EGL headers. - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7891

1 0

Re: [PATCH v2 0/2] MR7890: msvcrt: Avoid dynamic allocation when storing locale name. - approved
by Alexandre Julliard (＠julliard) 24 Apr '25

24 Apr '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7890

1 0

[PATCH 0/1] MR7837: shell32/tests: Avoid hang in test_rename.
by Bernhard Übelacker 24 Apr '25

24 Apr '25

Followup of 0eab97ffa8. Usually version checks have to be avoided, but this modifies a pre-existing version check to skip that single test just with Windows 7. [Test pattern page.](https://test.winehq.org/data/patterns.html#shell32:shlfileop) [Testbot run with this patch included.](https://testbot.winehq.org/JobDetails.pl?Key=157955) CC: @zhui -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7837

3 9

Re: [PATCH v5 0/2] MR7833: mf: Update state and start clock for both paused and stopped.
by Brendan McGrath (＠redmcg) 24 Apr '25

24 Apr '25

On Thu Apr 24 21:00:45 2025 +0000, Nikolay Sivov wrote: > Yes, if you resume from same position it will be assumed that source > produces sane time mark in the event. But there are a lot of assumptions > already, and it's relatively fragile on Windows in other aspects once > you start to go off default behavior. > Regarding multiple sources, as I recall it works in general, e.g. you > can have two completely separate video rendering branches (topoedit > could be used for testing), and it works reliably. Which one is correct > we can only test manually, if you return time+10 for one source and > time+20 another source and see which one reaches the sink clock state > method. What I haven't tried is using two separate source branches and > checking if same clock instance is used for both sinks. If it's doing > something mad and creates one clock per branch, next question would be > what happens to the junction nodes, like transforms with multiple inputs > where streams converging (there is an optional IMFClockConsumer thing > where you can obviously use only one clock). FYI - I just edited my comment above: https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101671 as I had missed a step. It calls `IMFMediaSource::Stop` before flushing the MFT. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101828

1 0

Re: [PATCH v5 0/2] MR7833: mf: Update state and start clock for both paused and stopped.
by Nikolay Sivov (＠nsivov) 24 Apr '25

24 Apr '25

On Thu Apr 24 20:50:29 2025 +0000, Brendan McGrath wrote: > I think Windows' approach has merit if we are requesting a new start > time, but for resumption I don't think it does. They don't perform any > of the flushing in this scenario. So if the source changes the position > significantly, then all the sinks and MFTs will have stale data. I guess > they just rely on the source not doing that on resumption. > But the other issue is, as you say, there will now be multiple sources > of truth. If we get different values from all the different streams, > which one is correct? Yes, if you resume from same position it will be assumed that source produces sane time mark in the event. But there are a lot of assumptions already, and it's relatively fragile on Windows in other aspects once you start to go off default behavior. Regarding multiple sources, as I recall it works in general, e.g. you can have two completely separate video rendering branches (topoedit could be used for testing), and it works reliably. Which one is correct we can only test manually, if you return time+10 for one source and time+20 another source and see which one reaches the sink clock state method. What I haven't tried is using two separate source branches and checking if same clock instance is used for both sinks. If it's doing something mad and creates one clock per branch, next question would be what happens to the junction nodes, like transforms with multiple inputs where streams converging (there is an optional IMFClockConsumer thing where you can obviously use only one clock). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101827

1 0