- wine-gitlab - winehq.org

Re: [PATCH v5 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Rémi Bernon (＠rbernon) 14 Nov '25

14 Nov '25

Rémi Bernon (@rbernon) commented about dlls/winex11.drv/clipboard.c: > + > + if (xevent->type == PropertyNotify && > + xevent->xproperty.window == xwindow && > + xevent->xproperty.atom == x11drv_atom(__wine_timestamp_prop)) > + return True; > + > + return False; > +} > + > + > +/************************************************************************** > + * get_server_time > + * > + * Get the current X11 server timestamp by generating a PropertyNotify event > + */ > +static Time get_server_time( Display *display, Window win ) This looks complicated and we probably don't want to touch the X11 event queue outside of ProcessEvents. There's already `EVENT_x11_time_to_win32_time` which estimates the X server time, and it is used in `set_input_focus` for the same kind of purpose as you need here. It might not be very accurate though, and if you need it to be, maybe it would be better to find a way to detect remote vs local X server and check / assume that a local server uses `clock_gettime` / `CLOCK_MONOTONIC` for its time which I believe most if not all implementations do (or some other clock, I'm not 100% confident). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121992

1 0

[PATCH v5 0/5] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) 14 Nov '25

14 Nov '25

Follow-up to !8184. This also adds a bunch of helpers for writing media source tests (without involving the mf session) in mfsrcsnk, these could be helpful for more tests of this kind in the future. I'm somewhat unsure as to why we haven't done tests for source behavior so far: while those are plugins, applications rely on a bunch of things in the builtin sources that microsoft provides. Since this affects both mfsrcsnk and winegstreamer sources, tests should be run both with `HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler` enabled and disabled. Due to this I figured it'd make sense to implement everything first and then remove the test todo_wine's and the statements rejecting the thin parameter in a single commit ("Allow thinning"). Perhaps this could be solved more nicely by setting the registry key in the tests themselves? I'm unsure if that is something we do in tests, generally. `MEStreamThinMode` events need to be emitted between the last sample using the outdated thinning parameter and the first sample using the updated thinning parameter. The winegstreamer implementation for this turned out a bit complex, if there is a simpler way to do this please let me know. Regarding winegstreamer, note that buffers need to be intercepted before the decoder because decoders often discard `GST_BUFFER_FLAG_DELTA_UNIT` flags (which is already annoying in itself - it causes all samples to be marked as `MFSampleExtension_CleanPoint`, this should potentially be worked around in the future). But even besides that, intercepting before the decoder is the "proper" implementation, since the point of thinning is increasing decoding speed by skipping delta frames, tho there are some games that rely on the semantics as well. -- v5: mfsrcsnk: Emit MEStreamThinMode event. mfsrcsnk: Move media_source_send_sample. mfsrcsnk: Implement thinning. winedmo: Fall back to dts for sample time if pts is not present. https://gitlab.winehq.org/wine/wine/-/merge_requests/8505

3 9

[PATCH v44 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) 14 Nov '25

14 Nov '25

Follow-up of !2786, which appears to have been abandoned. Depends on !8182, !8575, !8578 # Execute minimal test case 1. checkout wine into \~/src/wine 2. in dlls/ws2_32/tests/sock.c wrap all calls to test functions after `Init()` until `test_afunix()` with #if 0 ... #endif 3. build into \~/src/wine-build 4. run `(cd ~/src/wine-build; WINEPREFIX=~/src/wine/.wine ../wine/tools/runtest -q -P wine -T . -M ws2_32.dll -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock)` # How to debug wineserver Since `wineserver` runs in the background, simple calls to printf() will show nothing when the test case is executed. A workaround is to open a file and call fprintf() to write debug messages to this file, which can then be inspected. # How to debug a wine test case At https://gitlab.winehq.org/wine/wine/-/blob/master/tools/runtest#L151 there is mentioned a environment variable name `WINETEST_WRAPPER`, with which it may be possible to run gdb to debug test cases ``` (cd ~/src/wine-build; make -j10 ; WINETEST_WRAPPER="gdb --args" WINEPREFIX=~/src/wine/.wine ../wine/tools/runtest -P wine -T . -M ws2_32.dll -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) Reading symbols from ./wine... (gdb) set follow-fork-mode child (gdb) r current directory: 'Z:\home\ralf.habacker\src\wine-build' sock.c:14624: Test failed: test_afunix.sock: wrong attr ffffffff sock.c:14658: Test failed: test_afunix.sock: wrong family 0 sock.c:14693: Test failed: test_afunix.sock: wrong family 0 ... ``` With this you can debug the wine application, but unfortunally not the windows api. # How to debug a wine test case (windows api) 1. After building wine install the binaries into a temporary location ``` make -C ~/src/wine-build install DESTDIR=~/src/wine-install ``` 2. run ``` (cd ../wine-build; \ WINEPREFIX=~/src/wine/.wine \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ ./wine programs/winedbg/i386-windows/winedbg.exe --gdb dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` Now let's look at the loaded shared libraries ``` Wine-gdb> info sharedlibrary From To Syms Read Shared Object Library 0xf7b39000 0xf7bff6e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine/.wine/drive_c/windows/system32/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine/.wine/drive_c/windows/system32/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine/.wine/drive_c/windows/system32/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine/.wine/drive_c/windows/system32/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine/.wine/drive_c/windows/system32/gdi32.dll 0x7a0b1000 0x7a0e48e8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` It is visible, that the unix variant of the shared libraries (ntdll.so) are read from the build dir and also the test case. The Windows part (\*.dll) is loaded from the wine prefix, so that these must be copied from the build directory initially and whenever changes are made. With this is possible to set breakpoints ``` Wine-gdb> b GetFileAttributesW@4 Breakpoint 1 at 0x7b5d3725: file ../wine/dlls/kernelbase/file.c, line 1665. Wine-gdb> c Continuing. Breakpoint 1, GetFileAttributesW@4 ( name=0x40fcfa <test_afunix+1434> L"\xec83\x8304\xfff8\x940f\x89c0\x247c\xf08\xc0b6\x44c7\x424\x1bbf\103\x489\xe824\x52e6\001\x44c7", <incomplete sequence \x824>) at ../wine/dlls/kernelbase/file.c:1665 1665 TRACE( "%s\n", debugstr_w(name) ); ``` # Followup By adding `WINESYSTEMDLLPATH=/home/user/src/wine-install/usr/local/lib/wine/i386-windows/` to the command line, some shared libraries are loaded directly from the build directory, so they do not need to be copied. ``` From To Syms Read Shared Object Library 0xf7eb2000 0xf7f786e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/gdi32.dll 0x79e31000 0x79e648e8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` Why this does not apply to all system libraries is currently unclear. -- v44: ws2_32: Add note in bind() for AF_UNIX sockets ws2_32/tests: In tests for AF_UNIX sockets print actual directory used server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. ws2_32: Add support for AF_UNIX sockets. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

3 7

[PATCH v2 0/1] MR9395: arm64: Detect more new processor features.
by Martin Storsjö (＠mstorsjo) 14 Nov '25

14 Nov '25

This one is somewhat tricky, as the existing `ProcessorFeatures` array is limited to `PROCESSOR_FEATURE_MAX` aka 64 entries, while this now defines features up to index 88. To handle the higher number of features, this patch extends `KUSER_SHARED_DATA` with a separate second array for the later features. This requires updating an assert about its size. If there's a better place to store the excess feature bits, I'm open for suggestions. As far as I can see, there's no obvious place that would be ABI visible where it should be stored. (I also see that upstream definitions of `KUSER_SHARED_DATA` has been extended with another new field that Wine doesn't have - so having our own data there probably isn't ideal.) So if there's some other convenient way of storing this (e.g. a global variable in ntdll) that also works, but it would need to be accessible from both the PE and unix sides, so it's probably not very straightforward either? -- v2: arm64: Detect more new processor features. https://gitlab.winehq.org/wine/wine/-/merge_requests/9395

2 1

[PATCH 0/2] MR9398: Don't try to activate a window in set_window_pos if it's set as active in GUITHREADINFO.
by Santino Mazza (＠tati) 14 Nov '25

14 Nov '25

This prevents a window from getting reactivated when calling `SetWindowPos` inside the WM_ACTIVATE handler. For now I only was able to reproduce this by triggering a change in the active window from X11 with an alt-tab or by clicking another window, I was not able to write a wine test for this. This test program works for reproducing it. ```c #include <windows.h> LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { if (uMsg == WM_ACTIVATE) { SetWindowPos(hwnd, 0, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); } done: return DefWindowProc(hwnd, uMsg, wParam, lParam); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pCmdLine, int nCmdShow) { HWND hwnd; const char CLASS_NAME[] = "class"; WNDCLASSA wc = {}; wc.lpfnWndProc = WindowProc; wc.hInstance = hInstance; wc.lpszClassName = CLASS_NAME; RegisterClass(&wc); hwnd = CreateWindowEx(0, CLASS_NAME, "test", 0, 4, 4, 1024, 768, NULL, NULL, hInstance, NULL); ShowWindow(hwnd, SW_SHOW); MSG msg; while (TRUE) { GetMessage(&msg, NULL, 0, 0); TranslateMessage(&msg); DispatchMessage(&msg); } } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9398

3 6

[PATCH 0/1] MR9455: windows.media.playback.mediaplayer/tests: Skip tests when CLASS_E_CLASSNOTAVAILABLE is returned.
by Mohamad Al-Jaf (＠maljaf) 14 Nov '25

14 Nov '25

The runtime class is not available on Windows 10 1507. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9455

3 2

[PATCH 0/5] MR9458: Reparse points, part 3.
by Elizabeth Figura (＠zfigura) 14 Nov '25

14 Nov '25

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

3 6

[PATCH 0/9] MR9456: winemac: Remove macdrv_get_displays() and struct macdrv_display.
by Brendan Shanks (＠bshanks) 13 Nov '25

13 Nov '25

winemac has functions+structs to enumerate "adapters", "monitors", and "displays", but these are all reporting the same underlying objects (macOS screens/displays) in slightly different ways. "displays" is the oldest one, and the least connected to the current win32u concepts of sources and monitors. To remove `macdrv_display`, I essentially integrated `macdrv_get_displays()` into `macdrv_get_monitors()` (where it was used to get `RcMonitor` and `RcWork`). I converted one other caller to use `macdrv_get_monitors()` instead, and the other callers didn't actually support multiple monitors anyway. I may work on eliminating the redundancy between "adapters" and "monitors" in the future, as far as I can tell "monitors" are a superset of "adapters" (monitors includes mirrors, adapters does not). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9456

2 9

Re: [PATCH v5 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Jiajin Cui (＠jin-king1) 13 Nov '25

13 Nov '25

On Thu Nov 13 16:47:46 2025 +0000, Esme Povirk wrote: > I think these are supposed to be sorted? I don't think sorting was done here, because "DndProtocol" still comes after "WM_TAKE_FOCUS". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121972

1 0

[PATCH v2 0/3] MR9454: Revert "winmm: Use AUTOCONVERTPCM when initializing the audio client."
by Giovanni Mascellani (＠giomasce) 13 Nov '25

13 Nov '25

This reverts commit 21fb3555ed1f26e46d4c82cb2ec8fc29f730a0e9, which inadvertently removed support for converting audio formats not directly supported by mmdevapi. I'll work on a better solution over the next few days. -- v2: Revert "winmm: Use AUTOCONVERTPCM when initializing the audio client." https://gitlab.winehq.org/wine/wine/-/merge_requests/9454

2 3

2025

2024

2023

2022

wine-gitlab