- wine-gitlab - winehq.org

[PATCH v2 0/5] MR7334: oleaut32: Fix logic for deciding whether type description follows the name.
by Dmitry Timoshkov (＠dmitry) 18 Feb '25

18 Feb '25

-- v2: oleaut32: Add support for decoding SLTG variable help strings. oleaut32: Add support for decoding SLTG function help strings. oleaut32: Implement decoding of SLTG help strings. oleaut32: 'typekind' is the last field of SLTG_OtherTypeInfo structure. oleaut32: Fix logic for deciding whether type description follows the name. https://gitlab.winehq.org/wine/wine/-/merge_requests/7334

3 8

Re: [PATCH v6 0/6] MR7174: rtworkq: Fix handling of platform startup and lock counts.
by Nikolay Sivov (＠nsivov) 18 Feb '25

18 Feb '25

On Tue Feb 18 06:30:29 2025 +0000, Conor McCarthy wrote: > No problem to do that if 11 commits are ok. Not a problem for me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7174#note_94986

1 0

[PATCH 0/2] MR7142: win32u: Reset surface clip region if it matches the visible rect.
by Rémi Bernon (＠rbernon) 18 Feb '25

18 Feb '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57665 With an empty clipping region, when the window is being shown, the Expose event we receive is ignored by `expose_window_surface`, assuming there's no redraw necessary. If a clipping region is set, we call `NtUserRedrawWindow` with `RDW_ERASE` which clears the window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7142

2 3

[PATCH 0/1] MR7257: winex11: Get rid of x11drv_win_data use_alpha flag.
by Rémi Bernon (＠rbernon) 18 Feb '25

18 Feb '25

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

2 2

[PATCH v3 0/2] MR7157: winex11: Only erase the desktop window pixels on expose events.
by Rémi Bernon (＠rbernon) 18 Feb '25

18 Feb '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57665 --- The issue is that The Medium launcher uses a dialog window procedure, and implements its background by doing a StretchBlt call on WM_PAINT in the dialog procedure call, which happens before the window message loop. It then itself calls InvalidateRect(hwnd, NULL, 0), which queues a WM_PAINT as well but with only the RDW_INVALIDATE flag. Next, when the window message loop is executed, the WM_PAINT message is being processed as it should, but as we've invalidate the window with RDW_ERASE ourselves from the expose event, the WM_NCPAINT handler erases the entire window, clearing the pixels that the launcher has just painted. This regressed since the window surface clipping region logic changed, as the expose event handling was previously not calling `NtUserRedrawWindow` on windows with a surface and without a clipping region. The clipping region was also previously not always set, or set later, and we're setting it more consistently since 51b16963f6e0e8df43118deac63f640aee4698b7, even when it matches the window rect, for compatibility with some old wineandroid logic (where I believe it was used to clip window surfaces to their proper sizes). -- v3: winex11: Avoid setting RDW_ERASE on expose events. explorer: Paint the desktop even without RDW_ERASE. https://gitlab.winehq.org/wine/wine/-/merge_requests/7157

2 3

[PATCH 0/5] MR7334: oleaut32: Fix logic for deciding whether type description follows the name.
by Dmitry Timoshkov (＠dmitry) 18 Feb '25

18 Feb '25

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

3 7

[PATCH v4 0/5] MR7347: ntdll: Avoid process_attach() even indirectly if loaded with `DONT_RESOLVE_DLL_REFERENCES`
by Jinoh Kang (＠iamahuman) 18 Feb '25

18 Feb '25

This cleans up `LDR_DONT_RESOLVE_REFS` checks in preparation for !7. -- v4: ntdlll: Remove redundant LDR_DONT_RESOLVE_REFS checks before calling process_attach(). ntdll: Skip DLL initialization and ldr notification entirely if DONT_RESOLVE_DLL_REFERENCES is set. kernel32/tests: Test for unexpected loader notification for import dependency loaded with DONT_RESOLVE_DLL_REFERENCES. https://gitlab.winehq.org/wine/wine/-/merge_requests/7347

3 7

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

18 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7353

2 1

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

18 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7352

2 1

[PATCH 0/2] MR7349: win32u, winex11: Sort vulkan devices.
by Paul Gofman (＠gofman) 18 Feb '25

18 Feb '25

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

3 5

Re: [PATCH v16 0/1] MR7322: programs/cmd: Implement ability to abort lengthy directory operations via Ctrl-C. - approved
by eric pouech (＠epo) 18 Feb '25

18 Feb '25

This merge request was approved by eric pouech. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7322

1 0

[PATCH v3 0/2] MR7345: server: Add order for registry value.
by Haoyang Chen (＠chenhaoyang) 18 Feb '25

18 Feb '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=9314 -- v3: server: Store the order for registry value. https://gitlab.winehq.org/wine/wine/-/merge_requests/7345

2 2

[PATCH v2 0/2] MR7345: server: Add order for registry value.
by Haoyang Chen (＠chenhaoyang) 18 Feb '25

18 Feb '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=9314 -- v2: server: Store the order for registry value. https://gitlab.winehq.org/wine/wine/-/merge_requests/7345

2 2

[PATCH 0/1] MR7345: server: Add order for registry value.
by Haoyang Chen (＠chenhaoyang) 18 Feb '25

18 Feb '25

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

3 3

[PATCH 0/1] MR7348: winecoreaudio: Avoid duplicate Program Change or Channel Aftertouch MIDI messages.
by Brendan Shanks (＠bshanks) 18 Feb '25

18 Feb '25

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

3 2

Re: [PATCH v6 0/6] MR7174: rtworkq: Fix handling of platform startup and lock counts.
by Conor McCarthy (＠cmccarthy) 18 Feb '25

18 Feb '25

On Tue Feb 18 06:30:29 2025 +0000, Nikolay Sivov wrote: > I knew I commented on these changes before, but then I found it was > !7244. Could we merge those, or what's the plan? No problem to do that if 11 commits are ok. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7174#note_94962

1 0

[PATCH v5 0/6] MR7174: rtworkq: Fix handling of platform startup and lock counts.
by Conor McCarthy (＠cmccarthy) 18 Feb '25

18 Feb '25

Startup and lock counts in native Windows are separate, and the lock count does not decrease when an async result is freed if the platform has been started. -- v5: rtworkq: Introduce an async result object cache. rtworkq: Introduce a platform startup count. rtworkq/tests: Test work queue. mfplat/tests: Test platform startup and lock counts. mfplat/tests: Test mixing of MF platform functions with their Rtwq equivalents. https://gitlab.winehq.org/wine/wine/-/merge_requests/7174

2 6

[PATCH v3 0/1] MR7339: ntdll: implement create_logical_proc_info on FreeBSD.
by Damjan Jovanovic (＠dj) 18 Feb '25

18 Feb '25

Port the XML parser from dlls/ntdll/actctx.c to ASCII and use it to parse the XML returned from FreeBSD's kern.sched.topology_spec sysctl. -- v3: ntdll: implement create_logical_proc_info on FreeBSD. https://gitlab.winehq.org/wine/wine/-/merge_requests/7339

3 3

[PATCH v2 0/2] MR7342: Implement D3D11_FEATURE_D3D9_SIMPLE_INSTANCING_SUPPORT feature check.
by Zhiyi Zhang (＠zhiyi) 18 Feb '25

18 Feb '25

For React Native. -- v2: d3d11: Implement D3D11_FEATURE_D3D9_SIMPLE_INSTANCING_SUPPORT feature check. https://gitlab.winehq.org/wine/wine/-/merge_requests/7342

2 4

[PATCH v3 0/1] MR7179: wined3d: Add some DXT format mappings in the Vulkan renderer.
by Aida Jonikienė (＠DodoGTA) 18 Feb '25

18 Feb '25

This removes some texture errors when using Himavant. -- v3: wined3d: Add DXT format mappings in the Vulkan renderer. https://gitlab.winehq.org/wine/wine/-/merge_requests/7179

4 4

[PATCH v3 0/5] MR7347: ntdll: Avoid process_attach() even indirectly if loaded with `DONT_RESOLVE_DLL_REFERENCES`
by Jinoh Kang (＠iamahuman) 17 Feb '25

17 Feb '25

This cleans up `LDR_DONT_RESOLVE_REFS` checks in preparation for !7. -- v3: ntdlll: Remove redundant LDR_DONT_RESOLVE_REFS checks before calling process_attach(). ntdll: Skip DLL initialization and ldr notification entirely if DONT_RESOLVE_DLL_REFERENCES is set. kernel32/tests: Test for unexpected loader notification for import dependency loaded with DONT_RESOLVE_DLL_REFERENCES. kernel32/tests: Test for unexpected LDR_PROCESS_ATTACHED flag in import dependency loaded with DONT_RESOLVE_DLL_REFERENCES. kernel32/tests: Add basic tests for internal flags of modules loaded with DONT_RESOLVE_DLL_REFERENCES. https://gitlab.winehq.org/wine/wine/-/merge_requests/7347

2 6

[PATCH 0/5] MR4894: setupapi: implement CM_Locate_DevNode
by Etaash Mathamsetty (＠etaash.mathamsetty) 17 Feb '25

17 Feb '25

This api is used by libxess on intel GPUs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4894

3 8

Re: [PATCH v8 0/2] MR7060: scrrun/tests: Add drive_get_path test
by Quinn Rafferty (＠ramleejo) 17 Feb '25

17 Feb '25

On Wed Jan 1 16:32:32 2025 +0000, Nikolay Sivov wrote: > @alexhenrie is it possible to create a drive without a letter? Regarding > wine supporting only drives with assigned letters, I don't think it > matters that much if it turns out to be easy to return a correct path. > IDrive has separate properties for paths and letters, so maybe there is > a reason for that. My understanding is that the way to query all available drives is via DriveCollection. Due to this I changed the tests to what Alex Henrie suggested as it will properly verify the functionality of the function. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7060#note_94929

1 0

[PATCH v4 0/2] MR7238: winebus,mmdevapi: implement audio device container id
by Harald Sitter (＠sitter) 17 Feb '25

17 Feb '25

This is a bit convoluted because of the amount of pieces involved. I'll try to untangle things a bit. The container id is meant to be globally unique and stable. We therefore need a suitable amount of stable entropy that we can feed into a hash function to get a stable and unique output. This happens in winebus. The corner stone of hash inputs is the linux device topology (sysfs path) obtained via udev. Along with all other possible data we feed this into a hash function to obtain our container id. A bunch of extra wine-specific keys needed to be added to carry the necessary metadata from the driver into the ntoskrnl (where it gets written to the property registry of the relevant device). Separate from this we also ingest the linux device topology (sysfs path) in the winepulse driver. In mmdevapi we then use winepulse's sysfs path to find the matching device in the setupapi and query its container id. We now have the same container id in both the device and the MMDevice, allowing applications (in particular Games) to find the MMDevice for a given device. For practical reasons we always resolve the sysfs path to the root device as early as possible. Container ids are meant to be equal for sub devices inside a "container" anyway. -- v4: containerid: helper to generate a containerid from a sysfs path mmdevapi: correctly read and write containerid as clsid blob https://gitlab.winehq.org/wine/wine/-/merge_requests/7238

2 3

Re: [PATCH v3 0/2] MR7341: shdocvw: Remove two functions. - approved
by Alexandre Julliard (＠julliard) 17 Feb '25

17 Feb '25

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

1 0

2025

2024

2023

2022

wine-gitlab