March 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v7 0/2] MR5255: winegstreamer: Append an optional parser before decoders in wg_transform. - approved
by Alexandre Julliard (＠julliard) 21 Mar '24

21 Mar '24

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

1 0

[PATCH v3 0/9] MR5329: ddraw: Support multiple devices per ddraw object.
by Paul Gofman (＠gofman) 21 Mar '24

21 Mar '24

Fixes Sim City 3000 Building Architect. -- v3: ddraw/tests: Add tests for multiple devices. ddraw: Support multiple devices per ddraw object. ddraw: Sync wined3d render target in d3d_device_sync_rendertarget(). ddraw: Store wined3d state in d3d_device. wined3d: Factor out wined3d_texture_set_lod() function. ddraw: Don't apply state in ddraw_surface_blt(). ddraw: Store matrix handle in the global table. ddraw: Store surface handles in the global table. ddraw: Store material handles in the global table. https://gitlab.winehq.org/wine/wine/-/merge_requests/5329

4 13

[PATCH 0/1] MR5380: Draft: netapi32: Add NetRemoteTOD stub.
by Vijay Kiran Kamuju (＠infyquest) 21 Mar '24

21 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56369 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5380

3 2

[PATCH 0/1] MR5379: kernel32: Make MakeCriticalSectionGlobal() a noop.
by Paul Gofman (＠gofman) 21 Mar '24

21 Mar '24

This fixes a performance regression introduced by 8b3944e1341baaf693927c8b758851d2dbba725a ("ntdll: Only allocate debug info in critical sections with RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO."). Critical section was using a fallback semaphore path if no debug info is present. That was apparently to support MakeCriticalSectionGlobal() which was deprecated and removed from kernel32 exports around Win2000. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5379

2 2

Re: [PATCH v2 0/7] MR5261: ntdll: Only allocate debug info in critical sections with RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO.
by Paul Gofman (＠gofman) 21 Mar '24

21 Mar '24

@rbernon The change which the blamed commit (unintentionally) introduced is that after loosing debug info critical sections started to use slower semaphore path. I sent a patch for that (https://gitlab.winehq.org/wine/wine/-/merge_requests/5379) which fixes mentioned 2 mf tests here. But I think that blamed patch most likely only uncovered a pre-existing race in either mf implementation or mf tests, I didn't debug that part. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5261#note_65695

1 0

[PATCH v5 0/1] MR5357: d3dcompiler: Add D3DX11CreateThreadPump stub.
by Vijay Kiran Kamuju (＠infyquest) 21 Mar '24

21 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56176 -- v5: d3dcompiler: Add D3DX11CreateThreadPump stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/5357

3 2

[PATCH 0/4] MR5378: advapi32/tests: Cleanup after RegLoadKey tests
by Piotr Caban (＠piotr) 21 Mar '24

21 Mar '24

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

2 4

[PATCH 0/1] MR5377: winedump: Fix REG_DWORD dumping with no data.
by Piotr Caban (＠piotr) 21 Mar '24

21 Mar '24

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

2 1

[PATCH 0/1] MR5376: mmdevapi: Make IMMDeviceCollection immutable after creation.
by Brendan Shanks (＠bshanks) 21 Mar '24

21 Mar '24

This matches the Windows behavior: the contents/size of an IMMDeviceCollection do not change after it's created. Any unplugged devices remain in the collection (but with a changed state). This shouldn't change anything on Wine since it currently doesn't add/remove devices after initialization, but is needed to add that in the future. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5376

2 1

[PATCH 0/1] MR5369: Draft: winegstreamer: Refactor wg_format.
by Ziqing Hui (＠zhui) 21 Mar '24

21 Mar '24

Since we are adding more and more media formats to wg_format, the current wg_format struct is getting ugly. Everytime we add a video format, we need to duplicate width, height, fps. Everytime we add a audio format, we need to duplicate channels, rate. So it would be better if we could share width, height, fps fields between different video formats, also share channels and rate fields between different audio formats. What makes me found the current wg_format is not in a good shape is when I was writting code for Proton, I found that I need to write some code like this if want to get width/height/fps from a wg_format: ``` static bool get_video_info_from_wg_format(struct wg_format *format, int32_t *width, int32_t *height, uint32_t *fps_n, uint32_t *fps_d) { switch (format->major_type) { case WG_MAJOR_TYPE_VIDEO: *width = format->u.video.width; *height = format->u.video.height; *fps_n = format->u.video.fps_n; *fps_d = format->u.video.fps_d; return true; case WG_MAJOR_TYPE_VIDEO_CINEPAK: *width = format->u.video_cinepak.width; *height = format->u.video_cinepak.height; *fps_n = format->u.video_cinepak.fps_n; *fps_d = format->u.video_cinepak.fps_d; return true; case WG_MAJOR_TYPE_VIDEO_H264: *width = format->u.video_h264.width; *height = format->u.video_h264.height; *fps_n = format->u.video_h264.fps_n; *fps_d = format->u.video_h264.fps_d; return true; case WG_MAJOR_TYPE_VIDEO_WMV: *width = format->u.video_wmv.width; *height = format->u.video_wmv.height; *fps_n = format->u.video_wmv.fps_n; *fps_d = format->u.video_wmv.fps_d; return true; case WG_MAJOR_TYPE_VIDEO_INDEO: *width = format->u.video_indeo.width; *height = format->u.video_indeo.height; *fps_n = format->u.video_indeo.fps_n; *fps_d = format->u.video_indeo.fps_d; return true; case WG_MAJOR_TYPE_VIDEO_MPEG1: *width = format->u.video_mpeg1.width; *height = format->u.video_mpeg1.height; *fps_n = format->u.video_mpeg1.fps_n; *fps_d = format->u.video_mpeg1.fps_d; return true; default: GST_ERROR("Type %d is not a video format.\n", format->major_type); return false; } } ``` Apparently, the code above is ugly. By refactoring wg_format, we can avoid code like this. This patch is a draft now, it only contains unixlib.h code. Zeb, I'd like to confirm that if this refactoring would be acceptable for you. If do, I'll continue finishing the remaining parts. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5369

4 3