May 2026 - Wine-Devel - list.winehq.org

Re: Feedback needed for a theme PR

by Patrick Hibbs

Having read the linked <a href="https://bugs.winehq.org/show_bug.cgi?id=59739">bug #59739</a>, the initial issue seems to be that wine isn't looking for themes outside of it's own prefix, and thus increasing the amount of space each prefix uses due to needing to copy the *same* custom theme data into each newly made prefix. This part is something I'd support fixing, as the prefixes are already too large to begin with. However, the issue seems to slowly suffer from scope creep and become a complaint that custom theming is not automatic across all prefixes. This is something that really should be left alone for a number of reasons. The most obvious being that there is an entire class of UI bugs that break apps as a direct result of the Windows theme being used and various wine-inaccuracies when handing Windows themes. Another reason against automatic custom theming for all prefixes, is that this is something that most 3rd party wrappers / launchers should be able to handle on their own. My own manager could do this with one additional line of code. (A few more if I want to be nice and allow proper checks.) For users that don't configure Wine themselves, (Steam / Proton users, PlayOnLinux, etc.), they aren't configuring this stuff directly anyway. Sure, the 3rd party wrappers may like a simple command line arg / environment variable to change it during prefix creation, and Wine could look into providing a standard way to indicate a choice, (which could be useful for other things like disabling winemenubuilder, enabling the start menu in Virtual Desktop mode, etc.), but we'd still need to have some sort of "safe-mode" that disables it for debugging / bug-reporting / testing / app workaround / etc. purposes. As for vanilla wine users, they'd be better served by having wine's control panel made more visible, better organized, and more feature complete. Maybe have a button that lets them import various "personalized" settings from another prefix? Currently the only easy way to duplicate a prefix config out side of a manager app, is to manually copy an existing prefix warts and all, then strip out what isn't desired. It would be better if Wine had some global settings that could be handled by KDE's System Settings / GNOME's Control Center apps, along with a clear "safe-mode" button that would disable it and that the wiki could refer users to when submitting bug reports / troubleshooting Wine. On 5/15/26 8:08 PM, Fatih Bakal via Wine-Devel wrote: > I currently need feedback as to how to implement a theming improvement to wine. My recommendation is that all prefixes use $HOME/.config/wine.msstyle/.theme if possible. I was told this is the place to ask for feedback. > > Please see https://gitlab.winehq.org/wine/wine/-/merge_requests/10920

May 16, 2026

Wine staging 11.9 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.9 (273 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * vkd3d: Fix compile errors under mingw. * d3d9: Add a fake d3d9 device vtbl initialization sequence. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * dcomp-DCompositionCreateDevice2 Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

May 16, 2026

Feedback needed for a theme PR

by fatihbakal7＠protonmail.com

I currently need feedback as to how to implement a theming improvement to wine. My recommendation is that all prefixes use $HOME/.config/wine.msstyle/.theme if possible. I was told this is the place to ask for feedback. Please see https://gitlab.winehq.org/wine/wine/-/merge_requests/10920

May 16, 2026

Re: Potential Clean Room issues with xinputaup

by Yusuf

Sorry, I sent an email without replying all. The xinputuap.dll is merged into the project currently, that was contributed from me. Thereby it was potentially made from source that was against the Clean Room guidelines of the project. Thanks

May 4, 2026

Re: [PATCH] d2d1: Fix arc center translation to use center.y in _31 update.

by Nikolay Sivov

Hi, Patches should be submitted through gitlab.winehq.org, see https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patches.

May 4, 2026

Re: Potential Clean Room issues with xinputaup

by Stefan Dösinger

Hi, > Am 01.05.2026 um 04:33 schrieb Yusuf via Wine-Devel <wine-devel(a)list.winehq.org>: > > Is there any update to this? Will I be banned from the project? > > Thanks I had to find the Email you are referring to, somehow it didn't make it into my inbox - probably Google's overzealous spam filter picked it out. For others who have the same issue: https://list.winehq.org/hyperkitty/list/wine-devel@list.winehq.org/message/… We'll probably err on the side of caution and not accept xinputuap related code from you, but I don't think looking at debug symbols should stop you from e.g. filing bugs or helping other users on the forums. Cheers, Stefan

May 4, 2026

[PATCH] d2d1: Strip translation from transform when scaling arc radii.

by Giang Nguyen

d2d_arc_transform() applies the same affine matrix to the arc's end point and to its two radius vectors (width, 0) and (0, height). That is correct for the end point (a position) but wrong for the radii (direction vectors): when the matrix includes a non-zero translation (_31, _32), the transformed radius vector becomes (width * _11 + _31, width * _12 + _32) and the resulting d2d_point_length() returns sqrt((width*_11 + _31)^2 + (width*_12 + _32)^2) instead of the intended sqrt((width*_11)^2 + (width*_12)^2) = width * sqrt(_11^2 + _12^2) i.e. the magnitude of the linear part only. Visible whenever a path that contains an arc is wrapped in a transformed geometry whose transform has both a non-trivial linear part and a translation — common for plugin host UIs with offset rendering. Fix: build a local copy of the matrix with _31 = _32 = 0 and use it for the radius transforms. Keep the original transform for the end point. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59718 Signed-off-by: Giang Nguyen <nen24t(a)gmail.com> --- dlls/d2d1/geometry.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/dlls/d2d1/geometry.c b/dlls/d2d1/geometry.c index 68de4c2193c..eda79d35e2b 100644 --- a/dlls/d2d1/geometry.c +++ b/dlls/d2d1/geometry.c @@ -4479,12 +4479,19 @@ static HRESULT STDMETHODCALLTYPE d2d_path_geometry_Open(ID2D1PathGeometry1 *ifac static inline void d2d_arc_transform(D2D1_ARC_SEGMENT *arc, const D2D1_MATRIX_3X2_F *transform) { + D2D1_MATRIX_3X2_F linear = *transform; D2D_POINT_2F point; + /* Radii are direction vectors, so they should be transformed with the + * linear part of the matrix only. Including the translation would add + * (_31, _32) to (width, 0) and (0, height) and yield incorrect lengths. */ + linear._31 = 0.0f; + linear._32 = 0.0f; + d2d_point_transform(&arc->point, transform, arc->point.x, arc->point.y); - d2d_point_transform(&point, transform, arc->size.width, 0.0f); + d2d_point_transform(&point, &linear, arc->size.width, 0.0f); arc->size.width = d2d_point_length(&point); - d2d_point_transform(&point, transform, 0.0f, arc->size.height); + d2d_point_transform(&point, &linear, 0.0f, arc->size.height); arc->size.height = d2d_point_length(&point); } -- 2.43.0

May 4, 2026

[PATCH] d2d1: Fix uninitialized points[0] in degenerate-radius arc fallback.

by Giang Nguyen

When d2d_arc_to_bezier() rejects an arc because both radii are below the fuzz threshold, it returns 0 to signal "treat as a straight line". The caller d2d_figure_add_arc() then passes points[0] to d2d_figure_add_lines() as the line endpoint: count = d2d_arc_to_bezier(&figure->vertices[last], arc, points); if (count > 0) return d2d_figure_add_beziers(figure, ...); else if (count == 0) return d2d_figure_add_lines(figure, points, 1); But points[0] is never written on the radius-rejection path, so add_lines() consumes uninitialized stack memory as the endpoint. Result: random line target, undefined visual behavior for any path that contains a degenerate-radius arc. Fix is to write the arc's specified end point into points[0] before returning 0, which matches the natural fallback semantics ("draw a line from the previous vertex to the arc's endpoint"). Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59718 Signed-off-by: Giang Nguyen <nen24t(a)gmail.com> --- dlls/d2d1/geometry.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dlls/d2d1/geometry.c b/dlls/d2d1/geometry.c index 68de4c2193c..51d587673dd 100644 --- a/dlls/d2d1/geometry.c +++ b/dlls/d2d1/geometry.c @@ -1247,6 +1247,7 @@ static int d2d_arc_to_bezier(const D2D_POINT_2F *start_point, const D2D1_ARC_SEG if (!d2d_arc_check_radius(rHalfChord2, fuzz2, &radius.x) || !d2d_arc_check_radius(rHalfChord2, fuzz2, &radius.y)) { + points[0] = arc->point; return 0; } -- 2.43.0

May 4, 2026

[PATCH] d2d1: Fix arc center translation to use center.y in _31 update.

by Giang Nguyen

In d2d_arc_to_bezier(), when computing the affine transform that maps the canonical unit-arc parameter space to the actual arc, the translation contribution from the arc center is meant to be the linear matrix-vector product M * center, i.e.: (_31, _32) += (M11*cx + M12*cy, M21*cx + M22*cy) The first line of the update used center.x in both terms, which yields M11*cx + M12*cx instead of M11*cx + M12*cy. Effect is invisible when M12 == 0 (i.e. arc->rotationAngle == 0), which is the common case for unrotated arcs in UI rendering. Becomes visible for arcs with a non-zero rotationAngle, where the arc center ends up displaced along the rotation axis. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59718 Signed-off-by: Giang Nguyen <nen24t(a)gmail.com> --- dlls/d2d1/geometry.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/d2d1/geometry.c b/dlls/d2d1/geometry.c index 68de4c2193c..b7dc2b7b55e 100644 --- a/dlls/d2d1/geometry.c +++ b/dlls/d2d1/geometry.c @@ -1311,7 +1311,7 @@ static int d2d_arc_to_bezier(const D2D_POINT_2F *start_point, const D2D1_ARC_SEG m._32 = 0.5f * (arc->point.y + start_point->y); if (!zero_center) { - m._31 += (m._11 * center.x + m._12 * center.x); + m._31 += (m._11 * center.x + m._12 * center.y); m._32 += (m._21 * center.x + m._22 * center.y); } -- 2.43.0

May 4, 2026

Wine staging 11.8 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.8 (281 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [59708] - d3d9: missing MSVC vtable byte-pattern Updated: * vkd3d-latest * dcomp-DCompositionCreateDevice2 Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

May 2, 2026