February 2024 - wine-gitlab

[PATCH 0/1] MR5184: winecrt0: Use load config on all targets.
by Jacek Caban (＠jacek) 28 Feb '24

28 Feb '24

Based on mingw-w64. System modules on Windows have load config available. In fact, all applications using the default MSVC for crt have it. mingw-w64 provides the load config, but it also requires linker to use it and currently only LLD supports it. This MR does the same in winecrt0. We will need it on both ARM64 and ARM64EC targets to support ARM64X (which requires LLD for other reasons anyway). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5184

3 2

[PATCH 0/1] MR5185: gdiplus: Fix crash in GdipAddPathString.
by Esme Povirk (＠madewokherd) 28 Feb '24

28 Feb '24

Apparently, 1454ffe7ddf01226aacec07836d4afa62fecd3fa introduced the assumption that the font passed to gdip_format_string is non-NULL, and GdipAddPathString wasn't passing it in. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5185

2 1

[PATCH v2 0/5] MR5120: mfreadwrite/reader: Implement source reader decoder / video processor pipelines.
by Rémi Bernon (＠rbernon) 28 Feb '24

28 Feb '24

-- v2: mfreadwrite/reader: Implement IMFSourceReaderEx_GetTransformForStream. mfreadwrite/reader: Create and append a converter transform. mfreadwrite/reader: Keep the stream transforms in a list. mfreadwrite/reader: Call SetOutputType directly on the decoder transform. mfreadwrite/reader: Split source_reader_create_decoder_for_stream helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/5120

3 8

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 28 Feb '24

28 Feb '24

On Wed Feb 28 11:16:58 2024 +0000, Stefan Dösinger wrote: > This is more a curiosity rather than something that needs to be > addressed in this patch: Dies CreateDeviceFromClipper fail if the > clipper has no window (but instead a cliplist or simply nothing)? > I would expect it to fail, but otoh SetCooperativeLevel on a NULL HWND > works in DDSCL_NORMAL I think. I had checked the no-window scenario (on WinXP) and IIRC, it treated coordinates as screen coordinates. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62946

1 0

[PATCH v6 0/12] MR672: vkd3d-shader/ir: Introduce a better CFG structurizer, part 3.
by Giovanni Mascellani (＠giomasce) 28 Feb '24

28 Feb '24

This applies on top of !662, the last four commits belong here. Here we compute a topological order (plus some additional properties) of the shader blocks. Eventually the blocks will be emitted precisely in this order, after having been enriched with structured control flow information. -- v6: vkd3d-shader/ir: Keep loops contiguous in the topological sort. vkd3d-shader/ir: Dump the topological order of the control flow graph. vkd3d-shader/ir: Topologically sort the control flow graph. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/672

2 16

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 28 Feb '24

28 Feb '24

On Wed Feb 28 11:16:57 2024 +0000, Stefan Dösinger wrote: > Suggestion: Check if *device is indeed the IDirect3DRMDevice (QI > IID_IDirect3DRMDevice from it and compare pointers). We have cases in > plain ddraw where callbacks and getters return the interface passed in > instead of what the header says and applications depend on it. > IOW, if you register the callback with > IDirect3DRMDevice3::AddUpdateCallback you may or may not get an > IDirect3DRMDevice3 * here. Interesting. Yeah, I may add some testing for that in another MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62936

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 28 Feb '24

28 Feb '24

On Wed Feb 28 11:16:56 2024 +0000, Stefan Dösinger wrote: > I am wondering if this breaks the tests > (test_create_device_from_clipper1 checks the refcount), but the > IDirectDrawSurface::SetClipper holds a reference itself. So we're > probably fine with not holding a ref ourselves, especially if we don't > use the clipper object anywhere. FWIW, I ran the tests on a local box running XP bare-metal, and it seemed fine with this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62935

1 0

[PATCH v5 0/12] MR672: vkd3d-shader/ir: Introduce a better CFG structurizer, part 3.
by Giovanni Mascellani (＠giomasce) 28 Feb '24

28 Feb '24

This applies on top of !662, the last four commits belong here. Here we compute a topological order (plus some additional properties) of the shader blocks. Eventually the blocks will be emitted precisely in this order, after having been enriched with structured control flow information. -- v5: vkd3d-shader/ir: Keep loops contiguous in the topological sort. vkd3d-shader/ir: Dump the topological order of the control flow graph. vkd3d-shader/ir: Topologically sort the control flow graph. vkd3d-shader/ir: Allow adding to a block list without checking for duplicates. vkd3d-shader/ir: Sort each loop by block label. vkd3d-shader/ir: Dump the loops in the control flow graph. vkd3d-shader/ir: Keep track of loops by header block. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/672

2 12

[PATCH v3 0/4] MR5156: mshtml: Always use the event target dispex
by Brendan McGrath (＠redmcg) 28 Feb '24

28 Feb '24

This MR ensures that document mode isn't updated on the wrong document when a DOMContentLoaded event occurs. This is done by always using the event target dispex (instead of the dispex associated with doc associated with the event listener). This fixes the launcher for Swords of Legends Online. -- v3: mshtml: Don't handle special case when doc != node->doc. https://gitlab.winehq.org/wine/wine/-/merge_requests/5156

3 8

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger (＠stefan) 28 Feb '24

28 Feb '24

On Wed Feb 28 11:17:59 2024 +0000, Stefan Dösinger wrote: > There is room for future work, but nothing that needs to be in this > patchset IMHO: > 1) Check how multiple ForceUpdate / Clear calls influence the returned > list of rectangles > 2) Check which d3drmdevice interface is passed to the update callbacks Ah I missed your remarks on the cover letter regarding point 1. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62913

1 0

2025

2024

2023

2022

wine-gitlab February 2024