- wine-gitlab - winehq.org

[PATCH 0/4] MR6818: Debug directory lookup in dbghelp.
by eric pouech (＠epo) 15 Nov '24

15 Nov '24

This MR is a subset of MR 6715 [1]. It mainly contains fixes and improvements in dbghelp handling of DEBUG directories in PE header. Since 6715 may take some time to be finished (may take some more time to have an approved solution), it seems preferable to land these fixes/improvements in Wine before code freeze. The changes in this MR: - fixes loading dwarf info from PE files compiled by gcc/mingw with --build-id option, - several improvements for SymSrvGetFileIndexInfo (esp. native fails with ERROR_BAD_EXE_FORMAT error code when there is no DEBUG directory; yet, does it fill most of the information out of the PE image... Note that images compiled with gcc/mingw compilation (dwarf debug info, no buildid don't have DEBUG directories) So mimic native's behavior, and fix some code paths accordingly, - some fixes for .dbg handling (not much of an use today anyway). [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/6715 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6818

2 5

[PATCH v4 0/2] MR6819: Add Japanese IME virtual key codes to winuser.rh.
by Marc-Aurel Zent (＠mzent) 15 Nov '24

15 Nov '24

Also removes ime.h from x11 keyboard driver. In the that file imported from the mingw-w64 runtime seem also to be typos like `WM_IMEKEYDOWN` and `WM_IMEKEYUP` and is not used at all in wine, so theoretically it could be removed entirely... Not too sure if there are any winelib considerations to be had here though. -- v4: winex11: Include kbd.h instead of ime.h. include: Add Japanese IME virtual key codes to kbd.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/6819

4 7

[PATCH 0/2] MR6810: comctl32/listview: Initialize hot cursor handle.
by Nikolay Sivov (＠nsivov) 15 Nov '24

15 Nov '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6810

4 4

Re: [PATCH v5 0/2] MR5633: win32u: Use the first vertical alternates table regardless of script. - approved
by Nikolay Sivov (＠nsivov) 15 Nov '24

15 Nov '24

This merge request was approved by Nikolay Sivov. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5633

1 0

Re: [PATCH v5 0/2] MR5633: win32u: Use the first vertical alternates table regardless of script.
by Nikolay Sivov (＠nsivov) 15 Nov '24

15 Nov '24

On Fri Nov 15 14:47:18 2024 +0000, Akihiro Sagawa wrote: > I manually tested the vertical features using a specially crafted > TrueType file. > The font file displays different circled numbers as vertical substitutes > for Japanese punctuation marks (U+3001, U+3002) based on its lookup > table. > If the implementation chooses: > - the first vert feature, i.e. no script/lang lookup, the app shows ① > (U+2460's glyph). > - the first script/lang tag (@@@@), it shows ② (U+2461's). > - the 'DFLT' script, it shows ③ (U+2462's). > - the 'kana' script, it shows ④ (U+2463's). > What we can see is ① with plain gdi API. > ![Capture](/uploads/ce5cba3c12e0debd2bdac94fd017d842/Capture.png) > See [gsub.txt](/uploads/9d5ef683f937fc0b48f9f7e833fab930/gsub.txt) file > in ttx format for details, please. Thank you, this looks conclusive enough for me. Please rebase, but otherwise I think it's ready. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5633#note_87626

1 0

[PATCH 0/1] MR6824: include: Add UI Automation Annotation Type ID definitions.
by Biswapriyo Nath (＠Biswa96) 15 Nov '24

15 Nov '24

Required for https://github.com/mozilla/gecko-dev/commit/c7ba4a96408cba7653ac1b7eb4ba105… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6824

3 2

Re: [PATCH v5 0/2] MR5633: win32u: Use the first vertical alternates table regardless of script.
by Akihiro Sagawa (＠sgwaki) 15 Nov '24

15 Nov '24

On Fri Nov 15 14:46:06 2024 +0000, Nikolay Sivov wrote: > I think the remaining question here is if we want to remove script/lang > lookup logic entirely, or instead prioritize. @sgwaki, any idea if it's > possible to test that? Testing manually is fine. To be clear, test font > should have at least two differing vert features, with second feature > being testable with specific script/lang pair, if that is possible to > achieve with plain gdi API at all. I manually tested the vertical features using a specially crafted TrueType file. The font file displays different circled numbers as vertical substitutes for Japanese punctuation marks (U+3001, U+3002) based on its lookup table. If the implementation chooses: - the first vert feature, i.e. no script/lang lookup, the app shows ① (U+2460's glyph). - the first script/lang tag (@@@@), it shows ② (U+2461's). - the 'DFLT' script, it shows ③ (U+2462's). - the 'kana' script, it shows ④ (U+2463's). What we can see is ① with plain gdi API. ![Capture](/uploads/ce5cba3c12e0debd2bdac94fd017d842/Capture.png) See [gsub.txt](/uploads/9d5ef683f937fc0b48f9f7e833fab930/gsub.txt) file in ttx format for details, please. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5633#note_87621

1 0

[PATCH v7 0/10] MR6569: Draft: winex11: Refactor window state/config tracker to fix race conditions.
by Rémi Bernon (＠rbernon) 15 Nov '24

15 Nov '24

This completely refactors the winex11 window state tracking, keeping track of the desired/pending/current window state and config in a fully asynchronous way, and avoiding duplicate requests. I believe this mitigates various race conditions that we're suffering from, solving most spurious event feedback loops when the X11 state is being applied while some win32 state change is being requested, and fixing the spurious d3d/ddraw/user32 test failures. -- v7: winex11: Request window state updates asynchronously. winex11: Update the window client config on window state changes. winex11: Wait for pending ConfigureNotify before updating the client state. winex11: Wait for pending _NET_WM_STATE before updating the client state. winex11: Ignore focus changes during WM_STATE transitions. winex11: Introduce a new window_update_client_config helper. winex11: Introduce a new window_update_client_state helper. winex11: Use the new window state tracker to get WM_STATE value. winex11: Use the new window state tracker to get _NET_WM_STATE value. d3d9/tests: Flush events after minimizing and restoring focus window. https://gitlab.winehq.org/wine/wine/-/merge_requests/6569

2 10

[PATCH v16 0/4] MR4551: Server-side thread priorities implementation (Part 1)
by Marc-Aurel Zent (＠mzent) 15 Nov '24

15 Nov '24

This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on. ~~I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).~~ A few tiny changes ~~(with the ready variable for example)~~ are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change. Since this is a rather large MR, I hope the split here is appropriate ~~(with the second part being slightly smaller)~~, but I think logically it makes the most sense here. -- v16: server: Check wineserver privileges on init with -20 niceness. server: Use setpriority to update thread niceness when safe. ntdll: Set RLIMIT_NICE to its hard limit. server: Introduce new set_thread_priority helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/4551

5 6

[PATCH 0/1] MR6822: winex11: Ignore focus changes during WM_STATE transitions.
by Rémi Bernon (＠rbernon) 15 Nov '24

15 Nov '24

When WM_STATE is being quickly updated, and depending on the WM we might receive transient focus changes, which will disrupt the Win32 state and make us randomly lose focus. Ignore them instead, when a window is being shown, and wait for WM_STATE to be updated and stable. We will eventually receive a WM_TAKE_FOCUS / FocusIn event *after* a window has been shown. When a window is hidden or minimized, we will receive the FocusOut event during the WM_STATE transition, and can safely handle it in this case, as we should have done all the Win32 side effects and have changed the foreground window already. When there's no window state change pending, the focus change event is unexpected, coming from the user or WM, and we handle it normally. With the planned asynchronous state changes it will become more likely to receive transient focus events, and we need to ignore any focus change that is expected or known to be superseded. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6822

1 0

2025

2024

2023

2022

wine-gitlab