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

[PATCH v3 0/1] MR723: vkd3d-shader/spirv: Implement MAD in two operations if flagged as precise.
by Conor McCarthy (＠cmccarthy) March 27, 2024

March 27, 2024

This would eliminate the todo for the precise mad() test in !718. Maybe we need test results on nvidia and intel to decide if we actually want this. -- v3: vkd3d-shader/spirv: Implement MAD in two operations if flagged as precise. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/723

4 3

[PATCH 0/5] MR5412: mfreadwrite/tests: More source reader transform tests.
by Rémi Bernon March 27, 2024

March 27, 2024

First change also avoids a leak of classes (later activates) when the transform is successfully connected. The use of MFTEnumEx is necessary so that the tests work, as they use a locally registered transform. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5412

2 6

[PATCH v3 0/4] MR5137: win32u: Use strings for adapter names and use them in the adapter config keys.
by Rémi Bernon March 27, 2024

March 27, 2024

I'm not completely sure what the expectations are regarding these registry key paths, but @afrantzis said Wayland reports adapters in an arbitrary order and this would let us find the right adapter config and their current settings based on their unique name instead. Other drivers simply format the numeric ID themselves, though might not be 0-based index anymore. -- v3: win32u: Use named sources instead of struct gdi_adapter. win32u: Rename struct adapter to struct source. win32u: Use a symlink for the logically indexed adapter config key. win32u: Split writing adapter to registry to a separate helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/5137

1 4

[PATCH v5 0/1] MR5369: Draft: winegstreamer: Refactor wg_format.
by Ziqing Hui (＠zhui) March 26, 2024

March 26, 2024

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. -- v5: winegstreamer: Refactor wg_format. https://gitlab.winehq.org/wine/wine/-/merge_requests/5369

3 2

[PATCH v3 0/10] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) March 26, 2024

March 26, 2024

I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally. As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata. A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with. Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators. -- v3: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs. vkd3d-shader/hlsl: Store state block on pass variables. vkd3d-shader/hlsl: Parse list of state blocks. vkd3d-shader/hlsl: Introduce hlsl_ir_stateblock_constant. vkd3d-shader/hlsl: Parse and store state blocks on variables. tests: Add tests for "compile" and CompileShader() syntax. tests: Add tests for fxgroup syntax. tests: Test function call syntax for state blocks. tests: Add more state block syntax tests. vkd3d-shader/hlsl: Also call dce before lowering deref paths. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739

4 32

[PATCH v9 0/1] MR5402: wmic.exe: Support interactive mode and piped commands
by Louis Lenders (＠xe) March 26, 2024

March 26, 2024

See also https://bugs.winehq.org/show_bug.cgi?id=56361 This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands. (probably used by program in aforementioned bugreport) Also support interactive mode (wine wmic.exe) Marked for now as draft. -- v9: wmic.exe: Support interactive mode and piped commands. https://gitlab.winehq.org/wine/wine/-/merge_requests/5402

3 2

[PATCH v6 0/2] MR5402: wmic.exe: Support interactive mode and piped commands
by Louis Lenders (＠xe) March 26, 2024

March 26, 2024

See also https://bugs.winehq.org/show_bug.cgi?id=56361 This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands. (probably used by program in aforementioned bugreport) Also support interactive mode (wine wmic.exe) Marked for now as draft. -- v6: put processing args in seperate function https://gitlab.winehq.org/wine/wine/-/merge_requests/5402

3 3

[PATCH v5 0/1] MR5402: wmic.exe: Support interactive mode and piped commands
by Louis Lenders (＠xe) March 26, 2024

March 26, 2024

See also https://bugs.winehq.org/show_bug.cgi?id=56361 This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands. (probably used by program in aforementioned bugreport) Also support interactive mode (wine wmic.exe) Marked for now as draft. -- v5: wmic.exe: Support interactive mode and piped commands. https://gitlab.winehq.org/wine/wine/-/merge_requests/5402

2 1

[PATCH v3 0/1] MR5402: wmic.exe: Support interactive mode and piped commands
by Louis Lenders (＠xe) March 26, 2024

March 26, 2024

See also https://bugs.winehq.org/show_bug.cgi?id=56361 This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands. (probably used by program in aforementioned bugreport) Also support interactive mode (wine wmic.exe) Marked for now as draft. -- v3: wmic.exe: Support interactive mode and piped commands. https://gitlab.winehq.org/wine/wine/-/merge_requests/5402

3 2

[PATCH v4 0/2] MR5402: wmic.exe: Support interactive mode and piped commands
by Louis Lenders (＠xe) March 26, 2024

March 26, 2024

See also https://bugs.winehq.org/show_bug.cgi?id=56361 This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands. (probably used by program in aforementioned bugreport) Also support interactive mode (wine wmic.exe) Marked for now as draft. -- v4: fix typo https://gitlab.winehq.org/wine/wine/-/merge_requests/5402

2 2