- Wine-GitLab - list.winehq.org

Re: [PATCH v24 0/1] MR9414: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Alexandre Julliard (＠julliard) Dec. 19, 2025

Dec. 19, 2025

Please don't rebase your MR every day, it's a waste of CI resources, and makes it look like it's not ready. We are currently in code freeze so it will have to wait anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_125887

1 0

Re: [PATCH v2 0/1] MR9798: wined3d: Update the context DC from its swapchain if it changed.
by Rémi Bernon Dec. 19, 2025

Dec. 19, 2025

Eh... thanks, I actually saw these but somehow was hoping they were just fluke. I should know better :sweat:. https://gitlab.winehq.org/wine/wine/-/merge_requests/9801 should fix it, I even had that change pending but was looking for an actual reason to send it, I guess this is it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9798#note_125885

1 0

[PATCH 0/1] MR9801: winex11: Avoid creating window data entirely for offscreen windows.
by Rémi Bernon Dec. 19, 2025

Dec. 19, 2025

This fixes a series of unfortunate changes made in 844e90b0b51c799bed68320940b51bda74ac275c b621117c652280799e209d5bec20106b1f28cb4e, which started causing various behavior changes as the (foreign / message) client window creation now triggers window data to be created, and even worse, with a whole_window set. This first makes these client windows to always be created attached to their whole window instead of the dummy parent, and, the be managed more like normal client windows and eventually detached / attached by reparenting them to / from the dummy parent. The actual issue, which started somehow after 92f5d5bc7c8412924e7cb4f6f715ecc9c4e4dd13, is that the client windows are created from an arbitrary thread, when D3D sets its internal pixel format, and this thread display is initialized and used and stored in the newly created window data. The client window lifetime is not bound to this particular thread, and it may outlive the thread itself. We then keep using a destroyed display for the reparenting calls, which is causing crashes. Using a dummy window data is enough for the client window creation to succeed and the client window will always stay attached to the dummy parent. As we don't create window data anymore, get_win_data will never succeed and we will never assume these client windows are from the current process. X11DRV_get_whole_window will works still, as we need it in some cases, but retrieving the toplevel X11 window from the window property instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9801

1 1

Re: [PATCH v2 0/1] MR9798: wined3d: Update the context DC from its swapchain if it changed.
by Alexandre Julliard (＠julliard) Dec. 19, 2025

Dec. 19, 2025

This is causing hangs in tests like evr:evr and mf:mf, could you please have a look? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9798#note_125880

1 0

[PATCH v2 0/1] MR9793: winex11: Avoid hiding windows between WM_SETREDRAW messages.
by Rémi Bernon Dec. 19, 2025

Dec. 19, 2025

See also f323d75e658fcb4f48c0b762001cee1da09d9398. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59098 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069 This is different from the Splinter Cell case, as the window processes its messages and the window get shown again, but it is still related to WM_SETREDRAW and this fix here would fix the Splinter Cell case too. I originally decided to try a simpler fix, but as this issue is also present with other applications I think it's better now to try fixing it for all of them. -- v2: winex11: Avoid hiding windows between WM_SETREDRAW messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/9793

3 10

[PATCH 0/2] MR9797: winex11: Track SWP_(SHOW|HIDE)WINDOW for window visibility.
by Rémi Bernon Dec. 19, 2025

Dec. 19, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59098 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9797

1 5

[PATCH 0/1] MR9800: winex11: Unmap windows only when SWP_HIDEWINDOW is set.
by Rémi Bernon Dec. 19, 2025

Dec. 19, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59098 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069 Instead of !9793 and !9797 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9800

1 1

[PATCH v3 0/3] MR9795: comctl32: Set default acceleration values for up-down controls.
by Sven Baars (＠sbaars) Dec. 19, 2025

Dec. 19, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57516 -- v3: comctl32: Fix the UDM_GETACCEL return value. comctl32: Set default acceleration values for up-down controls. comctl32/tests: Run the updown tests on comctl32 version 6. https://gitlab.winehq.org/wine/wine/-/merge_requests/9795

2 5

Re: [PATCH v2 0/1] MR9796: winebus: Adjust hatswitch encoding to follow T300RS and G29
by SeongChan Lee (＠foriequal0) Dec. 19, 2025

Dec. 19, 2025

On Fri Dec 19 02:25:22 2025 +0000, Tomasz Pakuła wrote: > Was this tested in other games? I'll try some come weekend but I can > only confirm simracing games. Flight would have to be confirmed separately It works fine on Dirt Rally 2.0 and BeamNG. no configuration needed after the patch, just worked. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9796#note_125866

1 0

Re: [PATCH 0/1] MR9786: server: Warn visibly if NOFILE is exceeded.
by Jinoh Kang (＠iamahuman) Dec. 18, 2025

Dec. 18, 2025

On Thu Dec 18 22:25:02 2025 +0000, Elizabeth Figura wrote: > That might catch legitimate cases from, say, a winedevice driver. That's okay as long as we don't assume or say `STATUS_TOO_MANY_OPENED_FILES` means `EMFILE`, we could simply report the error code as is. If flooding is a concern, maybe print it once? But I think drivers would only rarely print such an error code in quick succession. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9786#note_125860

1 0