- Wine-Devel - list.winehq.org

Explanation of CTL_CODES
by Barath Rk May 23, 2026

May 23, 2026

I am trying to implement the ReadConsoleInputEx(A|W) functions in kernelbase(It is needed for Microsoft's edit.exe. See bug #58252). I figured I could do that by defining a new CTL_CODE in include/wine/condrv.h. However, after a long time spent in exploring the source code, I don't get where the handler for the codes, such IOCTL_CONDRV_READ_INPUT are defined. Would appreciate some direction on this. Thanks in advance.

3 2

Wine staging 11.9 release
by Alistair Leslie-Hughes May 16, 2026

May 16, 2026

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.

1 0

Fwd: Potential Clean Room issues with xinputaup
by Yusuf May 4, 2026

May 4, 2026

Hi All! For the xinputuap bits I remember that I may(?) have examined the Debug Symbols for it, reading the Clean Room guidelines it seems to be against the conditions here. I don't plan to contribute to the wine projects(nowadays I have moral objections to it) yet if you wish ban me from your project. Yusuf

2 3

[PATCH] d2d1: Fix arc center translation to use center.y in _31 update.
by Giang Nguyen May 4, 2026

May 4, 2026

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

2 1

[PATCH] d2d1: Strip translation from transform when scaling arc radii.
by Giang Nguyen May 4, 2026

May 4, 2026

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

1 0

[PATCH] d2d1: Fix uninitialized points[0] in degenerate-radius arc fallback.
by Giang Nguyen May 4, 2026

May 4, 2026

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

1 0

Wine staging 11.8 release
by Alistair Leslie-Hughes May 2, 2026

May 2, 2026

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.

1 0

[Question] Use of old FDI.h with Microsoft copyright notice as reference
by David CF April 30, 2026

April 30, 2026

Dear all, Sorry to bother, but I could not find a clear answer and would like to check before doing any Wine work based on material with an unclear legal status. I was looking into Wine's implementation of FDI and cabinet.dll. While looking at code examples using FDICreate and FDICopy, I stumbled upon an old GPL project called CapiTel. The FDI.h contained in this project has many useful explanations for constants and functions that are poorly documented in the Microsoft Learn Win32 API reference, as well as in Wine's API reference. However, the file says: Copyright (C) Microsoft Corporation 1993-1997. All Rights Reserved. I was wondering whether it is OK to use information learned from this header to document the Wine API. I was also wondering whether it would be acceptable to patch some of the functions based on what I learned from this header. Thanks in advance for your help and guidance, David Carrasco Flores

3 3

[PATCH] user32: Add InitializeTouchInjection stub.
by Joe Meyer April 28, 2026

April 28, 2026

--- dlls/user32/input.c | 9 +++++++++ dlls/user32/user32.spec | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/dlls/user32/input.c b/dlls/user32/input.c index 48b38166b75..74c52df9e1b 100644 --- a/dlls/user32/input.c +++ b/dlls/user32/input.c @@ -688,6 +688,15 @@ BOOL WINAPI UnregisterTouchWindow( HWND hwnd ) return TRUE; } +/***************************************************************************** + * InitializeTouchInjection (USER32.@) + */ +BOOL WINAPI InitializeTouchInjection( UINT32 max_count, DWORD dw_mode ) +{ + FIXME( "max_count %u, dw_mode %#lx stub!\n", max_count, dw_mode ); + return TRUE; +} + /***************************************************************************** * GetGestureInfo (USER32.@) */ diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec index b8939646668..12cc31b3e34 100644 --- a/dlls/user32/user32.spec +++ b/dlls/user32/user32.spec @@ -749,7 +749,7 @@ # @ stub InitializeLpkHooks # @ stub InitializePointerDeviceInjection # @ stub InitializePointerDeviceInjectionEx -# @ stub InitializeTouchInjection +@ stdcall InitializeTouchInjection(long long) # @ stub InjectDeviceInput # @ stub InjectGenericHidInput # @ stub InjectKeyboardInput -- 2.54.0

1 0

USB Printing (for vinyl cutter) support & AI Assisted Code Contributions Policy
by Kyle Cascade April 27, 2026

April 27, 2026

I have a branch of wine that adds support for talking to my USB vinyl cutter, allowing me to run its Silhouette Studio software AND send it to the USB device. Winedb: https://appdb.winehq.org/objectManager.php?sClass=application&iId=16375 Branch: https://gitlab.winehq.org/kyle1/wine/-/compare/master...mr2-usb-driver-stac… Incredibly, it works! It took a lot of code to actually make it happen, but so incredible that I can actually use this device without Windows now. I'm super happy. But, before I try to work towards submitting it, I should disclose that I used Claude Code extensively to build it. I couldn't find any docs on the wiki or FAQ about AI-generated patches. Given the clean room policy, is there an official stance on this? I haven't read any Windows source code, but I can't prove that the model wasn't trained on it. Kyle

2 1