October 2024 - wine-gitlab

[PATCH 0/7] MR4947: winewayland.drv: part 12: Display mode change emulation
by Alexandros Frantzis (＠afrantzis) 24 Nov '24

24 Nov '24

This MR uses the existing compositor side surface scaling in the driver (through wp_viewporter, currently used for Hi-DPI scaling) to emulate display mode changes. This works wonderfully in coordination with fullscreen since the compositor is required non only to scale the surface, but also to position it properly and provide opaque surroundings (note: some compositors don't implement the last two features properly!). Since: 1. Wayland doesn't allow clients to change the actual display configuration, and 2. there is no queryable service that holds the display information in a consistent manner (à la xrandr), the MR uses the win32 device settings as the source of truth for the current display mode. We let win32u handle the display mode change in the default manner (i.e., just updating the registry settings), and provide access to the current mode when updating the display devices through a new `gdi_display_manager.get_adapter()` function. In order to be able to consistently (across all processes) associate an adapter device with its corresponding `wl_output` the MR introduces per-adapter driver data. Note for people trying this out: many modern games don't change the hardware display settings, but rather scale themselves in right way to achieve the visual effect of a mode change (similarly to how this MR works, but they do it on the application side). To exercise most of the functionality in this MR you need an application that actually uses the `ChangeDisplaySettings` win32 API. Thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4947

16 48

[PATCH 0/1] MR5925: d2d: Added support for DXGI_FORMAT_R8G8B8A8_UNORM on wic render targets
by Agustin Principe (＠principeagustin) 21 Nov '24

21 Nov '24

Added suppot for DXGI_FORMAT_R8G8B8A8_UNORM to d2d_wic_render_target_init. For further testing i can provide and .exe that renders a red circle over a blue background. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5925

4 5

[PATCH v2 0/1] MR6523: wtsapi32: Handle WTSSessionInfo class in WTSQuerySessionInformationW().
by Pétur Runólfsson (＠petur) 21 Nov '24

21 Nov '24

-- v2: wtsapi32: Handle WTSSessionInfo class in WTSQuerySessionInformationW(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6523

3 4

[PATCH 0/1] MR6735: msxml3: Undo removal of xmlThrDefTreeIndentString
by Fabian Maurer (＠DarkShadow44) 21 Nov '24

21 Nov '24

Fixes regression by 9d34c44d8464722c333fdde5313b341504d3ea44. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57325 Not sure why this was removed, but it breaks the office installer. If this is not the right course of action, please tell me and I'll try to find a different solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6735

7 21

[PATCH v3 0/2] MR4392: server: Don't crash when opening null path with a console handle as RootDirectory.
by Jinoh Kang (＠iamahuman) 20 Nov '24

20 Nov '24

Preparatory patch for revival of https://gitlab.winehq.org/wine/wine/-/merge_requests/498. -- v3: server: Don't crash when opening null path with a console server as RootDirectory. server: Don't crash when opening null path with a console handle as RootDirectory. https://gitlab.winehq.org/wine/wine/-/merge_requests/4392

3 3

[PATCH 0/1] MR6211: wined3d: Fix a memory leak.
by Haoyang Chen (＠chenhaoyang) 19 Nov '24

19 Nov '24

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

5 7

[PATCH v5 0/1] MR1139: ntoskrnl.exe: add KeNumberProcessors export.
by Etaash Mathamsetty (＠etaash.mathamsetty) 19 Nov '24

19 Nov '24

I haven't seen any software that uses this, but some older software out there might use it, so it's good idea to export it. -- v5: ntoskrnl.exe: add KeNumberProcessors export. https://gitlab.winehq.org/wine/wine/-/merge_requests/1139

4 4

[PATCH 0/1] MR6385: gdi32: Fix the text's charset error in obtaining from meta dc.
by JiangYi Chen (＠meshine) 19 Nov '24

19 Nov '24

Log: get_dc_attr always failed for meta dc,so GdiGetCodePage always return CP_ACP. And GetTextCharset is similar to this situation. Finally, leading to an error result of text_mbtowc call by ExtTextOutA and an error result of METADC_ExtTextOut. Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com> Change-Id: Icb6a8d57848935bc5c1b3913c155148af43eca0d -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6385

3 4

[PATCH v6 0/2] MR5231: ntdll: Add SDL_AUDIO*/SDL_VIDEO* to the special variables list.
by Aida Jonikienė (＠DodoGTA) 18 Nov '24

18 Nov '24

Overriding the SDL_VIDEODRIVER variable (for Wayland support as an example) on the Linux side can lead to some games under Wine failing to load (so treat that variable as special). -- v6: ntdll: Add SDL audio driver variables to the special variables list. ntdll: Add SDL video driver variables to the special variables list. https://gitlab.winehq.org/wine/wine/-/merge_requests/5231

5 6

[PATCH 0/7] MR6715: Draft: Support separated debug information for PE images.
by eric pouech (＠epo) 18 Nov '24

18 Nov '24

This serie is a first attempt to provide a solution to bug 57308 [1]. Basically, Arch distro is looking for Wine support in distributing debug information for Wine PE modules separated from image. A quick overview of distro (Debian, Fedora, Arch) situation i (I may have missed a couple of items), but: - no distro ship separate debug information for PE modules (they do it for ELF ones though) - at best, they ship unstripped PE modules. IMO, we need to help them pave the way to what should be the best expected situation (in Wine and wrt distros) to support separate debug information for PE images. First, I believe we need to use a (solid) key to bind the stripped image and the file holding the debug information. In ELF format, this is typically done by inserting a .note.gnu.build-id section (in both stripped image and debug information file) which contains the key. This key is used to either search in fixed location (eg /usr/lib/.debug), or as key to download the debug information from a remote server (debuginfod). The key is generally made of a hash of (some sections of) the image file. This allows (esp. in the case of downloading the debug information from a debugger) to discriminate between several versions of the same module. I think we should target this kind of solution instead of storing the debug information alongside the module (usually done as ntdll.dll.debug). This wouldn't let debuggers download the expected debug info upon request. Fortunately, gcc and clang provide a build-id option (when generating PE images) which stores this key in the PE image. What this serie does: - fixes & improves dbghelp in the support of the build-id information from gcc/mingw & clang, - improves Wine's configure script so that clang can be used to generate dwarf debug information and build-id information in PE builds, - adds a couple of additional search locations for debug information files, It takes the following assumptions for the storage: - debug information files for PE images are stored in same hierarchy as debug information files for ELF images (eg /usr/lib/.debug) - naming of such files is done as ELF, ie by using the hex string generated from the binary blob of the key. This is *NOT* the usual way how the GUID will be printed (because the first 3 integers of the GUID are stored in little-endian format). (Note: I had to make a choice here. I don't have strong arguments one way or the other, but we need to agree on the convention here). What distro should do to support separate debug info: - configure Wine with --enable-build-id - adapt at least the packaging tool to extract the key out of unstripped image [2], - if binutils isn't compiled with PE support (this is apparently the Arch case), adapt the scripts to use x86_64-objcopy instead of objcopy (and friends). I marked this MR as draft for now, as: - I still need to polish some items (like the default location for looking up debug information files), - wait for feedback on this proposal (it does make a couple of assumptions that need sharing IMO), Further steps: - the steps above are mainly targetted to have a solution for packaged download of debug information files, - this should be integrated in debuginfod (server side: ingestion of PE files and client side: ensure gdb, lldb are compatible; implement debuginfod in winedbg). Feed back welcomed! [1]: https://bugs.winehq.org/show_bug.cgi?id=57308 [2]: The least invasive readelf replacement (assuming binutils is compiled with PE support). (otherwise, use x86_64-objdump) BUILDID=`objdump -p "$INPUT" | sed -n "/RSDS signature / {s/.*signature //; s/ age.*//p; q;}"` BUILDID=${BUILDID:6:2}${BUILDID:4:2}${BUILDID:2:2}${BUILDID:0:2}${BUILDID:10:2}${BUILDID:8:2}${BUILDID:14:2}${BUILDID:12:2}${BUILDID:16} Additional note: gcc/mingw puts the desired debug entry inside a dedicated section (.buildid), while clangs keeps it in .rdata (as msvc does). So, this invalidates any attempt to get information from the .buildid section (as stated in bug report). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6715

4 14

2025

2024

2023

2022

wine-gitlab October 2024