September 2024 - wine-gitlab

Re: [PATCH v15 0/1] MR6453: emfdc: avoid memory leaks in get_bitmap_info - approved
by Jacek Caban (＠jacek) 13 Sep '24

13 Sep '24

This merge request was approved by Jacek Caban. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6453

1 0

[PATCH 0/4] MR6462: winemac: Use win32u for move/resize window SysCommand.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

It's not completely clear what exactly it was doing differently from win32u, but keeping the captions within the work area is probably fine for win32u, and de-duplicating this code is probably a good thing and makes later changes for DPI-based virtual display settings easier. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6462

2 5

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:31:24 2024 +0000, Ziqing Hui wrote: > Sounds like we will have 2 backend: winegstreamer and winedmo. For the > mftransforms front ends, like h264 encoder transform, h264 decoder > transform, wmv decoder dmo, will we have 2 seperate front ends? Yes, duplicating the frontend code seems like the easiest thing to do. The video encoder source could live in mfh264enc, and if we need more video encoder modules, they could share its source with PARENTSRC. Note that I haven't explored the encoding path very much yet, so we can probably not worry about it and just keep using GStreamer only for it for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82104

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:29:22 2024 +0000, Ziqing Hui wrote: > Which folder will the video_encoder.c be placed? We are putting the PE > frontend implementation of video encoder in winegstreamer now. Will we > have a duplicate video_decoder.c in winedmo folder? Sounds like we will have 2 backend: winegstreamer and winedmo. For the mftransforms front ends, like h264 encoder transform, h264 decoder transform, wmv decoder dmo, will we have 2 seperate front ends? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82103

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:05:59 2024 +0000, Rémi Bernon wrote: > I'm thinking to implement these with winedmo, while keeping the > redirection to the winegstreamer backend as default. Which folder will the video_encoder.c be placed? We are putting the PE frontend implementation of video encoder in winegstreamer now. Will we have a duplicate video_decoder.c in winedmo folder? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82102

1 0

[PATCH 0/1] MR5787: winevulkan: Use an internal NtUser call to retrieve a GPU LUID.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

Avoid taking the display_device_init mutex outside of win32u. Similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/5786, although this one doesn't cause any problems as far as I know. Still makes things simpler. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5787

3 6

[PATCH 0/10] MR4201: widl: Cleanup and simplify expressions.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

Some cleanup for expressions, sanitizing the structure a bit especially for abstract operations with multiple args. I also found out about named bison variables, implicit (as `$token` referring to `token`), or explicit (as `$name` referring to `token[name]`). I think it would make the rules much more readable so I started using them here. My plan is to add them progressively to the rules, unless there's some good reason not to (like idk how portable they are, if that's something we should be worried about). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4201

3 21

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:05:59 2024 +0000, Ziqing Hui wrote: > Will these only be implemented on top of winedmo or the winegstreamer > version will also migrate to it? I'm thinking to implement these with winedmo, while keeping the redirection to the winegstreamer backend as default. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82101

1 0

Re: [PATCH v5 0/4] MR6442: winedmo: Introduce a new DLL as a MF FFmpeg backend.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

On Fri Sep 13 08:05:43 2024 +0000, Ziqing Hui wrote: > one minor question: why this module is called wine**dmo**, from the > above comments, it sounds more like wineffmpeg. I found wineffmpeg to be awkward and didn't like the name, the libraries we use aren't even named ffmpeg but libavformat, libavcodec,... Then, there's an existing msdmo, and winedmo sounded nicer. DMOs (and now MFTs but only a few are pure MFTs, most are dual DMO-MFT objects) are the building blocks of all the windows multimedia components. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6442#note_82100

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) 13 Sep '24

13 Sep '24

Will these only be implemented on top of winedmo or the winegstreamer version will also migrate to it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82092

1 0

2025

2024

2023

2022

wine-gitlab September 2024