- wine-gitlab - winehq.org

[PATCH v2 0/9] MR7378: wined3d: NV12 textures, part 2/2.
by Elizabeth Figura (＠zfigura) 27 Feb '25

27 Feb '25

-- v2: d3d11/tests: Extend NV12 tests. wined3d: Implement planar NV12 in the Vulkan renderer. wined3d: Enable KHR_sampler_ycbcr_conversion. wined3d: Implement planar Vulkan blits. wined3d: Implement planar Vulkan downloads. wined3d: Implement planar Vulkan uploads. wined3d: Separate a wined3d_texture_vk_download_plane() helper. wined3d: Separate a wined3d_texture_vk_upload_plane() helper. wined3d: Use a separate format value for d3d10+ NV12. https://gitlab.winehq.org/wine/wine/-/merge_requests/7378

3 11

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

27 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. -- v8: 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

3 6

[PATCH 0/1] MR7434: winex11.drv: Allow MWM_FUNC_MAXIMIZE when WS_MAXIMIZE is present.
by Zhiyi Zhang (＠zhiyi) 27 Feb '25

27 Feb '25

Mutter refuses to maximize a window when MWM_FUNC_MAXIMIZE is not present. However, ShowWindow(SW_MAXIMIZE) on Windows can maximize the window, even without WS_MAXIMIZEBOX. This is similar to 688fe706. Fix Tidy Cauldron (2708320), a Unity game, unable to maximize in some cases. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7434

3 3

[PATCH v3 0/1] MR6780: include: Avoid the for-loop be optimized out
by Ruslan Garipov (＠ruslangaripov) 27 Feb '25

27 Feb '25

This stops GCC from optimizing out a `for` loop inside the `dump_cv_sst_src_module()` function, when tools/winedump is compiled with optimization settings -O1 or higher. Because the `baseSrcLn` field of the `struct OMFSourceFile` was declared as an array of one element **and it is an interior member** of the structure: ```c typedef struct OMFSourceFile { unsigned short cSeg; unsigned short reserved; unsigned int baseSrcLn[1]; unsigned short cFName; char Name; } OMFSourceFile; ``` The compiler/optimizer assumes that the `baseSrcLn` array may have only zero or one element. And generates the corresponding code. The following shows code that GCC 14.2.1 generates before and after this patch. Before patch: ``` 524f: e8 0c ef ff ff call 4160 <printf@plt> # this printf(3)'s "File table: ..." # r15 stores sourceFile->cSeg; assigned above. 5254: 66 41 83 3c 24 00 cmpw $0x0,(%r12) # r12 is sourceFile 525a: 74 22 je 527e <dump_codeview+0x70e> 525c: 4b 8d 44 bc 04 lea 0x4(%r12,%r15,4),%rax #rax is seg_info_dw 5261: 45 8b 44 24 04 mov 0x4(%r12),%r8d # sourceFile->baseSrcLn[0] 5266: be 01 00 00 00 mov $0x1,%esi 526b: 48 8d 3d fe 02 04 00 lea 0x402fe(%rip),%rdi # 45570 5272: 8b 48 04 mov 0x4(%rax),%ecx 5275: 8b 10 mov (%rax),%edx 5277: 31 c0 xor %eax,%eax 5279: e8 e2 ee ff ff call 4160 <printf@plt> 527e: 41 0f b6 06 movzbl (%r14),%eax # eax = sourceModule + ofs ``` The code checks if the `sourceFile->cSeg` is zero or not, and if not it `printf(3)`s information about the first element in the `baseSrcLn` and first offset pair. There is no `for` loop there, only its first iteration. After patch: ``` 525c: e8 ff ee ff ff call 4160 <printf@plt> # this printf(3)'s "File table: ..." # r12 is seg_info_dw and r15 stores integer 1; both assigned above. # r15 is `i' -- the loop counter. 5261: 66 41 83 3e 00 cmpw $0x0,(%r14) # r14 is sourceFile 5266: 74 37 je 529f <dump_codeview+0x72f> 5268: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 526f: 00 5270: 43 8b 54 fc f8 mov -0x8(%r12,%r15,8),%edx 5275: 43 8b 4c fc fc mov -0x4(%r12,%r15,8),%ecx 527a: 44 89 fe mov %r15d,%esi 527d: 31 c0 xor %eax,%eax 527f: 47 8b 04 be mov (%r14,%r15,4),%r8d # sourceFile->baseSrcLn[i] 5283: 48 8d 3d e6 02 04 00 lea 0x402e6(%rip),%rdi # 45570 528a: 49 83 c7 01 add $0x1,%r15 528e: e8 cd ee ff ff call 4160 <printf@plt> 5293: 41 0f b7 06 movzwl (%r14),%eax 5297: 41 8d 57 ff lea -0x1(%r15),%edx 529b: 39 c2 cmp %eax,%edx 529d: 7c d1 jl 5270 <dump_codeview+0x700> 529f: 48 8b 44 24 18 mov 0x18(%rsp),%rax # rax = sourceModule + ofs ``` The `for` loop now is where it should be. [EDITED] 2025-02-12: Fix merge request title. -- v3: include: Avoid the for-loop be optimized out. https://gitlab.winehq.org/wine/wine/-/merge_requests/6780

2 3

[PATCH 0/5] MR7432: mp3dmod: Add future support for Float encoding and fix various discrepancies with Windows
by Brendan McGrath (＠redmcg) 27 Feb '25

27 Feb '25

This MR adds the ability to support float encoding (which will be used by the IMFTransform interface). It also adds tests and addresses a number of small discrepancies discovered between the Wine and native implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7432

2 5

[PATCH v2 0/1] MR7428: wined3d: Use temporary buffer when stretching a surface to itself with cpu blit
by YuriK7 (＠riyu12383) 27 Feb '25

27 Feb '25

Fixes https://bugs.winehq.org/show_bug.cgi?id=57283. I believe some sort of smart two pass stretching is possible instead, but not worth it. [dlls/wined3d/surface.c#L1570](https://gitlab.winehq.org/riyu12383/wine/-/bl… not exactly sure if it's related and should be removed then ? -- v2: wined3d: Use temporary buffer when stretching a surface to itself with cpu blit https://gitlab.winehq.org/wine/wine/-/merge_requests/7428

2 2

[PATCH 0/1] MR7431: po: Update Dutch translation.
by Floris Renaud (＠jkfloris) 26 Feb '25

26 Feb '25

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

2 1

Re: [PATCH v3 0/5] MR7386: d3dx9: Add support for saving surfaces to targa files. - approved
by Alexandre Julliard (＠julliard) 26 Feb '25

26 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7355: wined3d: Handle a NULL "push_constants" buffer in glsl_fragment_pipe_alpha_test_func(). - approved
by Alexandre Julliard (＠julliard) 26 Feb '25

26 Feb '25

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

1 0

Re: [PATCH v2 0/2] MR7427: msxml3/tests: Remove tests that already run for msxml6. - approved
by Alexandre Julliard (＠julliard) 26 Feb '25

26 Feb '25

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

1 0

Re: [PATCH v6 0/5] MR7370: winex11: Pass fullscreen flag to is_window_managed. - approved
by Alexandre Julliard (＠julliard) 26 Feb '25

26 Feb '25

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

1 0

Re: [PATCH v5 0/1] MR7352: winewayland: Update locked pointer position hint. - approved
by Alexandre Julliard (＠julliard) 26 Feb '25

26 Feb '25

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

1 0

[PATCH v5 0/7] MR7152: dxgi: Fix the frame latency waitable implementation.
by Giovanni Mascellani (＠giomasce) 26 Feb '25

26 Feb '25

This is an alternative proposal to !5830. It fixes the same glitches in Horizon Zero Dawn, but attempts to do that by implementing the proper behavior expected from the swapchain. More precisely, it fixes a few mistakes I had made the last time I touched this code, it implements the frame latency waitable with a semaphore instead of an event (as it should be) and at last it uses the frame latency waitable to implement an appropriate wait after presentation when the client didn't request to manage the waitable directly. This implementation is not yet complete, because the semaphore should be released when the frame is presented. Knowing when this is the case would require using `VK_KHR_present_wait`. We currently approximate that with the moment in which the frame is submitted for presentation to Vulkan, which as far as I can tell is good enough. Eventually I'll try to write the proper thing. This MR depends on https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/1343, which has been submitted in the meantime to vkd3d. The vkd3d change is included in the first commit, so this MR is already functional. -- v5: dxgi: Wait on the frame latency semaphore when the client doesn't do it. dxgi: Make the frame latency waitable a semaphore. dxgi: Remove the frame latency fence. dxgi: Directly signal the frame latency fence. dxgi: Do not bias the frame latency fence. dxgi: Set the frame latency even when increasing the frame latency. dxgi: Submit Vulkan presentation as soon as possible. https://gitlab.winehq.org/wine/wine/-/merge_requests/7152

3 10

[PATCH v3 0/7] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 26 Feb '25

26 Feb '25

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB (in affected games). On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- v3: winebus: Get the number of haptic axes from SDL winebus: Support creation of arbitrary number of PID axes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH 0/1] MR7428: wined3d: Use temporary buffer when stretching a surface to itself with cpu blit
by YuriK7 (＠riyu12383) 26 Feb '25

26 Feb '25

Fixes https://bugs.winehq.org/show_bug.cgi?id=57283. I believe some sort of smart two pass stretching is possible, but not worth it. [dlls/wined3d/surface.c#L1570](https://gitlab.winehq.org/riyu12383/wine/-/bl… not exactly sure if it's related and should be removed then ? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7428

3 2

[PATCH v4 0/5] MR5814: d3dx9, d3dcompiler: Do not emit implicit truncation warnings before version 42.
by Elizabeth Figura (＠zfigura) 26 Feb '25

26 Feb '25

-- v4: d3dx9: Link versions 42 and 43 to the corresponding d3dcompiler DLL. d3dx9: Reimplement D3DXCompileShader() for versions before 42. d3dcompiler: Use D3DCompile2VKD3D() from vkd3d-utils. d3dcompiler: Use D3DPreprocess() from vkd3d-utils. https://gitlab.winehq.org/wine/wine/-/merge_requests/5814

3 11

[PATCH v3 0/2] MR7417: mfplat: Modify MFCreateWaveFormatExFromMFMediaType to allow MF_MT_AM_FORMAT_TYPE to be missing or set to GUID_NULL.
by Brendan McGrath (＠redmcg) 26 Feb '25

26 Feb '25

This MR: - adds tests for when MF_MT_AM_FORMAT_TYPE is missing or set to GUID_NULL; and - modifies MFCreateWaveFormatExFromMFMediaType to pass these tests -- v3: mfplat: Allow MF_MT_USER_DATA to be missing for all subtypes. mfplat/tests: Add additional MFCreateWaveFormatExFromMFMediaType tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/7417

2 3

[PATCH v7 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 26 Feb '25

26 Feb '25

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- v7: winegstreamer: Avoid large buffer pushes in wg_transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

2 3

[PATCH 0/1] MR7355: wined3d: Handle a NULL "push_constants" buffer in glsl_fragment_pipe_alpha_test_func().
by Henri Verbeet (＠hverbeet) 26 Feb '25

26 Feb '25

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

4 5

[PATCH v6 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 26 Feb '25

26 Feb '25

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- v6: winegstreamer: Avoid large buffer pushes in wg_transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

2 2

[PATCH v5 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 26 Feb '25

26 Feb '25

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- v5: winegstreamer: Avoid large buffer pushes in wg_transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

3 6

[PATCH v2 0/5] MR7386: d3dx9: Add support for saving surfaces to targa files.
by Connor McAdams (＠cmcadams) 26 Feb '25

26 Feb '25

This patch series adds quite a few new tests for saving to image file formats that aren't DDS, and adds partial support for saving surfaces to targa files. -- v2: d3dx9: Add basic support for saving surfaces to targa files. d3dx9: Add TGA prefix to targa specific defines. d3dx9/tests: Add tests for saving surfaces to non-DDS files. d3dx9/tests: Add a test for saving a surface as D3DXIFF_DIB. d3dx9/tests: Add some more tests for saving surfaces as targa files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7386

3 16

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

26 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. -- v4: winewayland: Implement SetCursorPos via pointer lock. winewayland: Update locked pointer position hint. https://gitlab.winehq.org/wine/wine/-/merge_requests/7353

3 3

Re: [PATCH v3 0/1] MR7323: wininet: Treat Expires value "-1" the same as "0"
by Aida Jonikienė (＠DodoGTA) 26 Feb '25

26 Feb '25

On Wed Feb 26 12:04:41 2025 +0000, Yongjie Yao wrote: > In fact, some HTTP server will send "Expires: -1" in HTTP response header. > You are right, HTTP spec is that invalid value, include "0". > I add a test to test_http_connection() that would send "Expires: -1" in > response header, I get the error log: > ``` > 0024:err:wininet:HTTP_ParseDateAsAsctime unexpected weekday L"-1" > 0024:err:wininet:HTTP_ParseDate unexpected date format L"-1" > ``` > Maybe we should just treat "Expires: -1" as an invalid date format and > ignore it. I mean you should test it on actual Windows -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7323#note_95992

1 0

Re: [PATCH v6 0/4] MR7173: rtworkq: Support putting work on RTWQ_CALLBACK_QUEUE_UNDEFINED.
by Rémi Bernon (＠rbernon) 26 Feb '25

26 Feb '25

Fwiw the tests here are failing on many Windows versions, see https://test.winehq.org/data/patterns.html#rtworkq:rtworkq -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7173#note_95991

1 0

Re: [PATCH v3 0/1] MR7323: wininet: Treat Expires value "-1" the same as "0"
by Yongjie Yao (＠yaoyongjie) 26 Feb '25

26 Feb '25

In fact, some HTTP server will send "Expires: -1" in HTTP response header. You are right, HTTP spec is that invalid value, include "0". I add a test to test_http_connection() that would send "Expires: -1" in response header, I get the error log: ``` 0024:err:wininet:HTTP_ParseDateAsAsctime unexpected weekday L"-1" 0024:err:wininet:HTTP_ParseDate unexpected date format L"-1" ``` Maybe we should just treat "Expires: -1" as an invalid date format and ignore it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7323#note_95990

1 0

[PATCH 0/1] MR6977: apisetschema: Add some Windows 10 API sets.
by Tim Clem (＠tclem) 26 Feb '25

26 Feb '25

Needed for Indiana Jones and the Great Circle. --- The naming of the shellfolders one is not a mistake; they seemed to have named it differently than all the other shell API sets. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6977

3 4

[PATCH v5 0/5] MR7370: winex11: Pass fullscreen flag to is_window_managed.
by Rémi Bernon (＠rbernon) 26 Feb '25

26 Feb '25

Instead of checking for monitor rect. Similar purpose as https://gitlab.winehq.org/wine/wine/-/merge_requests/7362 -- v5: winewayland: Pass fullscreen flag to is_window_managed. winex11: Pass fullscreen flag to is_window_managed. winex11: Check managed window changes in WindowPosChanged. winex11: Request managed/embedded in a new window_set_managed helper. winex11: Initialize window managed flag in create_whole_window. https://gitlab.winehq.org/wine/wine/-/merge_requests/7370

2 6

[PATCH v2 0/2] MR7417: mfplat: Modify MFCreateWaveFormatExFromMFMediaType to allow MF_MT_AM_FORMAT_TYPE to be missing or set to GUID_NULL.
by Brendan McGrath (＠redmcg) 26 Feb '25

26 Feb '25

This MR: - adds tests for when MF_MT_AM_FORMAT_TYPE is missing or set to GUID_NULL; and - modifies MFCreateWaveFormatExFromMFMediaType to pass these tests -- v2: mfplat: Allow MF_MT_AM_FORMAT_TYPE to be missing or set to GUID_NULL. mfplat/tests: Add additional MFCreateWaveFormatExFromMFMediaType tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/7417

2 3

[PATCH v4 0/1] MR7352: winewayland: Update locked pointer position hint.
by Attila Fidan (＠atticf) 26 Feb '25

26 Feb '25

If a surface is being clipped and hides the cursor, drawing its own one, winewayland constrains using a pointer lock and enables Wayland relative motion. If the application decides to stop drawing its own cursor and make the cursor visible, winewayland will disable relative motion and pointer lock, and enable pointer confinement. The user will perceive a pointer jump from the win32/application drawn cursor to where the Wayland pointer is after being unlocked and an absolute motion event is received, because they were desynchronized due to the Wayland one being locked in place. The pointer constraints protocol says this: > If the client is drawing its own cursor, it should update the position > hint to the position of its own cursor. A compositor may use this > information to warp the pointer upon unlock in order to avoid pointer > jumps. So, right before unlocking, make a request for the compositor to warp the pointer to the win32 position on pointer unlock. -- v4: winewayland: Update locked pointer position hint. https://gitlab.winehq.org/wine/wine/-/merge_requests/7352

3 4

[PATCH v4 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 26 Feb '25

26 Feb '25

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- v4: winegstreamer: Avoid large buffer pushes in wg_transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

2 1

[PATCH v3 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 26 Feb '25

26 Feb '25

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- v3: winegstreamer: Avoid large buffer pushes in wg_transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

2 2

Re: [PATCH v2 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 26 Feb '25

26 Feb '25

update: rebased to master and is now using the parser for buffer splitting. i found that holding onto the parser element and manually driving it is too complicated, it also causes the code paths to diverge significantly between the having-a-parser case and the not-having-a-parser case. so instead i added a proxy element which gives me control over how buffers move through the pipeline. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7288#note_95963

1 0

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Stefan Brüns (＠StefanBruens) 26 Feb '25

26 Feb '25

On Tue Feb 25 20:39:47 2025 +0000, Nikolay Sivov wrote: > This isn't about percentage or how common it is. It's not clear this is > the right direction to me, for example groups could contain path > geometries with different filling modes, or other groups. So, what is the behavior you expect? It is clear the behavior is correct when the fill mode is WINDING, or when the rendering does not depend on the fill rule - that also includes overlapping geometries with correct path direction, e.g. paths generated from font outlines. You should provide a way forward, not block it because it is not perfect. It definitely *does* work properly in the majority of cases, the rendering becomes more correct. If you want changes, please be specific. Wine is full of partially incomplete and incorrect implementations, according to your line of thoughts all this should be deleted. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_95959

1 0

Re: [PATCH v4 0/1] MR1060: include: Remove interfaces already define in msxml6.idl
by Nikolay Sivov (＠nsivov) 26 Feb '25

26 Feb '25

On Tue Feb 25 20:02:24 2025 +0000, Elizabeth Figura wrote: > > No, I think it is desirable. I'm going to move some more tests out, to > build with either msxml2.idl or msxml6.idl, and then we'll see what's left. > What's the progress on this? Is this something that could be delegated > to someone else invested in upstreaming wine-staging patches? I sent some more changes in !7427. But sure, we might need to duplicate some things between dlls too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1060#note_95957

1 0

[PATCH 0/2] MR7427: msxml3/tests: Remove tests that already run for msxml6.
by Nikolay Sivov (＠nsivov) 26 Feb '25

26 Feb '25

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

2 2

Re: [PATCH v2 0/1] MR7426: include: Add D3DKMT_WDDM_*_CAPS. - approved
by Alexandre Julliard (＠julliard) 25 Feb '25

25 Feb '25

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

1 0

Re: [PATCH v4 0/4] MR7412: win32u: Use VK_EXT_headless_surface for nulldrv surface. - approved
by Alexandre Julliard (＠julliard) 25 Feb '25

25 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7421: krnl386: Silence a warning in GetSystemDirectory16(). - approved
by Alexandre Julliard (＠julliard) 25 Feb '25

25 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7423: subst: Add basic implementation. - approved
by Alexandre Julliard (＠julliard) 25 Feb '25

25 Feb '25

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

1 0

Re: [PATCH v3 0/4] MR7381: imm32: Move the IME UI window to the bottom at creation. - approved
by Alexandre Julliard (＠julliard) 25 Feb '25

25 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7420: comctl32: Fix Alloc/HeapAlloc mismatches. - approved
by Alexandre Julliard (＠julliard) 25 Feb '25

25 Feb '25

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

1 0

[PATCH 0/2] MR7417: mfplat: Modify MFCreateWaveFormatExFromMFMediaType to allow MF_MT_AM_FORMAT_TYPE to be missing or set to GUID_NULL.
by Brendan McGrath (＠redmcg) 25 Feb '25

25 Feb '25

This MR: - adds tests for when MF_MT_AM_FORMAT_TYPE is missing or set to GUID_NULL; and - modifies MFCreateWaveFormatExFromMFMediaType to pass these tests -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7417

3 7

[PATCH 0/1] MR4662: properly track refcount and dependencies with forwarded exports.
by YUAN RUI (＠number201724) 25 Feb '25

25 Feb '25

fix: https://bugs.winehq.org/show_bug.cgi?id=52094 tests: ``` #include <Windows.h> #ifdef FROM_IMPORT #pragma comment(lib, "python3.lib") extern "C" int Py_IsInitialized(); #endif int main() { #ifdef FROM_IMPORT // test from import table Py_IsInitialized( ); #else // //Test ref count int (*Py_IsInitialized)(); HMODULE hmod_310 = LoadLibraryA( "C:\\Python310\\python310.dll" ); HMODULE hmod = LoadLibraryA( "C:\\Python310\\python3.dll" ); if ( !hmod ) return 0; *(FARPROC*)&Py_IsInitialized = GetProcAddress( hmod, "Py_IsInitialized" ); FreeLibrary( hmod_310 ); Py_IsInitialized( ); FreeLibrary( hmod ); // test dependencies hmod = LoadLibraryA( "C:\\Python310\\python3.dll" ); if ( !hmod ) return 0; *(FARPROC*)&Py_IsInitialized = GetProcAddress( hmod, "Py_IsInitialized" ); Py_IsInitialized(); FreeLibrary( hmod ); #endif return 0; } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4662

5 5

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Nikolay Sivov (＠nsivov) 25 Feb '25

25 Feb '25

On Tue Feb 25 20:23:00 2025 +0000, Stefan Brüns wrote: > @d1saster - Maybe you could extend the test so all 4 cases (2 fill > modes, intersecting/non-intersecting) are tested (marking the > ALTERNATE-intersecting one as known-fail). This isn't about percentage or how common it is. It's not clear this is the right direction to me, for example groups could contain path geometries with different filling modes, or other groups. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_95936

1 0

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Nikolay Sivov (＠nsivov) 25 Feb '25

25 Feb '25

This is included in wine-staging now, you could use that for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_95935

1 0

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

25 Feb '25

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

5 9

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Stefan Brüns (＠StefanBruens) 25 Feb '25

25 Feb '25

On Tue Feb 25 20:20:12 2025 +0000, Stefan Brüns wrote: > I think the current implementation is only incorrect when the fill mode > is D2D1_FILL_MODE_ALTERNATE (0) (aka Even-Odd), but correct for > D2D1_FILL_MODE_WINDING (1). More specifically, when the fill mode is > ALTERNATE *and* there are intersections - for all of the other three > cases (WINDING with and without intersections, ALTERNATE without), it is correct. > According to my experience, even-odd fill mode is quite uncommon. Having > an implementation which is correct 99% of the time in real-world usage, > and leaving the remainder with an explicit, verbose FIXME is an > definitive improvement. Today, the result is always incorrect. @d1saster - Maybe you could extend the test so all 4 cases (2 fill modes, intersecting/non-intersecting) are tested (marking the ALTERNATE-intersecting one as known-fail). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_95932

1 0

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Stefan Brüns (＠StefanBruens) 25 Feb '25

25 Feb '25

On Sat Sep 28 19:59:05 2024 +0000, Nikolay Sivov wrote: > It wouldn't consider it sufficient, it's clear that there is more to it > than copying data from individual geometries. So the question is the > same - what needs to be done to make it work properly, once it's > understood, we could implement it partially if it's too hard to do properly. I think the current implementation is only incorrect when the fill mode is D2D1_FILL_MODE_ALTERNATE (0) (aka Even-Odd), but correct for D2D1_FILL_MODE_WINDING (1). More specifically, when the fill mode is ALTERNATE *and* there are intersections - for all of the other three cases (WINDING with and without intersections, ALTERNATE without), it is correct. According to my experience, even-odd fill mode is quite uncommon. Having an implementation which is correct 99% of the time in real-world usage, and leaving the remainder with an explicit, verbose FIXME is an definitive improvement. Today, the result is always incorrect. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_95931

1 0

[PATCH v9 0/1] MR3096: ntdll: Add NtGetNextProcess stub.
by Alex Henrie (＠alexhenrie) 25 Feb '25

25 Feb '25

The stub is enough for TokenViewer.exe to start up and display its user interface. Based on a patch by Nikolay Sivov. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45119 -- v9: ntdll: Add NtGetNextProcess stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/3096

2 3

[PATCH v4 0/5] MR7370: winex11: Pass fullscreen flag to is_window_managed.
by Rémi Bernon (＠rbernon) 25 Feb '25

25 Feb '25

Instead of checking for monitor rect. Similar purpose as https://gitlab.winehq.org/wine/wine/-/merge_requests/7362 -- v4: winewayland: Pass fullscreen flag to is_window_managed. winex11: Pass fullscreen flag to is_window_managed. winex11: Check managed window changes in WindowPosChanged. winex11: Request managed/embedded in a new window_set_managed helper. winex11: Initialize window managed flag in create_whole_window. https://gitlab.winehq.org/wine/wine/-/merge_requests/7370

3 7

[PATCH v5 0/4] MR6855: server: Fix renaming file to a hardlink of itself.
by Gabriel Ivăncescu (＠insn) 25 Feb '25

25 Feb '25

-- v5: server: When renaming, only fstat the source once. server: Handle hardlinks and casefolding when renaming the same file. kernel32/tests: Test renaming a file into a hardlink of itself. kernel32/tests: Use FindClose instead of CloseHandle when closing https://gitlab.winehq.org/wine/wine/-/merge_requests/6855

4 9

Re: [PATCH v4 0/1] MR1060: include: Remove interfaces already define in msxml6.idl
by Elizabeth Figura (＠zfigura) 25 Feb '25

25 Feb '25

> No, I think it is desirable. I'm going to move some more tests out, to build with either msxml2.idl or msxml6.idl, and then we'll see what's left. What's the progress on this? Is this something that could be delegated to someone else invested in upstreaming wine-staging patches? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1060#note_95923

1 0

[PATCH 0/1] MR7426: include: Add D3DKMT_WDDM_*_CAPS.
by Brendan Shanks (＠bshanks) 25 Feb '25

25 Feb '25

These structs are in the [Windows SDK](https://www.nuget.org/packages/Microsoft.Windows.SDK.CPP), and on MSDN. They are used in downstream patches like https://github.com/ValveSoftware/wine/commit/15c0fcd0ab4d, and sometimes in user-space libraries/applications. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7426

2 1

[PATCH v3 0/8] MR7424: winebth.sys part 5: Update properties for tracked remote devices.
by Vibhav Pant (＠vibhavp) 25 Feb '25

25 Feb '25

This fadds to the basic infrastructure needed for device inquiry/scanning. Also, fixes radio properties being incorrectly updated. -- v3: winebth.sys: Set the device class for remote devices from BlueZ's "Class" property. winebth.sys: Use the "Trusted" property from BlueZ device objects to set BDIF_PERSONAL. winebth.sys: Use the "Name" property of a BlueZ adapter for the local radio name. winebth.sys: Don't iterate over the remaining radios once a local device has been removed. winebth.sys: Initially set numOfDevices to 0 in IOCTL_BTH_GET_DEVICE_INFO. winebth.sys: Use the correct DBus property name in IOCTL_WINEBTH_RADIO_SET_FLAG. winebth.sys: Update properties for tracked remote devices on receiving PropertiesChanged for org.bluez.Device1 objects from BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/7424

2 9

[PATCH v3 0/4] MR7406: winebth.sys: Minor fixes related to device/radio properties.
by Vibhav Pant (＠vibhavp) 25 Feb '25

25 Feb '25

-- v3: winebth.sys: Don't iterate over the remaining radios once a local device has been removed. winebth.sys: Initially set numOfDevices to 0 in IOCTL_BTH_GET_DEVICE_INFO. winebth.sys: Use the correct DBus property name in IOCTL_WINEBTH_RADIO_SET_FLAG. winebth.sys: Only set the updated properties for local radios on BLUETOOTH_WATCHER_EVENT_TYPE_RADIO_PROPERTIES_CHANGED. https://gitlab.winehq.org/wine/wine/-/merge_requests/7406

2 6

[PATCH 0/8] MR7424: winebth.sys part 5: Update properties for tracked remote devices.
by Vibhav Pant (＠vibhavp) 25 Feb '25

25 Feb '25

This adds to the basic infrastructure needed for adding support for device inquiry/scanning. Also, fixes radio properties being incorrectly updated. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7424

2 8

[PATCH v6 0/1] MR7374: wine.inf: Add VC runtime version key.
by Bernhard Kölbl (＠besentv) 25 Feb '25

25 Feb '25

The Unreal engine bootstrapper relies on this to detect VC presence since version 5.3. -- v6: wine.inf: Add VC runtime version key. https://gitlab.winehq.org/wine/wine/-/merge_requests/7374

3 3

[PATCH v3 0/4] MR7412: win32u: Use VK_EXT_headless_surface for nulldrv surface.
by Rémi Bernon (＠rbernon) 25 Feb '25

25 Feb '25

Allows running more tests with nulldrv, including some D3D tests with vulkan renderer. -- v3: win32u: Use VK_EXT_headless_surface for nulldrv surface. win32u: Pass a vulkan_instance pointer to vulkan_surface_create. winevulkan: Enable the VK_EXT_headless_surface extension. winevulkan: Generate function pointers for required funcs. https://gitlab.winehq.org/wine/wine/-/merge_requests/7412

3 5

[PATCH v12 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by Joe Souza (＠JoeS209) 25 Feb '25

25 Feb '25

Current code requires entering a newline character in order to continue past DIR /P prompts. This change allows any key to be pressed instead. Code to handle this was similar to existing WCMD_pause() so we leveraged that code for this purpose as well. Key to the fix was the removal of ENABLE_LINE_INPUT from the console flags, and ENABLE_PROCESSED_INPUT was added in order to preserve the ability to abort the operation via Ctrl-C. -- v12: cmd: Allow any key to continue past DIR /P pauses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7400

2 2

[PATCH 0/1] MR7288: winegstreamer: Avoid large buffer pushes in wg_transform.
by Yuxuan Shui (＠yshui) 25 Feb '25

25 Feb '25

## Context This is a problem discovered when running "Max: The Curse of Brotherhood" under proton. This game writes 4MB a piece into `wg_transform`, which contains about 4 seconds of compressed video. `wg_transform` calls `gst_pad_push` in `transform_ProcessOutput`, which takes \~300ms (i.e. 20 frames @ 60fps) to decode this buffer of video. So the end result is the game hitches every 4 seconds while playing cut scene videos. Proton currently has a special case for this particular game, for which it breaks up the buffer into small chunks to avoid long blocks. This MR adopts that and applies it generally. One concern raised by @redmcg is: > The only issue I can think of is if there are any decoders which don't have a parser; then they might not know how to deal with an arbitrary 4096 byte buffer (the parser is generally responsible for taking arbitrary buffers and producing something the decoder can work with, for example: a full frame). So this MR only enables this strategy when there is a parser element. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7288

5 14

[PATCH 0/1] MR7418: wininet: Treat Expires value "-1" the same as "0"
by Yongjie Yao (＠yaoyongjie) 25 Feb '25

25 Feb '25

In iis server, use -1 to specify immediate expiration. For detailed documentation, please refer to: https://learn.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525906(v=… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7418

4 7

Re: [PATCH v3 0/1] MR7323: wininet: Treat Expires value "-1" the same as "0"
by Jacek Caban (＠jacek) 25 Feb '25

25 Feb '25

I can see that you quoted MSDN page in the other MR, but it's not clear to me if it's relevant. It mentions some IIS APIs, not how HTTP headers look like. I guess adding a test to `test_http_connection()` that would send "-1" "Expires" header and querying `INTERNET_OPTION_CACHE_TIMESTAMPS` on the result would tell us how it works. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7323#note_95883

1 0

[PATCH v2 0/2] MR7412: win32u: Use VK_EXT_headless_surface for nulldrv surface.
by Rémi Bernon (＠rbernon) 25 Feb '25

25 Feb '25

Allows running more tests with nulldrv, including some D3D tests with vulkan renderer. -- v2: win32u: Use VK_EXT_headless_surface for nulldrv surface. winevulkan: Enable VK_EXT_headless_surface extension. https://gitlab.winehq.org/wine/wine/-/merge_requests/7412

3 9

Re: [PATCH v3 0/1] MR7323: wininet: Treat Expires value "-1" the same as "0"
by Jacek Caban (＠jacek) 25 Feb '25

25 Feb '25

It's not clear to me what we should do in case of "-1". My understanding of HTTP spec is that it's invalid, which would suggest that failing to parse is the right thing to do. Does it break some application? If it does, maybe it expects ETag to be used and "Expires" header to be ignored? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7323#note_95881

1 0

[PATCH 0/1] MR7419: wininet: Fix crash when connection is null in NETCON_secure_connect
by Yongjie Yao (＠yaoyongjie) 25 Feb '25

25 Feb '25

There will be crashed when connect is null, so we need avoid crash by checking connect value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7419

3 2

Re: [PATCH v2 0/7] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 25 Feb '25

25 Feb '25

I'm trying to change the static arrays of axis usages in `hid_device_add_physical()` into a `for` loop + a new function based on the current `hid_report_descriptor_append_usage()` but had some issues. I'll update the MR when I get it to work. Seems like a better idea if the `PID_AXIS_MAX` was ever to change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7422#note_95872

1 0

Re: [PATCH v2 0/4] MR7272: wined3d: NV12 textures, part 1/2.
by Nikolay Sivov (＠nsivov) 25 Feb '25

25 Feb '25

On Tue Feb 25 12:14:29 2025 +0000, Rémi Bernon wrote: > Fwiw 4caa93a369b51a9bd8922a3f2cdd02a632b52543 broke the evr tests. According to bisect it was 6bc747b78c46883c82770ea876facb7d27a1cb4e. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7272#note_95871

1 0

[PATCH 0/1] MR7423: subst: Add basic implementation.
by Hans Leidekker (＠hans) 25 Feb '25

25 Feb '25

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

2 1

[PATCH 0/7] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 25 Feb '25

25 Feb '25

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB. On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 7

[PATCH v5 0/1] MR5658: winevulkan: Make device memory wrapper available in callbacks.
by Arek Hiler (＠ivyl) 25 Feb '25

25 Feb '25

With [`VK_EXT_device_address_binding_report`](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_device_address_binding_report.html) we can get [debug_util](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/ht… callbacks used to track memory bindings. Since it's the host's implementation that starts the callback we have to be sure that we have a way of converting it to the client side's variant before it's added to the handle map - i.e. we don't know the host handle at that time yet. This is [used by vkd3d-proton](https://github.com/HansKristian-Work/vkd3d-proton/pull/1962). Requires Mesa with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28649 (24.3 is modern enough to have it). before (note the missing BIND for VkDevice which actually means `VkDeviceMemory`): ``` vkd3d-proton % WINEDLLOVERRIDES="d3d12=n;d3d12core=n" \ VKD3D_TEST_FILTER=create_placed_resource_size \ VKD3D_CONFIG=fault VKD3D_DEBUG=trace \ ~/build/wine/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800101600000 || size 000000000019a000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800101600000 || size 000000000019a000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800101600000 || size 0000000001000000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 6669.627:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800101600000 || size 0000000001000000 ``` after: ``` vkd3d-proton % WINEDLLOVERRIDES="d3d12=n;d3d12core=n" \ VKD3D_TEST_FILTER=create_placed_resource_size \ VKD3D_CONFIG=fault VKD3D_DEBUG=trace \ ~/build/wine/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800101600000 || size 000000000019a000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800101600000 || size 000000000019a000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800101600000 || size 0000000001000000. 4015.597:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800101600000 || size 0000000001000000. ``` [The spec guarantees](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/v… the following: > An application can receive multiple callbacks if multiple VkDebugUtilsMessengerEXT objects are created. A callback will always be executed in the same thread as the originating Vulkan call. -- v5: winevulkan: Make device memory wrapper available in callbacks. https://gitlab.winehq.org/wine/wine/-/merge_requests/5658

2 1

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

25 Feb '25

On Tue Feb 25 08:50:37 2025 +0000, Joe Souza wrote: > Hmm. The changes in this merge request should affect only Ctrl-C at a > /P pause. Otherwise should behave the same. I will look at this later > today. Thanks. sorry, my post wasn't 100% clear: * run cmd with full blown console (./wine wineconsole cmd) * run 'dir /p /s \\\*' * pressing any key works (and pages output) * but ctrl-c doesn't stop dir /p as it should -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_95858

1 0

[PATCH 0/1] MR7420: comctl32: Fix Alloc/HeapAlloc mismatches.
by Haoyang Chen (＠chenhaoyang) 25 Feb '25

25 Feb '25

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

3 2

[PATCH v8 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by Joe Souza (＠JoeS209) 25 Feb '25

25 Feb '25

Current code requires entering a newline character in order to continue past DIR /P prompts. This change allows any key to be pressed instead. Code to handle this was similar to existing WCMD_pause() so we leveraged that code for this purpose as well. Key to the fix was the removal of ENABLE_LINE_INPUT from the console flags, and ENABLE_PROCESSED_INPUT was added in order to preserve the ability to abort the operation via Ctrl-C. -- v8: cmd: Allow any key to continue past DIR /P pauses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7400

3 4

[PATCH 0/1] MR7421: krnl386: Silence a warning in GetSystemDirectory16().
by Arek Hiler (＠ivyl) 25 Feb '25

25 Feb '25

``` With GCC 14.2 on Debian 11: $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The following error happens: In file included from ~/src/wine/dlls/krnl386.exe16/file.c:33: In function 'lstrcpyA', inlined from 'GetSystemDirectory16' at ~/src/wine/dlls/krnl386.exe16/file.c:648:9, inlined from 'get_search_path' at ~/src/wine/dlls/krnl386.exe16/file.c:192:12: ~/src/wine/include/winbase.h:2939:12: error: argument 1 null where non-null expected [-Werror=nonnull] 2939 | return strcpy( dst, src ); | ^~~~~~~~~~~~~~~~~~ In file included from ~/src/wine/dlls/krnl386.exe16/file.c:28: ~/src/wine/include/msvcrt/string.h: In function 'get_search_path': ~/src/wine/include/msvcrt/string.h:53:26: note: in a call to function 'strcpy' declared 'nonnull' 53 | _ACRTIMP char* __cdecl strcpy(char*,const char*); | ^~~~~~ In function 'lstrcatA', inlined from 'GetSystemDirectory16' at ~/src/wine/dlls/krnl386.exe16/file.c:649:9, inlined from 'get_search_path' at ~/src/wine/dlls/krnl386.exe16/file.c:192:12: ~/src/wine/include/winbase.h:2952:12: error: argument 1 null where non-null expected [-Werror=nonnull] 2952 | return strcat( dst, src ); | ^~~~~~~~~~~~~~~~~~ ~/src/wine/include/winbase.h:2952:12: note: in a call to built-in function '__builtin_strlen' (built using --with-mingw and --enable-werror to turn it into an error) The warning doesn't really matter as get_search_path() calls GetSystemDirectory16(NULL, 0) to get the size for allocation. `if (count >= len)` in the latter saves us from ever atempting to strcpy() onto NULL, but the compiler is not smart enough to figure out that len will be greater than 0. This change mimics kernel32's GetSystemDirectoryW(). ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7421

2 1

[PATCH v2 0/1] MR7410: test-linux32: Disable broken tests that are already released broken
by Damien Zammit (＠zamaudio) 25 Feb '25

25 Feb '25

This should allow the CI to fully pass on this merge request. If it does, master branch could have CI tests enabled to ensure any actual broken test caused by a merge request is visible just by the CI status, and master can also reflect the passing status. Signed-off-by: Damien Zammit <damien(a)zamaudio.com> -- v2: test-linux32: Disable broken tests that are already released broken https://gitlab.winehq.org/wine/wine/-/merge_requests/7410

3 3

[PATCH 0/1] MR7323: wininet: Treat Expires value "-1" the same as "0"
by Yongjie Yao (＠yaoyongjie) 25 Feb '25

25 Feb '25

fix "err:wininet:HTTP_ParseDateAsAsctime unexpected weekday L"-1"" -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7323

2 2

[PATCH v7 0/2] MR7324: Use Microsoft provided coefficients for YUV to RGB conversion.
by Brendan McGrath (＠redmcg) 25 Feb '25

25 Feb '25

The current YUV to RGB conversion provides values in studio-range [16-235], but full-range is required [0-255]. As a result, we currently write the value of 16 to represent black, and so we get gray instead. This MR changes the coefficients used in the conversion so that the resultant output is in full-range. It actually uses two sets of coefficients as these differ between SD and HD. Also included is a number of Direct Draw 7 tests. The coefficients used are documented here: https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-… -- v7: wined3d: Use Microsoft provided coefficients for YUV to RGB conversion. ddraw/tests: Test yuv to rgb blt in ddraw7. https://gitlab.winehq.org/wine/wine/-/merge_requests/7324

2 4

[PATCH v2 0/4] MR7381: imm32: Move the IME UI window to the bottom at creation.
by Zhiyi Zhang (＠zhiyi) 25 Feb '25

25 Feb '25

Tidy Cauldron (2708320), a Unity game, uses EnumWindows() to find the first window in the current thread and maximizes the window when changing to windowed mode. However, before this patch, the IME UI window and the DXGI fallback device window are on top of the game window at creation and thus they could get maximized instead. This causes the game window to lose focus and freeze. -- v2: dxgi: Move the fallback device window to the bottom at creation. d3d11/tests: Test that the fallback device window shouldn't be above normal windows at creation. imm32: Move the IME UI window to the bottom at creation. imm32/tests: Test that the IME UI window shouldn't be above normal windows at creation. https://gitlab.winehq.org/wine/wine/-/merge_requests/7381

4 7

Re: [PATCH v4 0/1] MR7221: ieframe: Add IShellWindows stub implementation.
by Helix Graziani (＠TornadoCookie) 24 Feb '25

24 Feb '25

On Tue Feb 4 14:36:04 2025 +0000, Jacek Caban wrote: > I think it's because we register it in a wrong way, see > `HKEY_CLASSES_ROOT\CLSID\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}`. On > Wine, it contains `InprocServer32` key, while on Windows it uses > `LocalServer32`. We should probably remove `threading()` attribute from > `ShellWindows` coclass in `exdisp.idl` and have `.rgs` file in shell > registering it manually. Interesting. I'll try using the values from Windows and seeing what it does. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7221#note_95821

1 0

Re: [PATCH v3 0/7] MR7409: mp3dmod: Implement GetInputCurrentType and GetOutputCurrentType - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7404: makecab: Add stub program. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7414: programs/cmd: Open file in 'TYPE' with more sharing attributes. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v2 0/3] MR7415: findstr should default to regex search. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7399: winex11.drv: Weaken filter_event conditions for some events. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7401: comctl32/tests: Skip a few tests in non-english locale. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v3 0/1] MR7413: wbemprox: Add support for Win32_PhysicalMemoryArray. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v2 0/1] MR7405: dwrite: Fix spelling for Sundanese. - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v6 0/2] MR4611: ntdll: implement NtGetNextProcess - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

Re: [PATCH v3 0/5] MR3747: kernelbase: Implement DeriveCapabilitySidsFromName(). - approved
by Alexandre Julliard (＠julliard) 24 Feb '25

24 Feb '25

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

1 0

[PATCH v2 0/5] MR3747: kernelbase: Implement DeriveCapabilitySidsFromName().
by Paul Gofman (＠gofman) 24 Feb '25

24 Feb '25

CEF sometimes uses that during sandbox initialization. -- v2: kernelbase/tests: Add test for DeriveCapabilitySidsFromName(). kernelbase: Implement DeriveCapabilitySidsFromName(). ntdll: Implement RtlDeriveCapabilitySidsFromName(). ntdll/tests: Add tests for RtlDeriveCapabilitySidsFromName(). ntdll: Add stub for RtlDeriveCapabilitySidsFromName(). https://gitlab.winehq.org/wine/wine/-/merge_requests/3747

2 5

[PATCH v2 0/7] MR7409: mp3dmod: Implement GetInputCurrentType and GetOutputCurrentType
by Brendan McGrath (＠redmcg) 24 Feb '25

24 Feb '25

This MR implements the following APIs in `mp3dmod`: - `GetInputCurrentType` - `GetOutputCurrentType` It also adds checks to various APIs for an invalid stream and fixes a potential resource leak in `SetOutputType`. This is in preparation for adding an `IMFTransform` interface to the MP3 decoder as detailed here: https://learn.microsoft.com/en-us/windows/win32/medfound/windows-media-mp3-… -- v2: mp3dmod: Fix leak of previous outtype. mp3dmod: Implement GetOutputCurrentType. mp3dmod: Implement GetInputCurrentType. https://gitlab.winehq.org/wine/wine/-/merge_requests/7409

2 8

[PATCH v3 0/5] MR5814: d3dx9, d3dcompiler: Do not emit implicit truncation warnings before version 42.
by Elizabeth Figura (＠zfigura) 24 Feb '25

24 Feb '25

-- v3: d3dx9: Link versions 42 and 43 to the corresponding d3dcompiler DLL. d3dx9: Reimplement D3DXCompileShader() for versions before 42. d3dcompiler: Use D3DCompile2VKD3D() from vkd3d-utils. d3dcompiler: Use D3DPreprocess() from vkd3d-utils. vkd3d: Import vkd3d-utils. https://gitlab.winehq.org/wine/wine/-/merge_requests/5814

2 6

[PATCH 0/3] MR7415: findstr should default to regex search.
by eric pouech (＠epo) 24 Feb '25

24 Feb '25

Our findstr implementation defaults to textual search, while native defaults to regex. So this MR: - add tests to show that, - reverts the default, - adapt tests that were written with textual search in mind to pass textual search option Note: native fails when passing the two flags ('findstr /l /r...'). I didn't bother fixing our implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7415

3 4

[PATCH 0/2] MR7412: win32u: Use VK_EXT_headless_surface for nulldrv surface.
by Rémi Bernon (＠rbernon) 24 Feb '25

24 Feb '25

Allows running more tests with nulldrv, including some D3D tests with vulkan renderer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7412

3 5

[PATCH 0/1] MR7414: programs/cmd: Open file in 'TYPE' with more sharing attributes.
by eric pouech (＠epo) 24 Feb '25

24 Feb '25

Triggered by Chromium unit tests. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7414

2 1

[PATCH v3 0/1] MR7352: winewayland: Request warp to win32 position on pointer unlock.
by Attila Fidan (＠atticf) 24 Feb '25

24 Feb '25

If a surface is being clipped and hides the cursor, drawing its own one, winewayland constrains using a pointer lock and enables Wayland relative motion. If the application decides to stop drawing its own cursor and make the cursor visible, winewayland will disable relative motion and pointer lock, and enable pointer confinement. The user will perceive a pointer jump from the win32/application drawn cursor to where the Wayland pointer is after being unlocked and an absolute motion event is received, because they were desynchronized due to the Wayland one being locked in place. The pointer constraints protocol says this: > If the client is drawing its own cursor, it should update the position > hint to the position of its own cursor. A compositor may use this > information to warp the pointer upon unlock in order to avoid pointer > jumps. So, right before unlocking, make a request for the compositor to warp the pointer to the win32 position on pointer unlock. -- v3: winewayland: Update locked pointer position hint. https://gitlab.winehq.org/wine/wine/-/merge_requests/7352

3 4

[PATCH v2 0/1] MR7413: wbemprox: Add support for Win32_PhysicalMemoryArray.
by Dmitry Timoshkov (＠dmitry) 24 Feb '25

24 Feb '25

-- v2: wbemprox: Add support for Win32_PhysicalMemoryArray. https://gitlab.winehq.org/wine/wine/-/merge_requests/7413

3 2

[PATCH 0/8] MR7402: comctl32: Implement IAccessible methods.
by Esme Povirk (＠madewokherd) 24 Feb '25

24 Feb '25

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

3 11

[PATCH v2 0/3] MR7406: winebth.sys: Minor fixes for setting radio properties.
by Vibhav Pant (＠vibhavp) 24 Feb '25

24 Feb '25

-- v2: winebth.sys: Initially set numOfDevices to 0 in IOCTL_BTH_GET_DEVICE_INFO. https://gitlab.winehq.org/wine/wine/-/merge_requests/7406

2 3

2025

2024

2023

2022

wine-gitlab