April 2026 - 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

[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

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

Upcoming vkd3d 2.0 release
by Henri Verbeet April 16, 2026

April 16, 2026

Hi all, The planned release date for vkd3d 2.0 is Thursday May 21. That means the public API will become frozen next week on April 23, and features will be frozen two weeks before the release, on May 7. This does not mean that development should slow down or stop, of course; after making sure that we're in good shape to release, this would be the ideal time to make sure that any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 2.1 is Monday August 24. A tentative release schedule for future releases can be found on the vkd3d wiki[1]. Regards, Henri [1] https://gitlab.winehq.org/wine/vkd3d/-/wikis/release-schedule

2 1

[PATCH v2 0/2] Fixes for CodeQL analysis of MSVC's CL.EXE
by Jason A. Donenfeld April 13, 2026

April 13, 2026

CodeQL has a mode where it'll run a compiler and trace its execution, in order to have some internal representation, which it then ingests into its database, for later analysis. I managed to get MSVC's CL.EXE running in Wine, from the latest EWDK, but when I tried to trace its execution using CodeQL, I ran into trouble. These two fixes resolve that issue. The first patch is trivial. The second patch is more involved, and so I've added some test cases. This should match ntdll/ntsokrnl behavior pretty closely. I can't send these to Gitlab because I don't have the ability to fork repos there yet. I'll open a ticket for that. Jason A. Donenfeld (2): cmd: link against kernel32 for CreateProcessW ntdll, server: allow oversized views with MEM_RESERVE dlls/ntdll/tests/virtual.c | 80 ++++++++++++++++++++++++++++++++++ dlls/ntdll/unix/sync.c | 1 + dlls/ntdll/unix/virtual.c | 38 +++++++++++----- include/wine/server_protocol.h | 8 ++-- programs/cmd/Makefile.in | 2 +- server/mapping.c | 16 ++++--- server/protocol.def | 2 + server/request_handlers.h | 16 ++++--- server/request_trace.h | 2 + 9 files changed, 136 insertions(+), 29 deletions(-) -- 2.53.0

4 9

[PATCH 0/2] Fixes for CodeQL analysis of MSVC's CL.EXE
by Jason A. Donenfeld April 13, 2026

April 13, 2026

CodeQL has a mode where it'll run a compiler and trace its execution, in order to have some internal representation, which it then ingests into its database, for later analysis. I managed to get MSVC's CL.EXE running in Wine, from the latest EWDK, but when I tried to trace its execution using CodeQL, I ran into trouble. These two fixes resolve that issue. I can't send these to Gitlab because I don't have the ability to fork repos there yet. I'll open a ticket for that. Jason A. Donenfeld (2): ntdll, server: allow file-backed SEC_RESERVE sections cmd: link against kernel32 for CreateProcessW dlls/ntdll/unix/virtual.c | 13 ++++++++++--- programs/cmd/Makefile.in | 2 +- server/mapping.c | 6 ++++-- 3 files changed, 15 insertions(+), 6 deletions(-) -- 2.53.0

2 4

[PATCH] gdi32: Implement GdiEntry13 as Direct3DCreate9 wrapper.
by Wehrwolfmann April 11, 2026

April 11, 2026

On Windows, GdiEntry13 is used by WPF (wpfgfx_v0400.dll) to obtain an IDirect3D9 object via GetProcAddress(gdi32, "GdiEntry13"). WPF expects the return value to be an IDirect3D9 pointer, equivalent to calling Direct3DCreate9(D3D_SDK_VERSION). The previous implementation mapped GdiEntry13 to a stub of DdQueryDisplaySettingsUniqueness that always returned 0, causing WPF to fail to initialize its rendering pipeline and resulting in black or missing windows for all WPF applications running under Wine. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59634 --- dlls/gdi32/dc.c | 36 ++++++++++++++++++++++++++++++++---- include/ddrawgdi.h | 2 +- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/dlls/gdi32/dc.c b/dlls/gdi32/dc.c index adfcd51..4b453dd 100644 --- a/dlls/gdi32/dc.c +++ b/dlls/gdi32/dc.c @@ -2709,15 +2709,43 @@ INT WINAPI NamedEscape( HDC hdc, const WCHAR *driver, INT escape, INT input_size return 0; } +typedef void * (WINAPI *Direct3DCreate9_func)(UINT); +static Direct3DCreate9_func pDirect3DCreate9; + +static BOOL WINAPI init_d3d9( INIT_ONCE *once, void *param, void **context ) +{ + HMODULE d3d9_module = LoadLibraryW( L"d3d9.dll" ); + if (d3d9_module) + pDirect3DCreate9 = (Direct3DCreate9_func)GetProcAddress( d3d9_module, "Direct3DCreate9" ); + if (!pDirect3DCreate9) + WARN( "Failed to load d3d9.dll or find Direct3DCreate9\n" ); + return TRUE; +} + /******************************************************************* * DdQueryDisplaySettingsUniqueness (GDI32.@) * GdiEntry13 + * + * On Windows, GdiEntry13 is used by WPF (wpfgfx_v0400.dll) to obtain + * an IDirect3D9 object. WPF calls GetProcAddress(gdi32, "GdiEntry13") + * and expects the return value to be an IDirect3D9 pointer, equivalent + * to calling Direct3DCreate9(D3D_SDK_VERSION). + * + * The original DdQueryDisplaySettingsUniqueness stub returned 0 (NULL), + * causing WPF to fail to initialize its rendering pipeline. */ -ULONG WINAPI DdQueryDisplaySettingsUniqueness(void) +void * WINAPI DdQueryDisplaySettingsUniqueness(void) { - static int warn_once; - if (!warn_once++) FIXME( "stub\n" ); - return 0; + static INIT_ONCE init_once = INIT_ONCE_STATIC_INIT; + + TRACE( "\n" ); + + InitOnceExecuteOnce( &init_once, init_d3d9, NULL, NULL ); + + if (pDirect3DCreate9) + return pDirect3DCreate9( 32 /* D3D_SDK_VERSION */ ); + + return NULL; } /******************************************************************* diff --git a/include/ddrawgdi.h b/include/ddrawgdi.h index 4b78702..c0893b9 100644 --- a/include/ddrawgdi.h +++ b/include/ddrawgdi.h @@ -27,7 +27,7 @@ extern "C" { #define DdQueryDisplaySettingsUniqueness GdiEntry13 -ULONG APIENTRY DdQueryDisplaySettingsUniqueness(void); +void * APIENTRY DdQueryDisplaySettingsUniqueness(void); #ifdef __cplusplus } -- 2.53.0

2 1

[PATCH] winewayland: Use xdg_popup for Win32 popup menus.
by Wehrwolfmann April 10, 2026

April 10, 2026

On Wayland, popup menus (WS_POPUP windows with class #32768) don't close when clicking outside because the compositor only delivers pointer events to the focused surface. X11 solves this with XGrabPointer, but Wayland requires xdg_popup with an explicit grab. Add WAYLAND_SURFACE_ROLE_POPUP that creates an xdg_popup surface with xdg_popup_grab for windows matching the POPUPMENU_CLASS_ATOM (#32768). The compositor sends popup_done when the user clicks outside, which we translate to WM_CANCELMODE to dismiss the menu. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply(a)anthropic.com> --- dlls/winewayland.drv/wayland_surface.c | 114 +++++++++++++++++++++++++ dlls/winewayland.drv/waylanddrv.h | 9 ++ dlls/winewayland.drv/window.c | 35 +++++++- 3 files changed, 157 insertions(+), 1 deletion(-) diff --git a/dlls/winewayland.drv/wayland_surface.c b/dlls/winewayland.drv/wayland_surface.c index 2f8275d..752760d 100644 --- a/dlls/winewayland.drv/wayland_surface.c +++ b/dlls/winewayland.drv/wayland_surface.c @@ -327,6 +327,103 @@ err: ERR("Failed to assign subsurface role to wayland surface\n"); } +/********************************************************************** + * xdg_popup listeners + */ +static void xdg_popup_handle_configure(void *data, struct xdg_popup *xdg_popup, + int32_t x, int32_t y, + int32_t width, int32_t height) +{ + TRACE("hwnd=%p pos=%d,%d size=%dx%d\n", data, x, y, width, height); +} + +static void xdg_popup_handle_done(void *data, struct xdg_popup *xdg_popup) +{ + HWND hwnd = data; + TRACE("hwnd=%p popup_done\n", hwnd); + NtUserPostMessage(hwnd, WM_CANCELMODE, 0, 0); +} + +static void xdg_popup_handle_repositioned(void *data, + struct xdg_popup *xdg_popup, + uint32_t token) +{ +} + +static const struct xdg_popup_listener xdg_popup_listener = +{ + xdg_popup_handle_configure, + xdg_popup_handle_done, + xdg_popup_handle_repositioned, +}; + +/********************************************************************** + * wayland_surface_make_popup + * + * Gives the popup role to a plain wayland surface. The popup is + * positioned relative to the parent surface and can use an explicit + * grab so that the compositor dismisses it on outside clicks. + */ +void wayland_surface_make_popup(struct wayland_surface *surface, + struct wayland_surface *parent, + int x, int y, int width, int height) +{ + struct xdg_positioner *positioner; + + TRACE("surface=%p parent=%p pos=%d,%d size=%dx%d\n", + surface, parent, x, y, width, height); + + assert(!surface->role || surface->role == WAYLAND_SURFACE_ROLE_POPUP); + if (surface->xdg_popup) return; + + wayland_surface_clear_role(surface); + surface->role = WAYLAND_SURFACE_ROLE_POPUP; + + /* Create xdg_surface for the popup */ + surface->popup_xdg_surface = + xdg_wm_base_get_xdg_surface(process_wayland.xdg_wm_base, + surface->wl_surface); + if (!surface->popup_xdg_surface) goto err; + xdg_surface_add_listener(surface->popup_xdg_surface, + &xdg_surface_listener, surface->hwnd); + + /* Create positioner to place popup relative to parent */ + positioner = xdg_wm_base_create_positioner(process_wayland.xdg_wm_base); + if (!positioner) goto err; + + xdg_positioner_set_size(positioner, width > 0 ? width : 1, + height > 0 ? height : 1); + xdg_positioner_set_anchor_rect(positioner, x, y, 1, 1); + xdg_positioner_set_anchor(positioner, XDG_POSITIONER_ANCHOR_TOP_LEFT); + xdg_positioner_set_gravity(positioner, XDG_POSITIONER_GRAVITY_BOTTOM_RIGHT); + + /* Create popup */ + surface->xdg_popup = + xdg_surface_get_popup(surface->popup_xdg_surface, + parent->xdg_surface, positioner); + xdg_positioner_destroy(positioner); + if (!surface->xdg_popup) goto err; + + xdg_popup_add_listener(surface->xdg_popup, &xdg_popup_listener, + surface->hwnd); + + /* Grab the popup so compositor sends popup_done on outside click. */ + { + uint32_t serial = InterlockedCompareExchange(&process_wayland.input_serial, 0, 0); + if (serial) + xdg_popup_grab(surface->xdg_popup, process_wayland.seat.wl_seat, serial); + } + + wl_surface_commit(surface->wl_surface); + wl_display_flush(process_wayland.wl_display); + + return; + +err: + wayland_surface_clear_role(surface); + ERR("Failed to assign popup role to wayland surface\n"); +} + /********************************************************************** * wayland_surface_clear_role * @@ -375,6 +472,20 @@ void wayland_surface_clear_role(struct wayland_surface *surface) surface->toplevel_hwnd = 0; break; + + case WAYLAND_SURFACE_ROLE_POPUP: + if (surface->xdg_popup) + { + xdg_popup_destroy(surface->xdg_popup); + surface->xdg_popup = NULL; + } + + if (surface->popup_xdg_surface) + { + xdg_surface_destroy(surface->popup_xdg_surface); + surface->popup_xdg_surface = NULL; + } + break; } memset(&surface->pending, 0, sizeof(surface->pending)); @@ -733,6 +844,9 @@ BOOL wayland_surface_reconfigure(struct wayland_surface *surface) if (!surface->wl_subsurface) break; /* surface role has been cleared */ wayland_surface_reconfigure_subsurface(surface); break; + case WAYLAND_SURFACE_ROLE_POPUP: + if (!surface->xdg_popup) break; /* surface role has been cleared */ + break; } wayland_surface_reconfigure_size(surface, width, height); diff --git a/dlls/winewayland.drv/waylanddrv.h b/dlls/winewayland.drv/waylanddrv.h index 3b0c300..911b43c 100644 --- a/dlls/winewayland.drv/waylanddrv.h +++ b/dlls/winewayland.drv/waylanddrv.h @@ -82,6 +82,7 @@ enum wayland_surface_role WAYLAND_SURFACE_ROLE_NONE, WAYLAND_SURFACE_ROLE_TOPLEVEL, WAYLAND_SURFACE_ROLE_SUBSURFACE, + WAYLAND_SURFACE_ROLE_POPUP, }; struct wayland_keyboard @@ -282,6 +283,11 @@ struct wayland_surface struct wl_subsurface *wl_subsurface; HWND toplevel_hwnd; }; + struct + { + struct xdg_surface *popup_xdg_surface; + struct xdg_popup *xdg_popup; + }; }; struct wayland_surface_config pending, requested, processing, current; @@ -314,6 +320,9 @@ void wayland_surface_destroy(struct wayland_surface *surface); void wayland_surface_make_toplevel(struct wayland_surface *surface); void wayland_surface_make_subsurface(struct wayland_surface *surface, struct wayland_surface *parent); +void wayland_surface_make_popup(struct wayland_surface *surface, + struct wayland_surface *parent, + int x, int y, int width, int height); void wayland_surface_clear_role(struct wayland_surface *surface); void wayland_surface_attach_shm(struct wayland_surface *surface, struct wayland_shm_buffer *shm_buffer, diff --git a/dlls/winewayland.drv/window.c b/dlls/winewayland.drv/window.c index 2c3d1f8..c1ab090 100644 --- a/dlls/winewayland.drv/window.c +++ b/dlls/winewayland.drv/window.c @@ -192,16 +192,20 @@ static BOOL wayland_win_data_create_wayland_surface(struct wayland_win_data *dat struct wayland_surface *surface; enum wayland_surface_role role; BOOL visible; + DWORD style = NtUserGetWindowLongW(data->hwnd, GWL_STYLE); DWORD exstyle = NtUserGetWindowLongW(data->hwnd, GWL_EXSTYLE); struct wl_region *input_region; TRACE("hwnd=%p\n", data->hwnd); - visible = ((NtUserGetWindowLongW(data->hwnd, GWL_STYLE) & WS_VISIBLE) == WS_VISIBLE) && + visible = ((style & WS_VISIBLE) == WS_VISIBLE) && (!(exstyle & WS_EX_LAYERED) || data->layered_attribs_set); if (!visible) role = WAYLAND_SURFACE_ROLE_NONE; else if (toplevel_surface) role = WAYLAND_SURFACE_ROLE_SUBSURFACE; + else if ((style & WS_POPUP) && NtUserGetWindowRelative(data->hwnd, GW_OWNER) && + NtUserGetClassWord(data->hwnd, GCW_ATOM) == 32768) + role = WAYLAND_SURFACE_ROLE_POPUP; else role = WAYLAND_SURFACE_ROLE_TOPLEVEL; /* we can temporarily clear the role of a surface but cannot assign a different one after it's set */ @@ -236,6 +240,30 @@ static BOOL wayland_win_data_create_wayland_surface(struct wayland_win_data *dat case WAYLAND_SURFACE_ROLE_SUBSURFACE: wayland_surface_make_subsurface(surface, toplevel_surface); break; + case WAYLAND_SURFACE_ROLE_POPUP: + { + HWND owner = NtUserGetWindowRelative(data->hwnd, GW_OWNER); + struct wayland_win_data *owner_data = owner ? wayland_win_data_get(owner) : NULL; + if (owner_data && owner_data->wayland_surface) + { + RECT rect, owner_rect; + NtUserGetWindowRect(data->hwnd, &rect, 0); + NtUserGetWindowRect(owner, &owner_rect, 0); + wayland_surface_make_popup(surface, owner_data->wayland_surface, + rect.left - owner_rect.left, + rect.top - owner_rect.top, + rect.right - rect.left, + rect.bottom - rect.top); + wayland_win_data_release(owner_data); + } + else + { + if (owner_data) wayland_win_data_release(owner_data); + /* Fallback to toplevel if owner has no surface */ + wayland_surface_make_toplevel(surface); + } + break; + } } if (visible && client) wayland_client_surface_attach(client, data->hwnd); @@ -313,6 +341,11 @@ static void wayland_win_data_update_wayland_state(struct wayland_win_data *data) surface->processing.serial = 1; surface->processing.processed = TRUE; break; + case WAYLAND_SURFACE_ROLE_POPUP: + TRACE("hwnd=%p popup\n", surface->hwnd); + surface->processing.serial = 1; + surface->processing.processed = TRUE; + break; } wl_display_flush(process_wayland.wl_display); -- 2.53.0

1 0

Possible NtLockFile / NtUnlockFile FIXME Patches for Wine
by tim＠livingstaccato.com April 9, 2026

April 9, 2026

Hi there! My name is Tim Perkins. I'm a 25+ year user, but a first-time contributor (maybe). I've been playing around with the TradeWars Game Server on macOS (https://eisonline.classictw.com/) and it kept crashing or acting weird after a day or so of operation—faster if I was actually stressing the server. I seem to have hit a flocking problem. Once I hit that problem, it just starts eating up more and more file descriptors until bad things happen. I do dev during the day, but I do not know C well. However, I used Claude Code to come up with some patches that I think aren't too sloppy, nor do they open the gates of hell or create security vulnerabilities. I put all the patches and proof in a repo on GitHub at https://github.com/livingstaccato/space-wine/tree/main and made a GitHub action which compiles Wine on multiple platforms and runs some conformance tests. After using a version of Wine with those patches implemented, I've had the TradeWars server running stable for over a week now. I was hoping one of you more experienced subject matter experts could take a look and let me know if they're viable patches? :) Up front, though: if you ask me "Why did you do X?" my response will probably be, "… let me ask Claude." Thanks, and I hope this helps! --Tim

5 5

Tbs.h impletention planning
by 中川祥 April 9, 2026

April 9, 2026

How is Wine going to implement tbs.h and TPM 2.0 libraries?( such as ncrypt) Retrieving true linux information or faked Windows info?

1 0

On bug#27641: an editor should use the indic font when indic typing is being done
by समीर सिंह Sameer Singh April 7, 2026

April 7, 2026

Hi, I can still reproduce this issue on the latest master at the time of writing this. For example open: wine notepad and type something like: देवनागरी Instead of the program falling back to an appropriate font, "tofu" blocks are shown instead. Now, in ./dlls/gdi32/uniscribe/usp10.c I can see a function named: "find_fallback_font" which looks for a fallback font under Software\Wine\Uniscribe\Fallback in HKEY_CURRENT_USER. But I did not find this entry populated at all. My solution is: Define a table which has a representative char for each script, now when a new wine environment is being created, query the system using FontConfig to find fonts which contains the representative chars and then populate the registry entry. How does this sound? I have a rough working version right now, should I send a patch or is something missing in my current approach? -- समीरसिंह

3 5

Wine-Staging 11.6 release
by Elizabeth Figura April 6, 2026

April 6, 2026

The Wine-Staging development release 11.6 is now available. Summary since last release: * Rebased to upstream Wine 11.6. 285 patches are applied to upstream Wine. Patches removed from Wine-Staging since the last release: * windows.web: Stub IJsonArray * windows.web: JsonArray element getters * windows.web: Rework string parsing * windows.web: Support array parsing * windows.web: Add object mapping * windows.web: JsonObject typed getters * windows.web: Support boolean & number value creation Patch sets added: * dcomp-DCompositionCreateDevice2 Patch sets otherwise updated: * vkd3d-latest Binary packages for various distributions will be available from: https://www.winehq.org/download As always, if you find a bug, please report it via https://bugs.winehq.org ἔρρωσθε, Elizabeth Figura

1 0