- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10668: mfplat: Don't set frame size or stride if missing from VIDEOINFOHEADER2.
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

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

3 2

[PATCH v12 0/5] MR9992: Introduce ImeToAsciiEx() user driver function for use in winemac
by Marc-Aurel Zent (＠mzent) April 15, 2026

April 15, 2026

-- v12: win32u: Remove builtin WINE_IME_PROCESS_KEY driver call. winemac: Move macdrv_ImeProcessKey logic to ImeProcessKey and macdrv_ImeToAsciiEx. winemac: Implement and use macdrv_ImeToAsciiEx(). win32u: Move IME processing to ImeToAsciiEx. win32u: Introduce new ImeToAsciiEx user driver call. https://gitlab.winehq.org/wine/wine/-/merge_requests/9992

4 8

[PATCH v2 0/7] MR10669: odbc32: Implement sharing environment between connections.
by Piotr Caban (＠piotr) April 15, 2026

April 15, 2026

-- v2: odbc32: Don't leak connection object if it's reused in connect functions. odbc32: Implement sharing environment handle between connections. odbc32: Don't call into driver in SQLSetEnvAttr. odbc32: Don't call into driver in SQLGetEnvAttr. odbc32: Only set connection and login timeout if it was ever set. odbc32: Use SQLFreeHandle in SQLFreeStmt if possible. odbc32: Fix SQLBrowseConnect tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10669

2 7

[PATCH v11 0/19] MR10569: wineandroid: rework Android integration and switch to split process model
by Twaik Yont (＠twaik) April 15, 2026

April 15, 2026

This series reworks the wineandroid driver and moves it away from the current “Wine inside JVM process” model to a split architecture where the Android activity (UI) and Wine run in separate processes. The existing model relies on running Wine inside the JVM process and interacting with Android through JNI callbacks and APC/unixlib-based dispatch. This approach no longer works reliably on modern Android: - Android 10+ applies seccomp restrictions to app processes, making a number of required syscalls unavailable inside the activity process, while processes started via fork/exec are not subject to the same limitations. - The implementation depends on Wine thread context (TEB), signal handling, and register state assumptions that conflict with the JVM runtime (e.g. segment register usage on x86), requiring fragile workarounds. - Due to sandboxing, it is difficult to reliably debug or even observe all failure modes, and future Android changes are likely to tighten these restrictions further. At the same time, downstream projects such as MiceWine, Winlator, Termux’s Wine environment, GameHub and GameNative already use a model where the UI (activity) and Wine run in separate processes and communicate via IPC, which has proven to work reliably on current Android systems. This series implements that model in wineandroid: - Wine is now started in a separate process via fork/exec instead of running inside the JVM process. - Android-facing code no longer depends on the Wine APC/unixlib execution path and runs on the UI thread where appropriate (e.g. native window registration). - ioctl handling is reworked to remove reliance on Wine thread context, with explicit JNIEnv usage and fd-based reply plumbing. - Environment setup and initialization are moved to the Java side, simplifying the native startup path. - Logging for ioctl paths is routed through Android logcat without depending on a Wine TEB. The changes are split into multiple bisect-safe commits to keep intermediate states functional while migrating the code step by step. With Wine running in a separate process, it is no longer subject to JVM seccomp restrictions, and there are no longer conflicts between JVM and Wine execution contexts (signals, thread state, register usage, etc.). <details> <summary>Old message</summary> wineandroid: move ioctl handling to dedicated Java-only thread Move ioctl handling out of the Wine APC/unixlib execution path into a dedicated Java-only thread without Wine context. On Android 10+ a number of syscalls are restricted inside the activity process via seccomp, while processes started via fork/exec are not subject to the same limitations. Decoupling ioctl handling from the Wine context is required to eventually run this code outside of the activity process. This change introduces a new transport and execution model where ioctl dispatch no longer depends on Wine thread state, preparing for moving the Android backend into a separate process. The refactor is intentionally split into multiple bisect-safe commits to keep intermediate states functional while gradually migrating the dispatch path. Since this is a fairly large chunk of work, I’d like to make sure we’re aligned before continuing. </details> -- v11: wineandroid: terminate activity when desktop client disconnects This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

1 0

[PATCH v10 0/18] MR10569: wineandroid: rework Android integration and switch to split process model
by Twaik Yont (＠twaik) April 15, 2026

April 15, 2026

This series reworks the wineandroid driver and moves it away from the current “Wine inside JVM process” model to a split architecture where the Android activity (UI) and Wine run in separate processes. The existing model relies on running Wine inside the JVM process and interacting with Android through JNI callbacks and APC/unixlib-based dispatch. This approach no longer works reliably on modern Android: - Android 10+ applies seccomp restrictions to app processes, making a number of required syscalls unavailable inside the activity process, while processes started via fork/exec are not subject to the same limitations. - The implementation depends on Wine thread context (TEB), signal handling, and register state assumptions that conflict with the JVM runtime (e.g. segment register usage on x86), requiring fragile workarounds. - Due to sandboxing, it is difficult to reliably debug or even observe all failure modes, and future Android changes are likely to tighten these restrictions further. At the same time, downstream projects such as MiceWine, Winlator, Termux’s Wine environment, GameHub and GameNative already use a model where the UI (activity) and Wine run in separate processes and communicate via IPC, which has proven to work reliably on current Android systems. This series implements that model in wineandroid: - Wine is now started in a separate process via fork/exec instead of running inside the JVM process. - Android-facing code no longer depends on the Wine APC/unixlib execution path and runs on the UI thread where appropriate (e.g. native window registration). - ioctl handling is reworked to remove reliance on Wine thread context, with explicit JNIEnv usage and fd-based reply plumbing. - Environment setup and initialization are moved to the Java side, simplifying the native startup path. - Logging for ioctl paths is routed through Android logcat without depending on a Wine TEB. The changes are split into multiple bisect-safe commits to keep intermediate states functional while migrating the code step by step. With Wine running in a separate process, it is no longer subject to JVM seccomp restrictions, and there are no longer conflicts between JVM and Wine execution contexts (signals, thread state, register usage, etc.). <details> <summary>Old message</summary> wineandroid: move ioctl handling to dedicated Java-only thread Move ioctl handling out of the Wine APC/unixlib execution path into a dedicated Java-only thread without Wine context. On Android 10+ a number of syscalls are restricted inside the activity process via seccomp, while processes started via fork/exec are not subject to the same limitations. Decoupling ioctl handling from the Wine context is required to eventually run this code outside of the activity process. This change introduces a new transport and execution model where ioctl dispatch no longer depends on Wine thread state, preparing for moving the Android backend into a separate process. The refactor is intentionally split into multiple bisect-safe commits to keep intermediate states functional while gradually migrating the dispatch path. Since this is a fairly large chunk of work, I’d like to make sure we’re aligned before continuing. </details> -- v10: wineandroid: split Android driver and Wine into separate processes This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

1 0

[PATCH 0/6] MR10669: odbc32: Implement sharing environment between connections.
by Piotr Caban (＠piotr) April 15, 2026

April 15, 2026

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

2 6

[PATCH v9 0/18] MR10569: wineandroid: rework Android integration and switch to split process model
by Twaik Yont (＠twaik) April 15, 2026

April 15, 2026

This series reworks the wineandroid driver and moves it away from the current “Wine inside JVM process” model to a split architecture where the Android activity (UI) and Wine run in separate processes. The existing model relies on running Wine inside the JVM process and interacting with Android through JNI callbacks and APC/unixlib-based dispatch. This approach no longer works reliably on modern Android: - Android 10+ applies seccomp restrictions to app processes, making a number of required syscalls unavailable inside the activity process, while processes started via fork/exec are not subject to the same limitations. - The implementation depends on Wine thread context (TEB), signal handling, and register state assumptions that conflict with the JVM runtime (e.g. segment register usage on x86), requiring fragile workarounds. - Due to sandboxing, it is difficult to reliably debug or even observe all failure modes, and future Android changes are likely to tighten these restrictions further. At the same time, downstream projects such as MiceWine, Winlator, Termux’s Wine environment, GameHub and GameNative already use a model where the UI (activity) and Wine run in separate processes and communicate via IPC, which has proven to work reliably on current Android systems. This series implements that model in wineandroid: - Wine is now started in a separate process via fork/exec instead of running inside the JVM process. - Android-facing code no longer depends on the Wine APC/unixlib execution path and runs on the UI thread where appropriate (e.g. native window registration). - ioctl handling is reworked to remove reliance on Wine thread context, with explicit JNIEnv usage and fd-based reply plumbing. - Environment setup and initialization are moved to the Java side, simplifying the native startup path. - Logging for ioctl paths is routed through Android logcat without depending on a Wine TEB. The changes are split into multiple bisect-safe commits to keep intermediate states functional while migrating the code step by step. With Wine running in a separate process, it is no longer subject to JVM seccomp restrictions, and there are no longer conflicts between JVM and Wine execution contexts (signals, thread state, register usage, etc.). <details> <summary>Old message</summary> wineandroid: move ioctl handling to dedicated Java-only thread Move ioctl handling out of the Wine APC/unixlib execution path into a dedicated Java-only thread without Wine context. On Android 10+ a number of syscalls are restricted inside the activity process via seccomp, while processes started via fork/exec are not subject to the same limitations. Decoupling ioctl handling from the Wine context is required to eventually run this code outside of the activity process. This change introduces a new transport and execution model where ioctl dispatch no longer depends on Wine thread state, preparing for moving the Android backend into a separate process. The refactor is intentionally split into multiple bisect-safe commits to keep intermediate states functional while gradually migrating the dispatch path. Since this is a fairly large chunk of work, I’d like to make sure we’re aligned before continuing. </details> -- v9: wineandroid: split Android driver and Wine into separate processes wineandroid: make JNI initialization work with direct JVM loading wineandroid: create desktop view via ioctl and pass event pipe wineandroid: return ioctl errors directly wineandroid: remove unixlib/ntoskrnl ioctl path wineandroid: switch dequeueBuffer to socket transport wineandroid: switch ioctl dispatch to socket transport on main thread looper wineandroid: pass JNIEnv explicitly through ioctl handlers wineandroid: add reply_fd plumbing to ioctl path wineandroid: move native window registration to surface_changed wineandroid: simplify client pid handling wineandroid: use Android logging for ioctl dispatch paths wineandroid: load AHardwareBuffer symbols from libandroid wineandroid: switch java_* variables to direct linking wineandroid: set environment in Java and simplify wine_init wineandroid: fix loader path and library lookup for modern Wine/Android wineandroid: lower targetSdkVersion to avoid Android 10 W^X restrictions wineandroid: fix 64-bit crash in setCursor JNI call This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

1 1

[PATCH 0/2] MR10072: shell32: Always update `outlen` (`pcchOut`) when querying strings
by Marijn Suijten (＠Marijn) April 15, 2026

April 15, 2026

At least `AssocQueryStringW()` is documented to update the character count in `pcchOut` to "the number of characters actually placed in the buffer" which requires us to update the value of `*outlen` even when the buffer size was sufficient: https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-asso… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59402 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10072

2 3

[PATCH v7 0/7] MR10604: setupapi, ntoskrnl: Implement CM_Get_Parent with device tree properties
by Jan Robert Gerigk (＠RgSg86) April 15, 2026

April 15, 2026

Wine Bug: https://bugs.winehq.org/show_bug.cgi?id=59604 Implement CM_Get_Parent by storing device tree relationship properties when ntoskrnl enumerates child devices via IRP_MN_QUERY_DEVICE_RELATIONS: - DEVPKEY_Device_Parent on each child device - DEVPKEY_Device_Children on the parent device - DEVPKEY_Device_Siblings on each child device CM_Get_Parent reads DEVPKEY_Device_Parent through SetupDiGetDevicePropertyW. Also fix SETUPDI_EnumerateMatchingInterfaces to remove devices without interfaces from DIGCF_DEVICEINTERFACE enumeration results. --\> no more phantom devices Based on discussion with Rémi Bernon (Bug 59604) Tested on a fresh Wine 11.6 setup with KNX ETS 6.4.1: A USB HID license dongle (VID 2A07, PID 0102) is now correctly identified through CM_Get_Parent device tree navigation. -- v7: ntoskrnl/tests: Add DEVPKEY_Device_Parent test. setupapi/tests: Add CM_Get_Parent tests. cfgmgr32: Implement CM_Get_Parent using DEVPKEY_Device_Parent property. https://gitlab.winehq.org/wine/wine/-/merge_requests/10604

2 8

[PATCH 0/2] MR10666: mf/tests: Check some IMFTransform / IMediaObject interop.
by Rémi Bernon (＠rbernon) April 15, 2026

April 15, 2026

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

2 2