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

[PATCH v2 0/2] MR5238: krnl386, mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.
by Alex Henrie (＠alexhenrie) 12 Mar '24

12 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56260 -- v2: mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216. krnl386: Add functions to simulate a hardware interrupt. https://gitlab.winehq.org/wine/wine/-/merge_requests/5238

3 5

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 12 Mar '24

12 Mar '24

On Tue Mar 12 13:47:41 2024 +0000, Yuxuan Shui wrote: > @Alcaro Thank you for the help! Yes, that certainly would explain your symptoms, and why I never saw those issues. That's why Proton has a beta period, isn't it? Sounds like an easy fix, easier than comparing media types. Code duplication certainly has drawbacks, but I don't think we can blame me or WineHQ for this one; if you fork an active codebase, you get merge conflicts, and sometimes even behavioral conflicts like this. We can't let a fork constrain upstream development, can we? The safest way to avoid such trouble is get your code upstreamed. The stream order is indeed not guaranteed; as long as the input video bytestream is the same, I'm trusting that the stream order is also the same. Maybe that's naive of me, maybe it is indeed safe. I didn't check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64418

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) 12 Mar '24

12 Mar '24

On Tue Mar 12 13:40:49 2024 +0000, Yuxuan Shui wrote: > I spotted the problem. In `init_stream`: > ```c > stream->wg_stream = wg_parser_get_stream(reader->wg_parser, > reader->stream_count - i - 1); > ``` > vs `reinit_stream`: > ```c > stream->wg_stream = wg_parser_get_stream(reader->wg_parser, i); > ``` > Though indeed the order of the streams is not guaranteed to stay the > same (as per @rbernon) (Sorry forgot to mention this is proton only) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64413

1 0

[PATCH 0/1] MR5290: ntdll/tests: fix size passed to GetModuleFileNameW
by Marcus Meissner (＠msmeissn) 12 Mar '24

12 Mar '24

Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5290

2 1

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) 12 Mar '24

12 Mar '24

On Tue Mar 12 13:33:27 2024 +0000, Alfred Agrell wrote: > If the mismatch is just compressed/uncompressed, then that's supposed to happen. > If they are indeed switching audio/video, then yes, they probably got > rearranged, and that does indeed sound like a bug. I didn't run into any > such trouble during my testing, but that may just have been my testing > being limited. > I never checked how those Unix-side streams are created, so I'm not sure > how that part should be solved. One solution would be to check the > streams' media types, compare to the expected type, and swap if > mismatched, but I don't know if it's the best answer; there may be a > better solution somewhere deeper inside winegstreamer. I spotted the problem. In `init_stream`: ```c stream->wg_stream = wg_parser_get_stream(reader->wg_parser, reader->stream_count - i - 1); ``` vs `reinit_stream`: ```c stream->wg_stream = wg_parser_get_stream(reader->wg_parser, i); ``` Though indeed the order of the streams is not guaranteed to stay the same (as per @rbernon) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64412

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 12 Mar '24

12 Mar '24

On Tue Mar 12 13:07:01 2024 +0000, Yuxuan Shui wrote: > Like one is audio the other is video kind of mismatch. If the mismatch is just compressed/uncompressed, then that's supposed to happen. If they are indeed switching audio/video, then yes, they probably got rearranged, and that does indeed sound like a bug. I didn't run into any such trouble during my testing, but that may just have been my testing being limited. I never checked how those Unix-side streams are created, so I'm not sure how that part should be solved. One solution would be to check the streams' media types, compare to the expected type, and swap if mismatched, but I don't know if it's the best answer; there may be a better solution somewhere deeper inside winegstreamer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64410

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) 12 Mar '24

12 Mar '24

On Tue Mar 12 13:05:23 2024 +0000, Yuxuan Shui wrote: > So what I am seeing is PE-side `reader->stream[i].format` and Unix-side > wg_parser `stream[i].preferred_format` mismatch after reinit. > I think the streams probably got re-ordered during reinit. Like one is audio the other is video kind of mismatch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64405

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) 12 Mar '24

12 Mar '24

On Tue Mar 12 12:58:04 2024 +0000, Yuxuan Shui wrote: > oh, right. sorry i got the streams mixed up So what I am seeing is PE-side `reader->stream[i].format` and Unix-side wg_parser `stream[i].preferred_format` mismatch after reinit. I think the streams probably got re-ordered during reinit. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64404

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) 12 Mar '24

12 Mar '24

On Tue Mar 12 12:22:57 2024 +0000, Alfred Agrell wrote: > `wg_parser_disconnect` and `wg_parser_destroy` frees the Unix-side > streams. `reader->streams` is PE-side, and is not affected by wg_parser_disconnect/destroy. oh, right. sorry i got the streams mixed up -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64403

1 0

[PATCH v2 0/6] MR704: vkd3d-shader/ir: Introduce a better CFG structurizer, part 5.
by Giovanni Mascellani (＠giomasce) 12 Mar '24

12 Mar '24

This applies on top of !698, the last three commits belong here. Here we reconstruct an internal representation of a structured program corresponding to the input CFG. The representation can be directly emitted (which will be the following MR) or other passes can be run on it to simplify the loop structure. -- v2: vkd3d-shader/ir: Dump the reconstructed structured program. vkd3d-shader/ir: Add jumps to the structured programs. vkd3d-shader/ir: Reconstruct a structured program. vkd3d-shader/ir: Sort loop intervals. vkd3d-shader/ir: Generate synthetic intervals for forward edges. vkd3d-shader/ir: Compute loop as intervals of the block order. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/704

2 6