November 2023 - Wine-GitLab

[PATCH v5 0/6] MR3454: user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION.
by Jinoh Kang (＠iamahuman) Jan. 20, 2024

Jan. 20, 2024

This is required to avoid silencing (potentially fatal) exceptions from timer procedures. -- v5: win32u: Ignore unhandled info index in NtUserSetObjectInformation. win32u/tests: Add tests for NtUserSetObjectInformation. user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION. user32/tests: Add tests for UOI_TIMERPROC_EXCEPTION_SUPPRESSION. include: Add definition for UOI_TIMERPROC_EXCEPTION_SUPPRESSION user32/tests: Make test_unicode_wm_char robust against superfluous messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/3454

2 7

[PATCH 0/4] MR4364: msttsengine: Implement basic functionality.
by Shaun Ren (＠shaunren) Jan. 19, 2024

Jan. 19, 2024

Also introduce the piper TTS library. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4364

5 12

[PATCH v2 0/4] MR2408: winex11: Detect Xkb layouts and create HKL registry keys.
by Rémi Bernon Jan. 18, 2024

Jan. 18, 2024

-- v2: winex11: Create registry keys for known Xkb layouts. winex11: Keep a list of every known Xkb layout. winex11: Read the _XKB_RULES_NAMES root window property. win32u: Init vsc2vk in NtUserGetKeyNameText only if necessary. https://gitlab.winehq.org/wine/wine/-/merge_requests/2408

2 5

[PATCH v2 0/4] MR3024: win32u: Introduce a new rawinput dedicated thread.
by Rémi Bernon Jan. 18, 2024

Jan. 18, 2024

Currently only used to keep rawinput devices updated without iterating the entire list on every change. This thread will then let us solve several problems: * Solve issues with input not being polled if/when applications aren't checking their messages. This removes the need for polling messages in DInput, which is known to confuse and break DOSBOX. * Solve some issues with ll-hook deadlocks between hooking threads and the thread that is currently polling for inputs. * Useful to process internal messages and implement some user driver mechanisms. It can for instance already process WM_WINE_CLIPCURSOR messages, instead of relying on the foreground thread. * Similarly, for cursor icon changes, wineserver can notify it on cursor window changes and request the cursor icon to be updated from the user driver, instead of having to check the window the cursor is located in to change its icon on every mouse move. * Ultimately make it possible to drop the __wine_send_input PE export, the thread can read HID reports from devices that a process has registered for, and send WM_INPUT messages accordingly. This has some drawbacks though, as reading NT devices currently involves much more wineserver roundtrips than `__wine_send_input`. There's evidence that Windows uses a similar thread to process hardware events (as described in https://devblogs.microsoft.com/oldnewthing/20140213-00/?p=1773) although it's probably a system-wide kernel thread. I considered reading X11 input from a per-prefix dedicated thread (for instance in explorer.exe) or dedicated process, but having one thread per-process has several advantages. The rawinput device registration state is done per-process and according to https://gitlab.winehq.org/wine/wine/-/merge_requests/2120 it also needs to post notifications that are process specific. It also keeps the guarantee that each process will read the inputs from the window it has created, and not from some other windows, although the message dispatch may decide to send the message to another process later, it avoids having to listen to input on other processes windows. It can then be seen as an intermediate step towards having a per-prefix thread, if that's something we end up needing. Moving from a per-process thread to a per-prefix thread should be easier. -- v2: win32u: Keep rawinput device list updated using WM_DEVICECHANGE. win32u: Register for device notifications in the rawinput thread. win32u: Introduce a dedicated thread for rawinput processing. ntdll/tests: Use combase instead of comctl32 as a test module. https://gitlab.winehq.org/wine/wine/-/merge_requests/3024

3 8

[PATCH 0/2] MR3264: dinput: Improve keyboard devices scancode support.
by Rémi Bernon Jan. 18, 2024

Jan. 18, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55205 This is not really a bug upstream because of the limited X11 scancode support, but it becomes one with the staging fixed scancode patch which enumerates more keys in the upper scancode range. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3264

1 3

[PATCH 0/1] MR4462: winepath: Don't duplicate the NT path.
by Alex Henrie (＠alexhenrie) Dec. 29, 2023

Dec. 29, 2023

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

2 3

[PATCH v5 0/1] MR3288: gdiplus: Clip polygons before drawing them
by David Kahurani (＠kahurani) Dec. 15, 2023

Dec. 15, 2023

Validate user data before passing it to PolyDraw. The program in the bug requests to draw figures outrageously outside the DC's region after presumably, some uninitialized values happen as a result of a missing font. Native gdiplus seems to handle this gracefully so we probably also should. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41617 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v5: gdiplus: Clip polygons before drawing them https://gitlab.winehq.org/wine/wine/-/merge_requests/3288

3 5

[PATCH v13 0/11] MR1074: Draft: ntdll: Improve Valgrind and GDB integration.
by Rémi Bernon Dec. 13, 2023

Dec. 13, 2023

Valgrind support requires a fork, which I've published to https://gitlab.winehq.org/rbernon/valgrind. The fork implements loading DWARF debug info from PE files, instead of the old and broken upstream PDB support. I've tried to upstream these changes a long time ago but didn't receive any feedback. I think we could maybe consider keeping a fork, which I'm happy to maintain, as the changes aren't too large. We may want to investigate adding 32-on-64 support, which may require a bit more changes (to VEX specifically, because its amd64 guest doesn't support segment register manipulation). The changes here are not all related to Valgrind, and I'll create separate MR for those which may make sense independently from Valgrind / GDB. Also included is a suppression file to silent some annoying false positives, many of which are coming from the cross-stack accesses during syscalls, which are confusing Valgrind's stack heuristics. One can try this out with something like: `WINELOADERNOEXEC=1 valgrind --suppressions=tools/valgrind.supp wine64/loader/wine64 wine64/programs/winecfg/winecfg.exe` -- v13: ntdll: Fix incorrect i386 call_user_mode_callback CFI. ntdll: Avoid marking freed block header as undefined for valgrind. ntdll: Force HEAP_TAIL_CHECKING_ENABLED flag with valgrind. ntdll: Fix valgrind notifications from ntdll.so. ntdll: Import valgrind headers for PE side ntdll. tools: Add gdbunwind.py script with a syscall unwinder. ntdll: Maintain a PE module link map and expose it to GDB. loader: Expose a shadow copy of ld.so link map to GDB. loader: Add rtld_init SystemTap probe to the preloader. configure.ac: Check for systemtap sys/sdt.h header. gitlab: Install systemtap-sdt-dev packages. https://gitlab.winehq.org/wine/wine/-/merge_requests/1074

3 15

[PATCH v7 0/2] MR4545: mf: Fix restarting a paused media session.
by Yuxuan Shui (＠yshui) Dec. 12, 2023

Dec. 12, 2023

-- v7: mf: Only preroll when starting from stopped state. mf/tests: Add test cases for evr events. https://gitlab.winehq.org/wine/wine/-/merge_requests/4545

3 10

[PATCH 0/4] MR473: tests/shader-runner: Run SM1 compilation in the shader runner, part 1.
by Francisco Casas (＠fcasas) Dec. 12, 2023

Dec. 12, 2023

Like the previous MRs, this has the objective of: * Preparing the way for SM1-specific tests. * Running SM1 compilation tests, even if we don't have a runner available to execute them (yet). * Allowing different runners to run through the shader_test file several times, targeting different shader model ranges. The current plan is: * We won't separate compilation tests from execution tests as in !418. * Instead of naming individual shader models in the shader_test files as in !434, we will keep working with the shader model ranges provided in the [require] directives. * We will test SM1 compilation going through the shader_test file twice with the vulkan runner, one for SM1 models and other for SM4 models, and for now we will just give a "todo" for execution tests until they are implemented (@zfigura patches). This first part only includes facilities to properly mark SM1-specific tests (as required by !458) and some refactoring to better work with the idea of intersecting shader model ranges. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/473

5 21