- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR1368: vbscript: Use CRT allocation functions. - approved
by Alexandre Julliard (＠julliard) 15 Nov '22

15 Nov '22

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

1 0

Re: [PATCH v2 0/4] MR1361: kernel32: Validate globalmem pointers before calling heap functions. - approved
by Alexandre Julliard (＠julliard) 15 Nov '22

15 Nov '22

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

1 0

Re: [PATCH v4 0/6] MR1298: winegstreamer: MPEG layer-3 decoder output media type enumeration and allocator properties. - approved
by Alexandre Julliard (＠julliard) 15 Nov '22

15 Nov '22

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

1 0

Re: [PATCH v2 0/1] MR1367: ws2_32: Return success for setting SO_ERROR. - approved
by Alexandre Julliard (＠julliard) 15 Nov '22

15 Nov '22

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

1 0

[PATCH v2 0/7] MR1301: Add ir50_32 video codec for winmm.
by Shaun Ren (＠shaunren) 15 Nov '22

15 Nov '22

This video codec is used by games such as Richman 4, and Zwei: The Arges Adventure. The decoder logic is based on code from the FFmpeg project. -- v2: loader/wine.inf: Enable ir50_32 video codec. ir50_32: Implement decompression to 15-bit RGB. https://gitlab.winehq.org/wine/wine/-/merge_requests/1301

5 14

[PATCH 0/2] MR1295: Enable compilation with long types in d3dx9_36/tests.
by eric pouech (＠epo) 15 Nov '22

15 Nov '22

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

3 4

[PATCH v16 0/1] MR672: comdlg32: Common item dialog fixes
by Ben Cottrell (＠bgc) 15 Nov '22

15 Nov '22

Made changes to comdlg32/itemdlg.c to add missing controls, which are the address bar and the up button. Updated bitmaps in comctl32 and SVG files for history icons. My changes help to resolve this bug: https://bugs.winehq.org/show_bug.cgi?id=50338. -- v16: comdlg32: Add missing controls and their functionality to IFileDialog, or the common item dialog. https://gitlab.winehq.org/wine/wine/-/merge_requests/672

4 4

Re: [PATCH v3 0/4] MR1311: wmvcore: Implement DedicatedDeliveryThread async reader output setting.
by Zebediah Figura (＠zfigura) 15 Nov '22

15 Nov '22

Zebediah Figura (@zfigura) commented about dlls/wmvcore/async_reader.c: > struct stream *stream = arg; > struct async_reader *reader = stream->reader; > struct sample *sample; > + WCHAR buffer[256]; > HRESULT hr; > > TRACE("reader %p, number %u\n", reader, stream->number); > > + swprintf(buffer, ARRAY_SIZE(buffer), L"wine_wmreader_stream_%u_read", stream->number); > + SetThreadDescription(GetCurrentThread(), buffer); Linux cuts off thread names at 15 characters (not counting the null terminator), which somewhat unfortunately makes all of these identical to each other and the deliver threads. Thus far I think Brendan had been trying to make the thread names distinct, if not per se trying to fit the entire name within 15 characters. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15868

1 0

Re: [PATCH v3 0/4] MR1311: wmvcore: Implement DedicatedDeliveryThread async reader output setting.
by Zebediah Figura (＠zfigura) 15 Nov '22

15 Nov '22

> We need the read threads to always be running and returning their next sample because we then deliver them in PTS order. Somewhat out of curiosity, did you check whether this still applies when DedicatedDeliveryThread is set? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15869

1 0

Re: [PATCH v3 0/4] MR1311: wmvcore: Implement DedicatedDeliveryThread async reader output setting.
by Zebediah Figura (＠zfigura) 15 Nov '22

15 Nov '22

On Mon Nov 14 12:05:16 2022 +0000, Rémi Bernon wrote: > I don't think we need to check it here anymore with the latest version. > Deselected streams will never have pending read requests (or they will > shortly complete it after deselection, with either error or a last sample). I guess, but it depends on the fact that "read_result" is zero-initialized and never written, which seems non-obvious and a little fragile. In fact, I think it can already break if a stream was selected and then later becomes deselected, even if the filter was stopped in between. Checking "stream->read_requested" would be more obvious but I think still broken for the same reasons (but simple enough to fix.) Note that if you do that then read_result becomes superfluous and doesn't really need to be stored anywhere. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15867

1 0

2025

2024

2023

2022

wine-gitlab