May 2024 - Wine-gitlab - list.winehq.org

[PATCH 0/1] MR5704: makedep: Silence Clang warnings in bison-generated files.
by Jacek Caban (＠jacek) 29 May '24

29 May '24

Depending on bison version and Clang config, generated files cause various warnings. In gitlab CI, there is an unused function in wbemprox. I don't see it on newer bison and LLVM, but there are other -Wunused-but-set-variable warning instead. This was partially fixed in upstream bison: https://git.savannah.gnu.org/cgit/bison.git/commit/?id=a166d5450e3f47587b98… The fix does not take into account MSVC targets, I tried upstreaming a fix for that, with no success: https://savannah.gnu.org/patch/?10420 https://lists.gnu.org/archive/html/bison-patches/2023-11/msg00000.html Together with !5628, this allows enabling `-Werror` in out CI. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5704

5 5

[PATCH v4 0/5] MR5744: winegstreamer: Fix various Cinepak issues
by Alfred Agrell (＠Alcaro) 29 May '24

29 May '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56698 I'm not hugely satisfied with some of those changes (especially how looping avi_decompressor_source_get_media_type now takes O(n^2) calls to ICDecompressQuery), but it gets the video in that issue working. If you've got a better idea for how to implement this stuff, do tell. -- v4: msvfw32/tests: Test that Cinepak rejects unsupported output types. iccvid: Reject unsupported output types. quartz/tests: Add Cinepak test to avi splitter. winegstreamer: Try DTS if PTS is absent. winegstreamer: Implement AM_MEDIA_TYPE to wg_format converter for Cinepak video. https://gitlab.winehq.org/wine/wine/-/merge_requests/5744

3 6

[PATCH 0/5] MR5745: wined3d: Remove miscellaneous unused definitions, part 3/4.
by Elizabeth Figura (＠zfigura) 29 May '24

29 May '24

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

2 5

[PATCH v2 0/1] MR5720: wineps.drv: Only merge dmDefaultSource member of devmodes when a slot is found.
by Danyil Blyschak (＠blyss) 29 May '24

29 May '24

There is a check earlier in the PSDRV_MergeDevmodes/merge_devmodes functions to update dmDefaultSource if a slot is found, and so this member should not be updated again with no such check. -- v2: wineps.drv: Only merge dmDefaultSource member of devmodes when a slot is found. https://gitlab.winehq.org/wine/wine/-/merge_requests/5720

4 3

[PATCH 0/1] MR5742: programs/conhost: Fix display of font preview (in 64bit mode).
by eric pouech (＠epo) 29 May '24

29 May '24

Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5742

3 2

[PATCH v3 0/2] MR5734: mf: Implement audio capture device enumeration in MFEnumDeviceSources().
by Paul Gofman (＠gofman) 29 May '24

29 May '24

-- v3: mf: Implement audio capture device enumeration in MFEnumDeviceSources(). https://gitlab.winehq.org/wine/wine/-/merge_requests/5734

4 5

[PATCH 0/1] MR5741: Draft: server: Implement key auto-repeat.
by Alexandros Frantzis (＠afrantzis) 29 May '24

29 May '24

This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions: 1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code). 2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves). Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5741

4 9

[PATCH v2 0/7] MR5665: For a CS_PARENTDC child use parent for visible region calculations.
by Dmitry Timoshkov (＠dmitry) 29 May '24

29 May '24

These patches fix painting in an application that draws outside of a CS_PARENTDC child client area in its WM_PAINT handler. Comments and suggestions are welcome. -- v2: win32u: Use parent rectangle for visible region calculations of a CS_PARENTDC child. win32u: Don't clip update region to the window client rectangle. win32u: GetUpdateRgn() should clip update region to the window client area. win32u: GetUpdateRect() should clip update rectangle to the window client area. win32u: Clip PAINTSTRUCT.rcPaint to the window client area. server: For a CS_PARENTDC child use parent for visible region calculations. server: If the being validated region covers whole window then validate everything. https://gitlab.winehq.org/wine/wine/-/merge_requests/5665

3 8

[PATCH v4 0/4] MR5738: win32u: More DPI awareness context fixes.
by Rémi Bernon 29 May '24

29 May '24

-- v4: win32u: Only keep DPI awareness context with window objects. win32u: Fix SetThreadDpiAwarenessContext. win32u: Pass the DPI awareness context in win_proc_params. win32u: Get the thread DPI context instead of the awareness. https://gitlab.winehq.org/wine/wine/-/merge_requests/5738

3 6

[PATCH v2 0/3] MR5736: win32u: Prefer properties from Vulkan over fake ones.
by Krzysztof Bogacki (＠Saancreed) 29 May '24

29 May '24

Currently, when GPUs are being added and display driver only provides a fake one (like e.g. winex11.drv does on Xwayland), its default name and empty UUID and PCI IDs will be preferred over ones reported by Vulkan. When Vulkan-only GPUs are added later, the resulting list will look like so: ``` Xrandr GPU 0x0000:0x0000 {00000000-0000-0000-0000-000000000000} NVIDIA GeForce RTX 4080 Laptop GPU 0x10de:0x27e0 {13938ad6-4925-b628-c068-30558bc4b489} ``` Instead, when default or empty properties were provided, we should prefer ones from Vulkan as they are more likely to be accurate: ``` Intel(R) Graphics (RPL-S) 0x8086:0xa788 {a7888086-0004-0000-0002-000000000000} NVIDIA GeForce RTX 4080 Laptop GPU 0x10de:0x27e0 {13938ad6-4925-b628-c068-30558bc4b489} ``` This is important for LUIDs to be later correctly assigned by winevulkan which searches for matching GPU by UUID. I'm not exactly sure if this implementation is the way to go (especially reporting and checking name for `"Wine GPU"`) but it's probably one of the simplest possible. Let me know if we already have some empty UUID around I could use for the comparison. -- v2: win32u: Prefer Vulkan UUIDs over empty ones. https://gitlab.winehq.org/wine/wine/-/merge_requests/5736

4 8