February 2025 - wine-gitlab

[PATCH v3 0/4] MR7375: dlls/oleaut32: Consistently use TLB_REF_NOT_FOUND
by Edward OC (＠funfunctor) 22 Feb '25

22 Feb '25

Trivial, small set of cleanups patches to start with, non-controversial and NOP functionally speaking. These are to help get the review process going in making ways towards the bar being lowered for contributing to the oleaut32 implementation. Signed-off-by: Edward O'Callaghan <edward(a)antitrust.cc> -- v3: test-linux32: Disable broken tests that are already released broken dlls/oleaut32: Invert if-stmt in ITypeLib2_fnRelease() dlls/oleaut32: Invert if stmt for clarity dlls/oleaut32: Consistently use TLB_REF_NOT_FOUND https://gitlab.winehq.org/wine/wine/-/merge_requests/7375

3 4

[PATCH 0/2] MR7403: user32: Call UpdateWindow() after showing a dialog.
by Elizabeth Figura (＠zfigura) 22 Feb '25

22 Feb '25

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

4 4

Re: [PATCH v4 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by eric pouech (＠epo) 22 Feb '25

22 Feb '25

yes `dir /p` needs to be fixed, and what you propose does work for the regular use (cmd in interactive mode...) did some testing on windows which confirm that ENABLE_PROCESSED_INPUT should be kept in wait operation * piping ctrl-c character in input stream doesn't stop the `dir /p` command * while hitting ctrl-c from keyboard (from the same pipe command) does * this means that the console is always kept in processed mode, and the ctrl-c is always returned through the ctrl-c handler and not as a character in input stream actually, I'd prefer to have a dedicated helper to only wait for user input (it doesn't prevent to have another helper which does {print message(); wait for input(); print \\r\\n}); and we tend to place generic helpers in wcmdmain.c there are some functional points to consider: * may be setting console mode to ENABLE_PROCESSED_INPUT only is too aggressive; it looks like only clearing ENABLE_LINE_INPUT could be sufficient (you may want to keep ENABLE_ECHO_INPUT to have character printed) * console mode isn't reset on error path * the most annoying bit is that the ctrl-c isn't handled * this may end up a bit complicated as you need to wait on two objects; WCMD_choice could help for some waitable reads, but not all the input handles are opened in overlapped mode \<g\> * and also, it must ensure that the callers to that helper correctly support the STATUS_CONTROL_C_EXIT (`pause` seems to ignore it, `dir` now has support for ctrl-c return code) note: builtin cmd doesn't properly implement pipes between commands, so don't try test it -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_95627

1 0

[PATCH 0/1] MR7404: makecab: Add stub program.
by Mohamad Al-Jaf (＠maljaf) 22 Feb '25

22 Feb '25

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

2 1

[PATCH v3 0/2] MR7353: winewayland: Implement SetCursorPos via pointer lock.
by Attila Fidan (＠atticf) 22 Feb '25

22 Feb '25

There is no ([not yet?](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requ…) dedicated protocol for requesting pointer warps, but it's possible to request one with `zwp_locked_pointer_v1.set_cursor_position_hint` which may be performed when the pointer is unlocked. The idea is to quickly lock/set position/unlock. This is used by SDL (in some cases: [SDL_MOUSE_EMULATE_WARP_WITH_RELATIVE](https://wiki.libsdl.org/SDL3/SDL_HINT…) and Xwayland. The limitation is/will be that the compositor will ignore requests to warp the pointer outside of surface bounds. What I'd like to have working is the auto cursor placement feature of some applications, where they just want to call SetCursorPos towards specific UI elements inside their single window, and usually they'll be unclipped and have a visible cursor while doing this. This patch also happens to allow mouselook to work in applications which use SetCursorPos for mouselook and aren't getting covered by the heuristics that turn on Wayland relative motion (for some reason the driver thinks the cursor is visible). Seems to affect Half-Life (GoldSrc) on my system. Though force enabling relative motion with an environment variable in a custom build or somehow improving the heuristics will also fix that. A suface/pointer can only have one lock or confinement, and this implementation depends on the pointer lock. So if needed, I temporarily unlock/unconfine in order to do the warp then relock/reconfine. I modified `wayland_pointer_update_constraint` so I don't have to temporarily disable relative motion during this in case it's enabled. I think it's safe/a no-op to attempt pointer warps while using relative motion, as according to the protocol the warp will not generate a relative motion event, and while there will be a wl_pointer motion event, they're ignored while relative motion is being used. -- v3: winewayland: Implement SetCursorPos via pointer lock. https://gitlab.winehq.org/wine/wine/-/merge_requests/7353

2 2

[PATCH v2 0/2] MR7353: winewayland: Implement SetCursorPos via pointer lock.
by Attila Fidan (＠atticf) 22 Feb '25

22 Feb '25

There is no ([not yet?](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requ…) dedicated protocol for requesting pointer warps, but it's possible to request one with `zwp_locked_pointer_v1.set_cursor_position_hint` which may be performed when the pointer is unlocked. The idea is to quickly lock/set position/unlock. This is used by SDL (in some cases: [SDL_MOUSE_EMULATE_WARP_WITH_RELATIVE](https://wiki.libsdl.org/SDL3/SDL_HINT…) and Xwayland. The limitation is/will be that the compositor will ignore requests to warp the pointer outside of surface bounds. What I'd like to have working is the auto cursor placement feature of some applications, where they just want to call SetCursorPos towards specific UI elements inside their single window, and usually they'll be unclipped and have a visible cursor while doing this. This patch also happens to allow mouselook to work in applications which use SetCursorPos for mouselook and aren't getting covered by the heuristics that turn on Wayland relative motion (for some reason the driver thinks the cursor is visible). Seems to affect Half-Life (GoldSrc) on my system. Though force enabling relative motion with an environment variable in a custom build or somehow improving the heuristics will also fix that. A suface/pointer can only have one lock or confinement, and this implementation depends on the pointer lock. So if needed, I temporarily unlock/unconfine in order to do the warp then relock/reconfine. I modified `wayland_pointer_update_constraint` so I don't have to temporarily disable relative motion during this in case it's enabled. I think it's safe/a no-op to attempt pointer warps while using relative motion, as according to the protocol the warp will not generate a relative motion event, and while there will be a wl_pointer motion event, they're ignored while relative motion is being used. -- v2: winewayland: Implement SetCursorPos via pointer lock. winewayland: Update locked pointer position hint. https://gitlab.winehq.org/wine/wine/-/merge_requests/7353

2 3

[PATCH v7 0/2] MR7392: server: Don't ceil poll timeouts to the next millisecond if higher resolution timeouts are supported.
by William Horvath (＠whrvt) 21 Feb '25

21 Feb '25

This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls). By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout). This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter. -- v7: server: Use epoll_pwait2 for the main loop on Linux. server: Use a high precision timespec directly for poll timeouts on supported platforms. https://gitlab.winehq.org/wine/wine/-/merge_requests/7392

2 3

[PATCH v6 0/2] MR7392: server: Add an epoll_pwait2 path for server_main_loop if supported.
by William Horvath (＠whrvt) 21 Feb '25

21 Feb '25

This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls). By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout). This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter. -- v6: server: Use epoll_pwait2 for the main loop on Linux. server: Use a high precision timespec directly for poll timeouts on supported platforms. https://gitlab.winehq.org/wine/wine/-/merge_requests/7392

2 3

Re: [PATCH v2 0/1] MR7390: po: update Polish translation - approved
by Alexandre Julliard (＠julliard) 21 Feb '25

21 Feb '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7390

1 0

Re: [PATCH v2 0/1] MR7396: winex11: Delay changing window config if win32 side is still minimized. - approved
by Alexandre Julliard (＠julliard) 21 Feb '25

21 Feb '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7396

1 0

2025

2024

2023

2022

wine-gitlab February 2025