November 2023 - wine-gitlab

[PATCH v3 0/1] MR3668: cmd: fixed command chaining
by Dmitry Sokolov (＠DmitrySokolov) 06 Nov '24

06 Nov '24

Fixed the following code: ```plaintext echo 1. && echo ok || echo failed echo 2. || echo failed && echo --- & echo 3. ``` Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55489 -- v3: cmd: fixed command chaining https://gitlab.winehq.org/wine/wine/-/merge_requests/3668

4 4

[PATCH v19 0/11] MR1180: Make all kernel callbacks go through user32
by Torge Matthies (＠tmatthies) 06 Nov '24

06 Nov '24

Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks. -- v19: include: Add a comment explaining why all kernel callbacks must be in user32. user32: Remove NtUserDriverCallback* kernel callbacks. winex11.drv: Route kernel callbacks through user32. winex11.drv: Pass a struct to x11drv_ime_set_result. winex11.drv: Pass a struct to x11drv_dnd_post_drop. winemac.drv: Route kernel callbacks through user32. wineandroid.drv: Route kernel callbacks through user32. opengl32: Route kernel callbacks through user32. winevulkan: Route kernel callbacks through user32. user32: Add NtUserDispatchCallback kernel callback. user.exe16: Move kernel callbacks to wow_callbacks. https://gitlab.winehq.org/wine/wine/-/merge_requests/1180

3 14

[PATCH v4 0/2] MR3671: cmd: refactored setting of 'errorlevel'
by Dmitry Sokolov (＠DmitrySokolov) 06 Nov '24

06 Nov '24

Encapsulate setting of 'errorlevel' in a separate function as the first stage of fixing bug #32679 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=32679 -- v4: cmd: fixed command chaining https://gitlab.winehq.org/wine/wine/-/merge_requests/3671

5 8

[PATCH 0/3] MR3124: Move periodic registry save out of wineserver
by Paul Gofman (＠gofman) 03 Oct '24

03 Oct '24

The problem is that registry save is a very heavy operation (scheduled each 30sec in wineserver) during which server doesn't process any requests and the whole prefix is stalled for the duration of the operation. For some reference, the process takes from 50-100ms here up to 1-1.5sec with default initial registry (after some registry modifications which trigger actual registry flush), depending on the filesystem type and state (as huge time may be spent in file close / rename). With the same registry after this patchset the server part (flush_key returning the whole registry data) is taking ~4-5mcs, measured from the client side so that already includes data transfer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3124

3 7

[PATCH 0/2] MR3421: win32u: Fix clip_fullscreen_window for Deus Ex
by Zsolt Vadász (＠zsoltiv) 03 Oct '24

03 Oct '24

These changes fix the camera rotation for Deus Ex. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3421

3 7

[PATCH 0/10] MR4201: widl: Cleanup and simplify expressions.
by Rémi Bernon (＠rbernon) 13 Sep '24

13 Sep '24

Some cleanup for expressions, sanitizing the structure a bit especially for abstract operations with multiple args. I also found out about named bison variables, implicit (as `$token` referring to `token`), or explicit (as `$name` referring to `token[name]`). I think it would make the rules much more readable so I started using them here. My plan is to add them progressively to the rules, unless there's some good reason not to (like idk how portable they are, if that's something we should be worried about). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4201

3 21

[PATCH v2 0/1] MR2657: d3d9/tests: test table fog z vs rhw with shaders, depth bias, oDepth..
by Aleksey Komarov (＠q4a) 08 Aug '24

08 Aug '24

General idea of this test is to show that a lot of factors influence the fog when transformed and untransformed vertex format was used: - Directly changing z and w (which is not equal in the corners). - Changing projection matrix that change z and w. - Using different programmable/ff vs/ps shader. - Using different depth bias. - Chaging depth in pixel shader (oDepth) may or may not affect to colors depending on the vendor implementation. - And various combinations of above. This gives `succ` in all cases on this configs: - Windows 10 with Radeon HD 8400 or Ivy Bridge GT1 (Intel HD Graphics). - Windows 7 with Radeon HD 6450. - Windows XP with GeForce Go 7300. -- v2: d3d9/tests: test table fog z vs rhw with shaders, depth bias, oDepth.. https://gitlab.winehq.org/wine/wine/-/merge_requests/2657

8 17

[PATCH 0/1] MR3047: ntdll: hook mmap for force allocate low 32-bit memory on wow64
by Fan WenJie (＠fanwenjie) 26 Jul '24

26 Jul '24

Signed-off-by: Fan WenJie <fanwj(a)mail.ustc.edu.cn> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3047

5 5

[PATCH 0/7] MR3606: winegstreamer: Introduce a new wg_source internal interface.
by Rémi Bernon (＠rbernon) 10 Jul '24

10 Jul '24

This is the first batch of a series implementing faster media source resolution required to workaround an Unreal Engine race condition present in some games, and deterministic stream ordering that decodebin / parsebin cannot provide, which is required to expose the streams in native order, for compatibility in several other applications. I pushed the full series as a branch here: https://gitlab.winehq.org/rbernon/wine/-/commits/mr/wg-source-part-one Note that this full series is also a first step in the direction of having a simpler demuxer interface, which will be required in the future for compatibility with applications that build MF or DirectShow pipelines directly and expect the relevant components to behave as a demuxer and expose compressed media types. For now it only delays the use of wg_parser to whenever the media source is started, and matches the non-ordered streams using their media types and tags. This is a best effort solution but I don't think we can do much better for the moment. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3606

6 29

[PATCH v4 0/2] MR2120: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
by Evan Tang (＠etang-cw) 28 May '24

28 May '24

This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man… Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them? -- v4: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications user32: Add tests for WM_INPUT_DEVICE_CHANGE messages https://gitlab.winehq.org/wine/wine/-/merge_requests/2120

3 4

2025

2024

2023

2022

wine-gitlab November 2023