December 2024 - Wine-GitLab

Re: [PATCH v2 0/7] MR6911: ntdll: Add WaitCompletionPacket.
by Jinoh Kang (＠iamahuman) Dec. 1, 2024

Dec. 1, 2024

Jinoh Kang (@iamahuman) commented about server/thread.c: > return 0; > } > > +int is_obj_signaled( struct object *obj ) > +{ > + struct wait_queue_entry wait_entry; > + struct thread_wait wait = {0}; > + > + if (!obj->ops->signaled) > + return 0; > + > + wait.thread = current; This looks wrong. Unless I've mistaken, this should be the thread that *initiated* the wait (like, the one that created or associated the wait completion packet), not `current`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6911#note_89384

1 0

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Robbert van der Helm (＠robbert-vdh) Dec. 1, 2024

Dec. 1, 2024

On Sun Dec 1 20:18:56 2024 +0000, Rémi Bernon wrote: > Hi, I don't think this checks does what you describe. > This specific `if` is there for *unmanaged* windows, which are X > override-redirect windows which are fully under Wine control, and which > won't receive WM_STATE property changes. We clear the `wm_state_serial` > for them, in order to allow sending more window state changes without > waiting, as well as window configure requests. That if doesn't set > wm_state_serial, it clears it, and it shouldn't prevent the > `ConfigureNotify` to be processed, rather the other way around. > For *managed* windows, when Wine requests a window state change, the > Window Manager is supposed to change the `WM_STATE` property accordingly > once it is done, and we should then receive the corresponding > `PropertyNotify` event. We still process `ConfigureNotify` events, but > we don't apply them to the Win32 state until all the requested changes > have been processed. > If the `WM_STATE` property isn't modified or isn't present, then yes the > Win32 state will appear to be stuck forever. This is however a bug in > the window manager, according to the ICCCM, and we can really only > support ICCCM-compatible window manager (or just uncheck "allow the > window manager to manage the windows" in `winecfg`). > In any case, `ConfigureNotify` events are always processed, and applied > to the Win32 state when there's no reason to wait. XEMBED support may be > what makes a difference here, as we used only for systray embedded > windows. I don't think any other use case was very intended before or > well supported, and there's assumptions being made that embedded windows > are always systray windows > It's probably possible to support it better, and maybe even easier to do > so now that we track X parent and embedder windows without leaking them > into the Win32 space anymore. If there's a regression, please open a bug > on bugs.winehq.org, describe your use case with reproducible steps, and > we will try to fix it. Thanks for the detailed write up! I only ran into this commit after bisecting the changes between Wine 9.21 and 9.22, so I'm almost certainly missing some context! The problem I'm facing seems to be that as soon as `SWP_STATECHANGED` is set and `window_set_wm_state()` gets called, `data->wm_state_serial` gets stuck on a nonzero value since it's set to the X11 connection's next sequence number and is then never cleared again. That causes `window_update_client_config()` to always bail before it does anything, which in turn causes the `NtUserPostMessage( hwnd, WM_WINE_WINDOW_STATE_CHANGED, 0, 0 )` called from `X11DRV_ConfigureNotify()` to not do anything anymore. This doesn't seem to cause any problems under normal use cases, since normally once a window is mapped, its coordinates relative to the root window will never suddenly change (not sure if there's a spicy interaction with multiple monitors though). But in yabridge I have to reparent a Wine window to another window, and to make that work I've always had to send these `ConfigureNotify` events to inform Wine about the window's actual position on screen. Otherwise it thinks it's located in the top left corner of the screen, and all mouse events will be at an offset. I can open a regression bug report on bugs.winehq.org, but since what yabridge is doing is almost certainly not the ended way to interact with Wine, I thought I'd check here first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_89383

1 0

[PATCH 0/2] MR6939: include: Enable format attributes for debug traces in Clang MSVC mode.
by Jacek Caban (＠jacek) Dec. 1, 2024

Dec. 1, 2024

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

2 2

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Rémi Bernon Dec. 1, 2024

Dec. 1, 2024

On Sun Dec 1 18:46:02 2024 +0000, Robbert van der Helm wrote: > Hi! > This specific check causes `ConfigureNotify` events to no longer be > processed by top level windows (i.e. managed) windows. as > `wm_state_serial` will be set but never cleared again. For the last > couple years I've been sending `ConfigureNotify` events to a reparented > window to embed Wine windows into other X11 windows, but this specific > check breaks that for Wine 9.22. Wine's XEmbed support (which never > worked quite as well as the reparent+`ConfigureNotify` approach) also > does not seem to work anymore with recent Wine releases. > My question is: is this check necessary to prevent other undesirable > interactions and if so, what's the current best way to send X11 window > configuration events to Wine windows? > More context: https://github.com/robbert-vdh/yabridge/issues/382#issuecomment-2510155844 Hi, I don't think this checks does what you describe. This specific `if` is there for *unmanaged* windows, which are X override-redirect windows which are fully under Wine control, and which won't receive WM_STATE property changes. We clear the `wm_state_serial` for them, in order to allow sending more window state changes without waiting, as well as window configure requests. That if doesn't set wm_state_serial, it clears it, and it shouldn't prevent the `ConfigureNotify` to be processed, rather the other way around. For *managed* windows, when Wine requests a window state change, the Window Manager is supposed to change the `WM_STATE` property accordingly once it is done, and we should then receive the corresponding `PropertyNotify` event. We still process `ConfigureNotify` events, but we don't apply them to the Win32 state until all the requested changes have been processed. If the `WM_STATE` property isn't modified or isn't present, then yes the Win32 state will appear to be stuck forever. This is however a bug in the window manager, according to the ICCCM, and we can really only support ICCCM-compatible window manager (or just uncheck "allow the window manager to manage the windows" in `winecfg`). In any case, `ConfigureNotify` events are always processed, and applied to the Win32 state when there's no reason to wait. XEMBED support may be what makes a difference here, as we used only for systray embedded windows. I don't think any other use case was very intended before or well supported, and there's assumptions being made that embedded windows are always systray windows It's probably possible to support it better, and maybe even easier to do so now that we track X parent and embedder windows without leaking them into the Win32 space anymore. If there's a regression, please open a bug on bugs.winehq.org, describe your use case with reproducible steps, and we will try to fix it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_89382

1 0

[PATCH 0/1] MR6938: Draft: winewayland.drv: Implement support for xdg-toplevel-icon.
by Etaash Mathamsetty (＠etaash.mathamsetty) Dec. 1, 2024

Dec. 1, 2024

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

2 1

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Robbert van der Helm (＠robbert-vdh) Dec. 1, 2024

Dec. 1, 2024

Robbert van der Helm (@robbert-vdh) commented about dlls/winex11.drv/window.c: > if (!data->embedded) XIconifyWindow( data->display, data->whole_window, data->vis.screen ); > break; > } > + > + /* override redirect windows won't receive WM_STATE property changes */ > + if (!data->managed) data->wm_state_serial = 0; Hi! This specific check causes `ConfigureNotify` events to no longer be processed by top level windows (i.e. managed) windows. as `wm_state_serial` will be set but never cleared again. For the last couple years I've been sending `ConfigureNotify` events to a reparented window to embed Wine windows into other X11 windows, but this specific check breaks that for Wine 9.22. Wine's XEmbed support (which never worked quite as well as the reparent+`ConfigureNotify` approach) also does not seem to work anymore with recent Wine releases. My question is: is this check necessary to prevent other undesirable interactions and if so, what's the current best way to send X11 window configuration events to Wine windows? More context: https://github.com/robbert-vdh/yabridge/issues/382#issuecomment-2510155844 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_89380

1 0

[PATCH v10 0/1] MR6884: Draft: Iphlpapi.dll: Included SendARP
by Thi Garlet (＠garlett) Dec. 1, 2024

Dec. 1, 2024

Returns MAC address by: - search local interfaces, or - send UDP packed that does not need linux privilege, then search local cache solve https://bugs.winehq.org/show_bug.cgi?id=9418 files updated - /dlls/iphlpapi/iphlpapi_main.c - /dlls/iphlpapi/tests/iphlpapi.c -- v10: iphlpapi.c: Add SendARP https://gitlab.winehq.org/wine/wine/-/merge_requests/6884

4 3

[PATCH v2 0/6] MR6937: msvcrt: Prepare directory related functions to handle utf-8 encoded file names.
by Piotr Caban (＠piotr) Dec. 1, 2024

Dec. 1, 2024

The idea is to use common helper to convert between CP_ACP and WCHAR strings first. Later all functions will be switched to support UTF-8 at the same time. -- v2: msvcrt: Call _wfullpath in _fullpath function. msvcrt: Call _wgetdcwd in _getdcwd function. msvcrt: Call _wgetcwd in _getcwd function. msvcrt: Call _wchdir in _chdir function. msvcrt: Call _wrmdir in _rmdir function. msvcrt: Call _wmkdir in _mkdir function. https://gitlab.winehq.org/wine/wine/-/merge_requests/6937

3 7

[PATCH 0/1] MR6935: msxml3: Accept the domdoc MaxElementDepth property.
by Andrew Nguyen (＠arethusa) Dec. 1, 2024

Dec. 1, 2024

Mathcad 15 wants to set a domdoc's MaxElementDepth property to 0 on startup, but it crashes if the setProperty call fails. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57493 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6935

4 3

[PATCH v3 0/6] MR6937: msvcrt: Prepare directory related functions to handle utf-8 encoded file names.
by Piotr Caban (＠piotr) Dec. 1, 2024

Dec. 1, 2024

The idea is to use common helper to convert between CP_ACP and WCHAR strings first. Later all functions will be switched to support UTF-8 at the same time. -- v3: msvcrt: Call _wfullpath in _fullpath function. msvcrt: Call _wgetdcwd in _getdcwd function. msvcrt: Call _wgetcwd in _getcwd function. https://gitlab.winehq.org/wine/wine/-/merge_requests/6937

3 8