- Wine-GitLab - list.winehq.org

[PATCH v7 0/4] MR10751: winscard: Implement SCardGetCardTypeProviderName and SCardListCards (smartcard database)
by Guillaume Raffin (＠TheElectronWill) May 25, 2026

May 25, 2026

These functions are necessary to make some smartcard-based programs work. They rely on the "SmartCard Database", which can be found in the windows registry, at \`HKLM\\SOFTWARE\\Microsoft\\Cryptography\\Calais\\SmartCards\`. I have added extensive unit tests and validated the implementation with a real application (an internal program based on Atos CardOS). As this is my first PR here, please don't hesitate to tell me if something's wrong! I was wondering if the database-related code should be moved to a dedicated file `winscard-database.c`? same for the tests?), let me know what you think. -- v7: winscard: Implement SCardGetCardTypeProviderNameA winscard: Implement SCardListCardsA winscard: Implement SCardListCardsW winscard: Implement SCardGetCardTypeProviderNameW https://gitlab.winehq.org/wine/wine/-/merge_requests/10751

3 9

[PATCH v15 0/4] MR10569: wineandroid: rework Android integration and switch to split process model
by Twaik Yont (＠twaik) May 25, 2026

May 25, 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> -- v15: wineandroid: split Android driver and Wine into separate processes wineandroid: terminate activity when desktop client disconnects wineandroid: make JNI initialization work with direct JVM loading wineandroid: create desktop view via ioctl and pass event pipe https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

2 6

[PATCH v2 0/1] MR10983: wined3d: Handle data aliasing when blitting to itself with FX transforms.
by Paul Gofman (＠gofman) May 25, 2026

May 25, 2026

-- v2: wined3d: Handle data aliasing when blitting to itself with FX transforms. https://gitlab.winehq.org/wine/wine/-/merge_requests/10983

3 3

[PATCH v3 0/2] MR10835: gdiplus: Add support for CMYK to ARGB pixel format conversion.
by Yongjie Yao (＠yaoyongjie) May 25, 2026

May 25, 2026

Add conversion from PixelFormat32bppCMYK to PixelFormat32bppARGB in convert_pixels(), using the standard subtractive color model formula where RGB = (255 - CMY) * (255 - K) / 255. -- v3: gdiplus: Fix return code for pixel format convertion. gdiplus/tests: Add test for pixel format conversion. https://gitlab.winehq.org/wine/wine/-/merge_requests/10835

2 2

Re: [PATCH v3 0/2] MR10809: comctl32: Fix VARHEIGHT rebar scaling when cyIntegral == 0
by Zhiyi Zhang (＠zhiyi) May 25, 2026

May 25, 2026

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/rebar.c: > > DestroyWindow(hRebar); > > + /* VARHEIGHT resizing test with cyIntegral == 0 on a horizontal rebar */ > + hRebar = create_rebar_control(0); > + SetWindowLongA(hRebar, GWL_STYLE, GetWindowLongA(hRebar, GWL_STYLE) | RBS_AUTOSIZE); > + check_sizes(); > + rbi.fMask = RBBIM_CHILD | RBBIM_CHILDSIZE | RBBIM_SIZE | RBBIM_STYLE; > + rbi.fStyle = RBBS_VARIABLEHEIGHT; > + rbi.cxMinChild = 50; Why do you need three bands? The numbers are all pretty random, so it's not obvious what you are trying to test. Please simplify it more. Focus the test on the bug that you want to fix. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10809#note_141203

1 0

Re: [PATCH v3 0/2] MR10809: comctl32: Fix VARHEIGHT rebar scaling when cyIntegral == 0
by Zhiyi Zhang (＠zhiyi) May 25, 2026

May 25, 2026

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/rebar.c: > > DestroyWindow(hRebar); > > + /* VARHEIGHT resizing test with cyIntegral == 0 on a horizontal rebar */ > + hRebar = create_rebar_control(0); > + SetWindowLongA(hRebar, GWL_STYLE, GetWindowLongA(hRebar, GWL_STYLE) | RBS_AUTOSIZE); > + check_sizes(); > + rbi.fMask = RBBIM_CHILD | RBBIM_CHILDSIZE | RBBIM_SIZE | RBBIM_STYLE; At this commit, the test fails, so it will introduce CI failures. You can put the fix in the same commit since the fix is pretty small. ``` mrebar.c:720: Test failed: invalid rect (client) (0,0)-(672,111) - expected (0,0)-(672,65) mrebar.c:720: Test failed: Height mismatch for row 0 - 65 vs 111 mrebar.c:720: Test failed: invalid rect (band) (0,0)-(90,111) - expected (0,0)-(90,65) mrebar.c:720: Test failed: invalid rect (band) (90,0)-(180,111) - expected (90,0)-(180,65) mrebar.c:720: Test failed: invalid rect (band) (180,0)-(672,111) - expected (180,0)-(672,65) ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10809#note_141202

1 0

[PATCH 0/1] MR10987: winex11.drv: Wait for the previous request when transitioning from IconicState to NormalState.
by Zhiyi Zhang (＠zhiyi) May 25, 2026

May 25, 2026

Fix a regression from 4c07e556. ea44fc34 is also related. Due to ea44fc34, when calling window_set_wm_state(WithdrawnState), Wine doesn't wait for the previous WM_STATE update to be completed. So when calling window_set_wm_state(WithdrawnState) and then window_set_wm_state(NormalState), the queued NormalState can be overwritten by an unexpected IconicState property notify event from a previous request, causing a window to be stuck in IconicState. For example, ``` 40551.339:012c:fixme:x11drv:window_set_wm_state calling XIconifyWindow for hwnd 0x200ae. ... 40551.340:012c:warn:x11drv:window_set_wm_state window 0x200ae/aa00003 is iconic, remapping to workaround Mutter issues. data->current_state.wm_state 1 data->pending_state.wm_state 3. 40551.340:012c:trace:x11drv:window_set_wm_state window 0x200ae/aa00003, requesting WM_STATE 0x3 -> 0 serial 5227, foreground 0x10020, activate 0 ... 40551.342:012c:warn:x11drv:handle_state_change window 0x200ae/aa00003 mismatch WM_STATE 0x3/5232, expected 0/5227 ``` Fix RiME(493200) sometimes fails to restore from Alt+Tab. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10987

3 3

[PATCH v4 0/6] MR10865: windows.devices.bluetooth: Add an initial implementation for IBluetoothLEDevice, IGattService.
by Vibhav Pant (＠vibhavp) May 25, 2026

May 25, 2026

-- v4: windows.devices.bluetooth: Implement IGattDeviceService::get_AttributeHandle. windows.devices.bluetooth: Implement IGattDeviceService::get_Uuid. windows.devices.bluetooth: Implement IBluetoothLEDevice::get_GattServices. windows.devices.bluetooth: Implement IBluetoothLEDevice::get_DeviceId. windows.devices.bluetooth: Implement BluetoothLEDeviceStatics::FromBluetoothAddressAsync. https://gitlab.winehq.org/wine/wine/-/merge_requests/10865

3 11

Re: [PATCH v6 0/5] MR10942: msvcp90: Add _Sinh _FSinh _LSinh _Cosh _FCosh _LCosh implementation
by Bartosz Kosiorek (＠gang65) May 25, 2026

May 25, 2026

Thank you Piotr for approval and support -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10942#note_141198

1 0

[PATCH v2 0/2] MR10969: wkscli: Add new dll
by Alistair Leslie-Hughes (＠alesliehughes) May 25, 2026

May 25, 2026

-- v2: wkscli: Move some functsion from netapi32 wkscli: Add new dll https://gitlab.winehq.org/wine/wine/-/merge_requests/10969

2 2