- Wine-Devel - list.winehq.org

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 1, 2026

May 1, 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 27, 2026

April 27, 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

questions/patch proposal for x11 hwcursor rendering artifacts | winex11.drv/mouse.c
by winehq＠jaceee.com April 24, 2026

April 24, 2026

Hi, I don't want to disturb you much but I would really appreciate some pointers with regards to winex11. I came across a pretty frustrating bug on buffered xorg based window managers where drawing of custom cursors that exceed XQueryBestSize end up in draws with artifacts with nvidia proprietary (visually looks like a bounded overflow draw), with mesa/intel you get flickering in some situations on xfce but not as crazy, (likely rapid switching between hw cursor <-> sw cursor or what have you). Anyways, i'm no X expert but I really tried looking into the issue and see which level of stack should the issue fall on/be addressed at. Well.. It's not obvious to me. Xlib / X protocol technically doesn't impose any policy on cursor limits but it does expose things like XQueryBestSize. For example on xfce/xlibre/nvidia machine: ``` ❯ xdpyinfo | grep -i cursor largest cursor: 256x256 ``` And so there is one game on steam that creates a cursor of 384x384 in 1440p and that ends up blowing up and turning into a visual mess. Of course, that cursor is not 384x384, it just creates a buffer of 384x384 because the game for some reason does like 4x internal scaling or something (96dpi x 4 I assume). Basically it's not that easy to really nail where the discrepancy is. x11/xorg server does 'technically' have path that switches hw cursor to sw cursor but it doesn't seem to work or is unstable on window manager/graphics driver basis? Like I said earlier, I experienced this artifact on both xlibre/xfce and freedesktop xorg/gnome on nvidia and mesa. The reason I'm mentioning this is that it seems that it doesn't seem to be a problem of just one window manager and also I'm still uncertain whether patching this on xorg server is either valid approach or easy. So from a protocol perspective I don't know whether or not technically the rendering artifacts are a fault of X protocol or server entirely or not. I think in part but the issue is that from a protocol perspective there is no real strictness about this so... I do figure that userspace apps that interact with create cursor can basically take advantage of protocol facilities that result in stable drawing. The only problem being is that I found two ways to address this issue, in wine in particular. either: 1. pass smaller BITMAP dimensions to NtGdiCreateDIBSection (cursor initializer?) which win seems to auto downscale the cursor to those dimensions ? (looks correct in my use-case but the cursor is visibly smaller) 2. clamp/trim/crop the larger cursor buffer into smaller one that fits XQueryBestSize. (looks 1:1 to windows in my use-case) The problem is that visually for my use-case 2 gives correct visual behavior but I think trimming is likely wrong approach if it were default. As you can see from the diff I'm gating both methods atm but what I would love to know if: - it's acceptable to have something like this be handled by winex11.drv at all or do you think this is not wine's problem at all? I would say that it would be good if wine respected XQueryBestSize but I'm not certain yet on what the right shape of the hot path should be. - does this diff look sensible or is this wrong approach in general? In terms of naming I'm pretty sure it's wrong, I just don't know what the right names should be. scale cursor is technically also an implicit lie (it doesn't resample, it just rewrites dims right - it just happend to give that resulting effect when I was testing)... If you think it's better for me to create a merge/draft request lmk, I just figured to just ask around first before jumping into something more formal: ``` diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c index e1a5e70a6fe..899990af266 100644 --- a/dlls/winex11.drv/mouse.c +++ b/dlls/winex11.drv/mouse.c @@ -673,7 +673,8 @@ static void send_mouse_input( HWND hwnd, Window window, unsigned int state, INPU static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HANDLE icon, HBITMAP hbmColor, unsigned char *color_bits, int color_size, HBITMAP hbmMask, unsigned char *mask_bits, int mask_size, - int width, int height, int istep ) + int width, int height, int istep, + int x_width, int x_height) { XcursorImage *image, *ret = NULL; DWORD delay_jiffies, num_steps; @@ -681,15 +682,29 @@ static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HA BOOL has_alpha = FALSE; XcursorPixel *ptr; - image = pXcursorImageCreate( width, height ); + image = pXcursorImageCreate( x_width, x_height ); if (!image) { ERR("X11 failed to produce a cursor frame!\n"); return NULL; } - image->xhot = iinfo->xHotspot; - image->yhot = iinfo->yHotspot; + if (!x_width || !x_height || !width || !height) + { + return NULL; + } + + if(iinfo->xHotspot > x_width) { + image->xhot = (XcursorDim)x_width - 1; + } else { + image->xhot = iinfo->xHotspot; + } + + if(iinfo->yHotspot > y_width) { + image->yhot = (XcursorDim)y_width - 1; + } else { + image->yhot = iinfo->yHotspot; + } image->delay = 100; /* fallback delay, 100 ms */ if (NtUserGetCursorFrameInfo(icon, istep, &delay_jiffies, &num_steps) != 0) @@ -705,10 +720,18 @@ static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HA TRACE("Could not draw frame %d (walk past end of frames).\n", istep); goto cleanup; } - memcpy( image->pixels, color_bits, color_size ); + + if (x_width >= width && x_height >= height) { + memcpy( image->pixels, color_bits, color_size ); + } else { + for (y = 0; y < x_height; y++) + memcpy( image->pixels + y * x_width, + (XcursorPixel *)color_bits + y * width, + x_width * sizeof(XcursorPixel) ); + } /* check if the cursor frame was drawn with an alpha channel */ - for (i = 0, ptr = image->pixels; i < width * height; i++, ptr++) + for (i = 0, ptr = image->pixels; i < x_width * x_height; i++, ptr++) if ((has_alpha = (*ptr & 0xff000000) != 0)) break; /* if no alpha channel was drawn then generate it from the mask */ @@ -725,8 +748,8 @@ static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HA goto cleanup; } /* use the buffer to directly modify the XcursorImage alpha channel */ - for (y = 0, ptr = image->pixels; y < height; y++) - for (x = 0; x < width; x++, ptr++) + for (y = 0, ptr = image->pixels; y < x_height; y++) + for (x = 0; x < x_width; x++, ptr++) if (!((mask_bits[y * width_bytes + x / 8] << (x % 8)) & 0x80)) *ptr |= 0xff000000; } @@ -752,6 +775,27 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i XcursorImages *images; XcursorImage **imgs; Cursor cursor = 0; + unsigned int x_width = 0; + unsigned int x_height = 0; + int w_width = width; + int w_height = height; + + /* Clamp requested cursor frame dimensions to max best dimensions + * available by x to avoid hwcursor overflows (or forced sw cursor switch) + * with oversized cursors on draw */ + if (scale_cursor_to_best_size ^ clamp_cursor_to_best_size) { + XQueryBestCursor( gdi_display, DefaultRootWindow( gdi_display ), + w_width, w_height, &x_width, &x_height ); + + /* Aggressively reassign cursor dimensions to max available */ + if(scale_cursor_to_best_size) { + if (width > (int)x_width) w_width = (int)x_width; + if (height > (int)x_height) w_height = (int)x_height; + } + } else { + x_width = w_width; + x_height = w_height; + } /* Retrieve the number of frames to render */ if (!NtUserGetCursorFrameInfo(icon, 0, &delay_jiffies, &nFrames)) return 0; @@ -760,8 +804,8 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i /* Allocate all of the resources necessary to obtain a cursor frame */ if (!(info = malloc( FIELD_OFFSET( BITMAPINFO, bmiColors[256] )))) goto cleanup; info->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); - info->bmiHeader.biWidth = width; - info->bmiHeader.biHeight = -height; + info->bmiHeader.biWidth = w_width; + info->bmiHeader.biHeight = -w_height; info->bmiHeader.biPlanes = 1; info->bmiHeader.biCompression = BI_RGB; info->bmiHeader.biXPelsPerMeter = 0; @@ -769,7 +813,7 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i info->bmiHeader.biClrUsed = 0; info->bmiHeader.biClrImportant = 0; info->bmiHeader.biBitCount = 32; - color_size = width * height * 4; + color_size = w_width * w_height * 4; info->bmiHeader.biSizeImage = color_size; hbmColor = NtGdiCreateDIBSection( hdc, NULL, 0, info, DIB_RGB_COLORS, 0, 0, 0, (void **)&color_bits ); if (!hbmColor) @@ -787,7 +831,7 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i info->bmiColors[1].rgbBlue = 0xff; info->bmiColors[1].rgbReserved = 0; - mask_size = ((width + 31) / 32 * 4) * height; /* width_bytes * height */ + mask_size = ((width + 31) / 32 * 4) * w_height; /* width_bytes * height */ info->bmiHeader.biSizeImage = mask_size; hbmMask = NtGdiCreateDIBSection( hdc, NULL, 0, info, DIB_RGB_COLORS, 0, 0, 0, (void **)&mask_bits ); if (!hbmMask) @@ -802,7 +846,7 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i imgs[i] = create_xcursor_frame( hdc, iinfo, icon, hbmColor, color_bits, color_size, hbmMask, mask_bits, mask_size, - width, height, i ); + w_width, w_height, i, (int)x_width, (int)x_height ); if (!imgs[i]) goto cleanup; } diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h index 9436f35e1ca..cdcdf95f5c0 100644 --- a/dlls/winex11.drv/x11drv.h +++ b/dlls/winex11.drv/x11drv.h @@ -478,6 +478,8 @@ extern BOOL usexcomposite; extern BOOL use_xfixes; extern BOOL managed_mode; extern BOOL private_color_map; +extern BOOL clamp_cursor_to_best_size; +extern BOOL scale_cursor_to_best_size; extern int primary_monitor; extern int copy_default_colors; extern int alloc_system_colors; diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c index 81008f45c33..0b1c87fef91 100644 --- a/dlls/winex11.drv/x11drv_main.c +++ b/dlls/winex11.drv/x11drv_main.c @@ -81,6 +81,8 @@ int primary_monitor = 0; BOOL client_side_graphics = TRUE; BOOL client_side_with_render = TRUE; BOOL shape_layered_windows = TRUE; +BOOL clamp_cursor_to_best_size = FALSE; +BOOL scale_cursor_to_best_size = FALSE; int copy_default_colors = 128; int alloc_system_colors = 256; int xrender_error_base = 0; @@ -514,6 +516,12 @@ static void setup_options(void) if (!get_config_key( hkey, appkey, "AllocSystemColors", buffer, sizeof(buffer) )) alloc_system_colors = wcstol( buffer, NULL, 0 ); + if (!get_config_key( hkey, appkey, "ClampCursorToBestSize", buffer, sizeof(buffer) )) + clamp_cursor_to_best_size = IS_OPTION_TRUE( buffer[0] ); + + if (!get_config_key( hkey, appkey, "ScaleCursorToBestSize", buffer, sizeof(buffer) )) + scale_cursor_to_best_size = IS_OPTION_TRUE( buffer[0] ); + get_config_key( hkey, appkey, "InputStyle", input_style, sizeof(input_style) ); NtClose( appkey ); ```

2 3

Wine staging 11.7 release
by Alistair Leslie-Hughes April 18, 2026

April 18, 2026

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.7 (280 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * msxml3: Add GB2312 support for builtin character converter. * odbc32: SQLDriverConnect/W reuse environment handle is possible Removed (No longer required). * None Added: * None Updated: * vkd3d-latest 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