- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR9611: po: Update English resource
by Ken Sharp (＠imwellcushtymelike) Nov. 27, 2025

Nov. 27, 2025

- Updates to new strings - movable preferred over moveable in all variants -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9611

2 1

[PATCH v5 0/6] MR9604: rometadata: IMetaDataImport implementation, part 3
by Vibhav Pant (＠vibhavp) Nov. 27, 2025

Nov. 27, 2025

-- v5: https://gitlab.winehq.org/wine/wine/-/merge_requests/9604

3 8

[PATCH v2 0/4] MR9610: opengl32: Support persistent memory emulation on top of GL_AMD_pinned_memory.
by Jacek Caban (＠jacek) Nov. 27, 2025

Nov. 27, 2025

This provides a less performant alternative to the Vulkan-based persistent memory mapping used on wow64, so use it as a fallback on older drivers when available. -- v2: opengl32: Simplify wow64_unmap_buffer. opengl32: Support persistent memory emulation on top of GL_AMD_pinned_memory. https://gitlab.winehq.org/wine/wine/-/merge_requests/9610

3 6

[PATCH 0/4] MR9610: opengl32: Support persistent memory emulation on top of GL_AMD_pinned_memory.
by Jacek Caban (＠jacek) Nov. 27, 2025

Nov. 27, 2025

This provides a less performant alternative to the Vulkan-based persistent memory mapping used on wow64, so use it as a fallback on older drivers when available. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9610

3 7

[PATCH 0/1] MR9609: winex11: Only use XRender bilinear filter with client-side graphics.
by Rémi Bernon Nov. 27, 2025

Nov. 27, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58882 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9609

1 1

[PATCH v3 0/2] MR9584: Draft: win32u: Update client surfaces starting from toplevel window.
by Rémi Bernon Nov. 27, 2025

Nov. 27, 2025

In apply_window_pos, to notify any parent or children and let them make the necessary changes for offscreen rendering. -- v3: win32u: Update client surfaces starting from toplevel window. winex11: Update window position in client surface update callback. https://gitlab.winehq.org/wine/wine/-/merge_requests/9584

1 2

[PATCH 0/5] MR9607: dmusic: SF2 fixes, part 4
by Anton Baskanov (＠baskanov) Nov. 27, 2025

Nov. 27, 2025

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

3 9

[PATCH v4 0/7] MR9604: rometadata: IMetaDataImport implementation, part 3
by Vibhav Pant (＠vibhavp) Nov. 27, 2025

Nov. 27, 2025

-- v4: rometadata: Implement IMetaDataImport::{EnumMembers, EnumMembersWithName, FindMember}. rometadata: Implement IMetaDataImport::{EnumFieldsWithName, FindField}. rometadata: Implement IMetaDataImport::FindMethod. rometadata: Implement IMetaDataImport::EnumMethodsWithName. https://gitlab.winehq.org/wine/wine/-/merge_requests/9604

3 9

[PATCH v3 0/7] MR9604: rometadata: IMetaDataImport implementation, part 3
by Vibhav Pant (＠vibhavp) Nov. 27, 2025

Nov. 27, 2025

-- v3: rometadata: Implement IMetaDataImport::{EnumMembers, EnumMembersWithName, FindMember}. rometadata: Implement IMetaDataImport::{EnumFieldsWithName, FindField}. rometadata: Implement IMetaDataImport::FindMethod. rometadata: Implement IMetaDataImport::EnumMethodsWithName. rometadata/tests: Add tests for IMetaDataImport::{EnumMembersWithName, FindMember}. https://gitlab.winehq.org/wine/wine/-/merge_requests/9604

2 9

[PATCH v2 0/1] MR9395: arm64: Detect more new processor features.
by Martin Storsjö Nov. 27, 2025

Nov. 27, 2025

This one is somewhat tricky, as the existing `ProcessorFeatures` array is limited to `PROCESSOR_FEATURE_MAX` aka 64 entries, while this now defines features up to index 88. To handle the higher number of features, this patch extends `KUSER_SHARED_DATA` with a separate second array for the later features. This requires updating an assert about its size. If there's a better place to store the excess feature bits, I'm open for suggestions. As far as I can see, there's no obvious place that would be ABI visible where it should be stored. (I also see that upstream definitions of `KUSER_SHARED_DATA` has been extended with another new field that Wine doesn't have - so having our own data there probably isn't ideal.) So if there's some other convenient way of storing this (e.g. a global variable in ntdll) that also works, but it would need to be accessible from both the PE and unix sides, so it's probably not very straightforward either? -- v2: arm64: Detect more new processor features. https://gitlab.winehq.org/wine/wine/-/merge_requests/9395

1 3