- Wine-GitLab - list.winehq.org

Re: [PATCH v4 0/1] MR10052: dinput: Return DIERR_UNSUPPORTED in dinput_device_Escape
by Rémi Bernon Feb. 9, 2026

Feb. 9, 2026

If you have a good reason for doing that explain yourself, otherwise stop. This MR looks perfectly fine to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10052#note_129223

1 0

[PATCH v2 0/1] MR10054: mf: Don't perform preroll if we are scrubbing.
by Brendan McGrath (＠redmcg) Feb. 9, 2026

Feb. 9, 2026

Tests on Windows show that a preroll isn't requested by the media session if rate is zero. This MR changes media session to match that behaviour. -- v2: mf: Don't perform preroll if we are scrubbing. https://gitlab.winehq.org/wine/wine/-/merge_requests/10054

3 4

Re: [PATCH v4 0/1] MR10052: dinput: Return DIERR_UNSUPPORTED in dinput_device_Escape - closed
by David Kahurani (＠ReDress) Feb. 9, 2026

Feb. 9, 2026

This merge request was closed by David Kahurani. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10052

1 0

[PATCH v3 0/1] MR10052: dinput: Return DIERR_UNSUPPORTED in dinput_device_Escape
by Viktor Balogh (＠viktorb) Feb. 9, 2026

Feb. 9, 2026

At least Thrustmaster wheels are known for using the Escape method for communication between the driver and the game. This is not utilized by every game, but one that does is RaceRoom Racing Experience (RRRE). RRRE uses it to query/set the wheel range and set force strengths. The problematic part is the wheel range query, because the returned value (0) is not the real range and that throws off the internal logic of RRRE's engine and causes the wheel to snap in one direction. Returning DIERR_UNSUPPORTED clearly indicates that the call failed and RRRE no longer tries to use these methods for interaction with the wheel. Returning DIERR_UNSUPPORTED is also aligns with the behaviour of `hid_joystick_effect_Escape`. Captures of what RRRE used are available over here: https://github.com/Kimplul/hid-tmff2/issues/165 See this issue for more context and the resolution: https://github.com/Kimplul/hid-tmff2/issues/39#issuecomment-3104689106 -- v3: dinput: Return DIERR_UNSUPPORTED in dinput_device_Escape https://gitlab.winehq.org/wine/wine/-/merge_requests/10052

4 4

[PATCH 0/1] MR9765: ws2_32 / Add stub for WSCInstallProvider64_32
by Janne Kekkonen (＠Janne) Feb. 9, 2026

Feb. 9, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58853 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9765

3 4

[PATCH v3 0/4] MR10060: Draft: comdlg32: Use XDG Desktop Portal for native file dialogs
by Alexander Wilms (＠Alexander-Wilms) Feb. 9, 2026

Feb. 9, 2026

This adds XDG desktop portal integration for Wine file dialogs, with compatibility fallbacks, and solves https://bugs.winehq.org/show_bug.cgi?id=51134 I used an LLM to create the patches, the wiki does not contain an LLM policy, so I don't know if this is eligible to be merged at all. I used the following sources: - https://github.com/MicrosoftDocs/win32 which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/menurc/resource-compiler - https://github.com/MicrosoftDocs/sdk-api which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-geto… - https://github.com/flatpak/xdg-desktop-portal - https://github.com/notepad-plus-plus/notepad-plus-plus to determine what calls are made when choosing Save As, since it initially didn't work - Wine logs from manual testing after adding extensive TRACE calls: - Wine `notepad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - Wine `wordpad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - [`hammerplusplus.exe`](https://ficool2.github.io/HammerPlusPlus-Website/index.html) (32-bit): `IFileDialog` (`IFileDialog2_fnShow`) Open/Save As via portal - `SumatraPDF.exe`: Open via `GetOpenFileNameW` in auto; Save As uses `GetSaveFileNameW` and falls back in case of the auto policy, but uses portal when forced (WINE_FORCE_PORTAL=1) - `notepad++.exe`: `IFileDialog` (`IFileDialog2_fnShow`) Save As via portal after result-path handling fixes Implementation: - Add a portal backend in `comdlg32` for file open/save requests - Add portal handling for `GetOpenFileNameW`, `GetOpenFileNameA`, `GetSaveFileNameW`, and `GetSaveFileNameA` when requests are compatible with portal features - Route compatible `IFileDialog`/`IFileOpenDialog`/`IFileSaveDialog` paths through the portal - Keep native Wine dialogs in case of unsupported/customized dialog options - Add a combobox to `winecfg` to select the policy for XDG Desktop Portal file dialogs: auto / always / never ![image](/uploads/2a1ded4968485e84aebfc1f0ceed0aa4/image.png){width=900 height=486} ![image](/uploads/0c70d44a21fd9334de55ce64ccb4fa9b/image.png){width=900 height=486} ![image](/uploads/5f3821abbf42809cafd5edbcb343b0f8/image.png){width=485 height=600} -- v3: comdlg32/tests: add IFileOpenDialog FOS_PICKFOLDERS runtime check winecfg: add portal file dialog policy and UI comdlg32: route IFileDialog through portal when compatible comdlg32: add XDG desktop portal backend for file dialogs https://gitlab.winehq.org/wine/wine/-/merge_requests/10060

2 4

[PATCH v2 0/4] MR10060: Draft: comdlg32: Use XDG Desktop Portal for native file dialogs
by Alexander Wilms (＠Alexander-Wilms) Feb. 9, 2026

Feb. 9, 2026

This adds XDG desktop portal integration for Wine file dialogs, with compatibility fallbacks, and solves https://bugs.winehq.org/show_bug.cgi?id=51134 I used an LLM to create the patches, the wiki does not contain an LLM policy, so I don't know if this is eligible to be merged at all. I used the following sources: - https://github.com/MicrosoftDocs/win32 which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/menurc/resource-compiler - https://github.com/MicrosoftDocs/sdk-api which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-geto… - https://github.com/flatpak/xdg-desktop-portal - https://github.com/notepad-plus-plus/notepad-plus-plus to determine what calls are made when choosing Save As, since it initially didn't work - Wine logs from manual testing after adding extensive TRACE calls: - Wine `notepad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - Wine `wordpad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - [`hammerplusplus.exe`](https://ficool2.github.io/HammerPlusPlus-Website/index.html) (32-bit): `IFileDialog` (`IFileDialog2_fnShow`) Open/Save As via portal - `SumatraPDF.exe`: Open via `GetOpenFileNameW` in auto; Save As uses `GetSaveFileNameW` and falls back in case of the auto policy, but uses portal when forced (WINE_FORCE_PORTAL=1) - `notepad++.exe`: `IFileDialog` (`IFileDialog2_fnShow`) Save As via portal after result-path handling fixes Implementation: - Add a portal backend in `comdlg32` for file open/save requests - Add portal handling for `GetOpenFileNameW`, `GetOpenFileNameA`, `GetSaveFileNameW`, and `GetSaveFileNameA` when requests are compatible with portal features - Route compatible `IFileDialog`/`IFileOpenDialog`/`IFileSaveDialog` paths through the portal - Keep native Wine dialogs in case of unsupported/customized dialog options - Add a combobox to `winecfg` to select the policy for XDG Desktop Portal file dialogs: auto / always / never ![image](/uploads/2a1ded4968485e84aebfc1f0ceed0aa4/image.png){width=900 height=486} ![image](/uploads/0c70d44a21fd9334de55ce64ccb4fa9b/image.png){width=900 height=486} ![image](/uploads/5f3821abbf42809cafd5edbcb343b0f8/image.png){width=485 height=600} -- v2: comdlg32/tests: add IFileOpenDialog FOS_PICKFOLDERS runtime check winecfg: add portal file dialog policy and UI https://gitlab.winehq.org/wine/wine/-/merge_requests/10060

2 4

[PATCH 0/4] MR10060: Draft: Use XDG Desktop Portal for native file dialogs
by Alexander Wilms (＠Alexander-Wilms) Feb. 9, 2026

Feb. 9, 2026

This adds XDG desktop portal integration for Wine file dialogs, with compatibility fallbacks, and solves https://bugs.winehq.org/show_bug.cgi?id=51134 I used an LLM to create the patches, the wiki does not contain an LLM policy, so I don't know if this is eligible to be merged at all. I used the following sources: - https://github.com/MicrosoftDocs/win32 which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/menurc/resource-compiler - https://github.com/MicrosoftDocs/sdk-api which contains the markdown sources for e.g. - https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-geto… - https://github.com/flatpak/xdg-desktop-portal - https://github.com/notepad-plus-plus/notepad-plus-plus to determine what calls are made when choosing Save As, since it initially didn't work - Wine logs from manual testing after adding extensive TRACE calls: - Wine `notepad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - Wine `wordpad.exe`: `GetOpenFileNameW` / `GetSaveFileNameW` via portal - [`hammerplusplus.exe`](https://ficool2.github.io/HammerPlusPlus-Website/index.html) (32-bit): `IFileDialog` (`IFileDialog2_fnShow`) Open/Save As via portal - `SumatraPDF.exe`: Open via `GetOpenFileNameW` in auto; Save As uses `GetSaveFileNameW` and falls back in case of the auto policy, but uses portal when forced (WINE_FORCE_PORTAL=1) - `notepad++.exe`: `IFileDialog` (`IFileDialog2_fnShow`) Save As via portal after result-path handling fixes Implementation: - Add a portal backend in `comdlg32` for file open/save requests - Add portal handling for `GetOpenFileNameW`, `GetOpenFileNameA`, `GetSaveFileNameW`, and `GetSaveFileNameA` when requests are compatible with portal features - Route compatible `IFileDialog`/`IFileOpenDialog`/`IFileSaveDialog` paths through the portal - Keep native Wine dialogs in case of unsupported/customized dialog options - Add a combobox to `winecfg` to select the policy for XDG Desktop Portal file dialogs: auto / always / never ![image](/uploads/2a1ded4968485e84aebfc1f0ceed0aa4/image.png){width=900 height=486} ![image](/uploads/0c70d44a21fd9334de55ce64ccb4fa9b/image.png){width=900 height=486} ![image](/uploads/5f3821abbf42809cafd5edbcb343b0f8/image.png){width=485 height=600} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10060

2 4

[PATCH v2 0/4] MR10006: windows.devices.bluetooth: Add initial implementation for BluetoothAdapter.
by Vibhav Pant (＠vibhavp) Feb. 9, 2026

Feb. 9, 2026

-- v2: windows.devices.bluetooth: Implement BluetoothAdapter::get_BluetoothAddress. windows.devices.bluetooth: Implement BluetoothAdapter::FromIdAsync. windows.devices.bluetooth: Implement BluetoothAdapter::GetDefaultAsync. windows.devices.bluetooth/tests: Add initial tests for BluetoothAdapter. https://gitlab.winehq.org/wine/wine/-/merge_requests/10006

2 4

[PATCH v10 0/4] MR10007: Support enabling/disabling IME on winewayland
by Ziia Shi (＠mkrsym1) Feb. 9, 2026

Feb. 9, 2026

Currently, IME is always enabled for all applications. This can cause some very annoying issues on winewayland. For example, fcitx takes over the character repeat functionality when enabled, and does it via repeatedly sending sequences of keyup/keydown, which leads to applications not being able to track hold duration of a button (can be reproduced on any game which requires holding a letter key). The spec states that the enable request should only be sent when a text edit is focused, and a disable request should be sent when it is unfocused. Windows provides a "similar-ish" mechanism: applications can use ImmAssociateContext/ImmAssociateContextEx to associate an IMC when IME should be enabled, and set associated IMC to null when it should be disabled. From my rather limited testing, it is implemented this way in Chromium/CEF, QT and Unity. Setting it to null internally results in deactivation of the currently associated context. This MR makes the ImeSetActiveContext function of the builtin IME utilize a new driver function to communicate activation status. It does not take into account which specific context was activated, thus semi-stub. This fixes behavior of applications using the above-mentioned components. I only implemented it for winewayland, it probably should also be implemented for winex11 too, but I'm not sure how. ~~Unfortunately this breaks IME input in Wine comctl32/user32 components. I am not sure how it is supposed to behave on Windows or how to test it at the current point, will look into it later. Having IME on by default appears to "fix" it, but that is very likely not the Windows behavior; moreover, at least Unity does not disable IME on start, which causes the above-mentioned issue to occur until a textbox is manually focused and unfocused.~~ Fixed -- v10: win32u: Call SetIMEEnabled from NtUserAssociateInputContext. imm32/tests: Test which IME receives ImeSetActiveContext deactivation call after layout change. winewayland: Implement SetIMEEnabled driver call. win32u: Add SetIMEEnabled driver call. https://gitlab.winehq.org/wine/wine/-/merge_requests/10007

3 7