March 2023 - Wine-GitLab - list.winehq.org

[PATCH 0/1] MR2260: wined3d: Initialise GLSL outputs to avoid nVidia warning
by David Gow (＠sulix) March 2, 2023

March 2, 2023

nVidia's GLSL compiler spits out a warning if a value is potentially used without being initialized. This affects many of wined3d's GLSL shaders, as either some element of the (e.g.) vs_out array are not initialized, or individual vector components remain unwritten to. As a quick way of working around this, initialize all vs_out, gs_out, and temporary Rn registers to vec4(0,0,0,0). This gets rid of all of the warnings in the cases I tried. (A more complete solution would probably track if we're initialising these, and only add what is required. Or would just disable the warning somehow.) Some example warnings (from a shader in the 'Pharaoh: A New Era' demo): ``` 0264:fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #3: 0264:fixme:d3d_shader:print_glsl_info_log Vertex info 0264:fixme:d3d_shader:print_glsl_info_log ----------- 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[2].zw" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[5].w" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[7]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[8]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[9]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[10]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[11]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[12]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[13]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[14]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[15]" might be used before being initialized ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260

5 10

[PATCH v9 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) March 2, 2023

March 2, 2023

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v9: d3d9: Always draw only a single instance for non-indexed draws. d3d9/tests: Add test for non-indexed instancing drawing. https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

3 4

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Henri Verbeet (＠hverbeet) March 2, 2023

March 2, 2023

> Otherwise, it can be technically made to work like for GL child window redering (keeping composite redirected drawables for different pixel formats) but that requires essentially the same blitting on each present as done with wined3d backup context. It wouldn't need to go through CPU memory though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26016

1 0

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) March 2, 2023

March 2, 2023

On Thu Mar 2 13:50:13 2023 +0000, **** wrote: > Marvin replied on the mailing list: > ``` > Hi, > It looks like your patch introduced the new failures shown below. > Please investigate and fix them before resubmitting your patch. > If they are not new, fixing them anyway would help a lot. Otherwise > please ask for the known failures list to be updated. > The tests also ran into some preexisting test failures. If you know how > to fix them that would be helpful. See the TestBot job for the details: > The full results can be found at: > https://testbot.winehq.org/JobDetails.pl?Key=130177 > Your paranoid android. > === debian11 (32 bit report) === > dinput: > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected FFFFFFFF > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 00000002 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 0000000A > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected FFFFFFFF > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 0000000B > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 00000002 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > ``` These seem unrelated to the changes in this MR, rebasing on latest master and trying again... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26010

1 0

[PATCH 0/2] MR2313: shlwapi/tests: Fix the date formatting tests when the locale does not match the code page.
by Francois Gouget (＠fgouget) March 2, 2023

March 2, 2023

In particular, February dates contain an e-acute in French, the representation of which depends on the code page being used, which in SHFormatDateTimeA() is CP_ACP. Also there are only three months that triggered this bug in French: February, August and December. So also make sure to test this issue year round. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54149 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2313

2 2

[PATCH 0/1] MR2311: include: Add more Windows.Foundation.Numerics type declarations.
by Jacek Caban (＠jacek) March 2, 2023

March 2, 2023

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

3 4

[PATCH 0/1] MR988: dmloader/tests: Mark tests failing randomly on Windows as flaky.
by Francois Gouget (＠fgouget) March 2, 2023

March 2, 2023

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

3 6

[PATCH 0/1] MR1138: gitlab: Add winetest checksums to the build artifacts.
by Francois Gouget (＠fgouget) March 2, 2023

March 2, 2023

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

3 5

[PATCH v3 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) March 2, 2023

March 2, 2023

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information. -- v3: winewayland.drv: Introduce wayland_mutex. winewayland.drv: Initialize basic per-thread Wayland instance. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

3 9

[PATCH v2 0/5] MR1543: mmdevapi: Handle process_attach, process_detach and test_connect UNIX driver functions
by Davide Beatrici (＠davidebeatrici) March 2, 2023

March 2, 2023

The goal is to eventually move all interfaces from each driver's `mmdevdrv.c` into `mmdevapi`. -- v2: wine{alsa,coreaudio,oss,pulse}: Move test_connect handling into mmdevapi. winepulse: Move process_attach and process_detach handling into mmdevapi. mmdevapi: Query MemoryWineUnixFuncs virtual memory and store the resulting handle. wine{alsa,coreaudio,oss,pulse}: Return STATUS_NOT_IMPLEMENTED for unused unixlib functions. include: Add missing "winternl.h" include to unixlib.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/1543

3 11

[PATCH v8 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) March 2, 2023

March 2, 2023

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v8: d3d9: Always draw only a single instance for non-indexed draws. https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

2 2

[PATCH v7 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) March 2, 2023

March 2, 2023

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v7: d3d9: Always draw only a single instance for non-indexed draws. d3d9/tests: Add test for non-indexed instancing drawing. https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

2 2

[PATCH v2 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) March 2, 2023

March 2, 2023

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information. -- v2: winewayland.drv: Introduce wayland_mutex. winewayland.drv: Initialize basic per-thread Wayland instance. winewayland.drv: Add stub for per-thread data. winewayland.drv: Perform basic per-process Wayland initialization. winewayland.drv: Add initial unixlib stub. winewayland.drv: Add initial driver stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

3 16

Re: [PATCH v2 0/3] MR2304: widl: Add parameterized signatures for more basic types.
by Mohamad Al-Jaf (＠maljaf) March 2, 2023

March 2, 2023

On Wed Mar 1 08:06:29 2023 +0000, Huw Davies wrote: > @rbernon, note that you should explicitly approve this as it contains > commits from another author. I see, yeah, I tried to add the correct strings to the types, but couldn't find anything on array. The others were pretty straightforward. Also, the build error was misleading and I think it'd be helpful to add the equivalent of `TRACE` in widl. The existing debug parameters were not helpful. Thanks for the link, good info. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2304#note_25975

1 0

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Etaash Mathamsetty (＠etaash.mathamsetty) March 2, 2023

March 2, 2023

tests failing for unrelated reasons -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_25966

1 0

[PATCH v6 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) March 1, 2023

March 1, 2023

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v6: d3d9: Always draw only a single instance for non-indexed draws. d3d9/tests: Add test for not-indexed instancing drawing https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

3 9

[PATCH v2 0/2] MR2302: gdiplus: Use FILE_SHARE_READ in GdipPrivateAddFontFile().
by w-flo (＠w-flo) March 1, 2023

March 1, 2023

ZusiDisplay sometimes loads the same font file into two different PrivateFontCollections using two threads, so there is a race condition when the file is opened without the FILE_SHARE_READ sharing mode. The second call to GdipPrivateAddFontFile() might fail if the first one hasn't closed the file handle yet. -- v2: gdiplus: Use FILE_SHARE_READ in GdipPrivateAddFontFile(). gdiplus/tests: Test for GdipPrivateAddFontFile() sharing violation. https://gitlab.winehq.org/wine/wine/-/merge_requests/2302

4 9

Re: [PATCH v2 0/5] MR2256: wined3d: move stubs out of state tables - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

Re: [PATCH v7 0/8] MR2098: mshtml: Implement synchronous XMLHttpRequests. - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

Re: [PATCH v3 0/2] MR2308: mfreadwrite/reader: Release device manager in source_reader_release. - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

Re: [PATCH v2 0/1] MR2307: dlls/dwrite: Pass correct font key when adding glyph to cache. - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

Re: [PATCH v5 0/1] MR2033: ntoskrnl: Add ExGetPreviousMode and test. - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

Re: [PATCH v5 0/1] MR2046: server: Annotate allocation functions with __WINE_(ALLOC_SIZE|DEALLOC|MALLOC). - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

Re: [PATCH v2 0/3] MR2304: widl: Add parameterized signatures for more basic types. - approved
by Alexandre Julliard (＠julliard) March 1, 2023

March 1, 2023

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

1 0

[PATCH v2 0/3] MR2274: ntdll: Add source file and line to debug traces.
by Rémi Bernon March 1, 2023

March 1, 2023

-- v2: ntdll: Add return address information in __wine_debug_context. ntdll: Add file and line information in __wine_debug_context. ntdll: Introduce struct __wine_debug_context for extensible debug info. https://gitlab.winehq.org/wine/wine/-/merge_requests/2274

2 7

[PATCH 0/6] MR2303: uiautomationcore: Implement a few COM UI Automation condition interfaces.
by Connor McAdams (＠cmcadams) March 1, 2023

March 1, 2023

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

3 11

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Paul Gofman (＠gofman) March 1, 2023

March 1, 2023

Do you see any other way out of this? I mean specifically the case when an app sets GL pixel format itself on a window. I was thinking about whether it is possible to make setpixelformat quicker in winex11 instead and I don't see how. If keeping direct presentation it will require some X window reconfigure which is not going to be anywhere quick. Otherwise, it can be technically made to work like for GL child window redering (keeping composite redirected drawables for different pixel formats) but that requires essentially the same blitting on each present as done with wined3d backup context. The other different (but a bit complicated) way would be to: - count statistics of GL pixel format switches; - introduce switching back from backup context and switch between resetting pixel format or switching to backup context or back based on that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25906

1 0

[PATCH 0/5] MR2256: wined3d: move stubs out of state tables
by Max Figura (＠maxfigura) March 1, 2023

March 1, 2023

Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2256

4 7

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Zebediah Figura (＠zfigura) March 1, 2023

March 1, 2023

> It's probably worth pointing out that this has quite some potential for causing regressions in performance. swapchain_blit_gdi() is not fast, and ideally we'd work on reducing the number of cases where it's needed. The fundamental idea here is that setting and restoring the pixel format is even worse, since we always need to recreate the GLX drawable when we do that. And as far as I can tell, this patch doesn't force GDI blitting in any other circumstance. That said, what about Mac? I don't really know what's going on here; set_pixel_format() seems to be cheap, but I can't easily tell if that's because it really is cheap, or because setting the pixel format just doesn't work. Either way this patch is questionable as-is. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25904

1 0

[PATCH v8 0/1] MR2153: win32u: Invalidate all cached keys after input.
by Henry Goffin (＠AMZN-hgoffin) March 1, 2023

March 1, 2023

This patch addresses an issue in Second Life and potentially other multi-threaded applications which process WM_KEYDOWN in one thread and then verify that the key is "still down" with GetAsyncKeyState from another thread. Wine uses a per-thread key cache, resulting in inconsistent views of key status. Caches are now invalidated when an input event is injected by the driver or via SendInput. -- v8: win32u: Invalidate all cached keys after input. https://gitlab.winehq.org/wine/wine/-/merge_requests/2153

2 2

Re: [PATCH v7 0/1] MR2153: win32u: Invalidate all cached keys after input.
by Zebediah Figura (＠zfigura) March 1, 2023

March 1, 2023

This is missing the change to protocol.def. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2153#note_25897

1 0

[PATCH v6 0/8] MR2098: mshtml: Implement synchronous XMLHttpRequests.
by Gabriel Ivăncescu March 1, 2023

March 1, 2023

wine-gecko does actually support synchronous XMLHttpRequests, even if they are deprecated, but unfortunately it is very broken compared to IE or all the other major browsers (more details [here](https://bugzilla.mozilla.org/show_bug.cgi?id=697151)) Thankfully, it still provides us with the event message loop, which is enough to fix it on mshtml side and act like IE. For sync XHRs, send() is supposed to block all script code, except for notifications sent to the sync XHR. This is because when send() blocks, no other piece of code in the script should execute other than the sync XHR handlers. Unfortunately, that's not the case in Gecko's broken implementation, which can execute handlers as if they were APCs while it's "blocked" in send(). Note that it doesn't actually block, though, because we still process the message loop (non-event related tasks such as navigation, paints, and other stuff), and that's normal. Gecko doesn't block everything related to script events, only some things on the document and timers, but that's far from enough and not even enough for our purposes since we use our own timer tasks. And not even message events are blocked, even though we *also* use our own message event dispatchers (but it doesn't block Gecko ones either). So what we have to do is we need to track all the timers and events dispatched that result in script handlers being executed, while "blocking" inside of a sync XHR send(), and queue them up to defer them to be dispatched later, after send() unblocks. But this is easier said that done. There are many corner cases to consider here, for example: * Events dispatched *synchronously* from within a sync XHR handler or other piece of code called from it. * Nested sync XHR send() calls (called during handler of another sync XHR). * Async XHRs having their events dispatched during a blocking sync XHR send() are complicated. `readyStateChange` for example needs to have the async XHR's readyState at the time it was sent, **not** at the time it was actually dispatched, since we're going to delay it and dispatch it later. It's similar with other XHR states, such as responseText (which can be partial). * Aborts of async XHRs during such handlers. These patches hopefully should address all the issues and, on a high level, work like this: * Track the `readyState` and `responseText` length manually, so we can override / force them to specific values. * "Snapshot" the async XHR at the time we encounter an event for it, and queue this event with such information. When later dispatching this event (after being deferred), we temporarily set the state of the async XHR to the snapshot. * To deal with nested event dispatches, keep track of a "dispatch depth" (everytime we dispatch an event we increase the depth, and when it returns we decrease it). * For sync XHRs, we note the depth when send() is called, and defer events at that depth, since they're dispatched during the "blocked" message loop and need to be delayed (except for sync XHR events, which is a special case since it must be dispatched synchronously). When it returns, we restore the previous blocking depth. -- v6: mshtml: Send all readystatechange events for synchronous XHRs in IE9 mshtml: Implement synchronous XMLHttpRequest. mshtml: Add separate task list for tasks dispatching events. mshtml: Track readyState in XHRs and report it manually. mshtml: Register all event handlers when creating the XMLHttpRequest. mshtml: Pass optional args to XMLHttpRequest.open() correctly. mshtml: Free the task after the destructor. mshtml: Use proper types for readystate_locked and readystate_pending. https://gitlab.winehq.org/wine/wine/-/merge_requests/2098

3 12

[PATCH v14 0/4] MR84: vkd3d-shader/spirv: Merge all shader IR fork and join phases into a single phase.
by Conor McCarthy (＠cmccarthy) March 1, 2023

March 1, 2023

Normalise the incoming vkd3d_shader_instruction IR to the shader model 6 pattern where only one patch constant function is emitted. This allows generation of a single patch constant function in SPIR-V. -- v14: vkd3d-shader/spirv: Declare the phase SPIR-V function in spirv_compiler_enter_shader_phase(). vkd3d-shader/spirv: Remove the hull shader phase array. vkd3d-shader/trace: Trace the normalised instruction array after tracing the input. vkd3d-shader/ir: Merge all shader IR fork and join phases into a single phase. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/84

3 6

[PATCH v6 0/4] MR94: Fix other synchronization problems
by Giovanni Mascellani (＠giomasce) March 1, 2023

March 1, 2023

-- v6: vkd3d: Do not keep the CS queue locked while processing it. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/94

4 6

[PATCH v2 0/2] MR2308: mfreadwrite/reader: Release device manager in source_reader_release.
by Adrian Thiele (＠athiele) March 1, 2023

March 1, 2023

-- v2: mfreadwrite/reader: Release device manager in source_reader_release. mfreadwrite/tests: Check refcount of device manager after release. https://gitlab.winehq.org/wine/wine/-/merge_requests/2308

3 3

[PATCH 0/1] MR112: include: Document that vkd3d_shader_signature may contain pointers into the input shader blob.
by Zebediah Figura (＠zfigura) March 1, 2023

March 1, 2023

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/112

3 2

[PATCH 0/1] MR2308: mfreadwrite/reader: Release device manager in source_reader_release.
by Adrian Thiele (＠athiele) March 1, 2023

March 1, 2023

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

4 5

[PATCH 0/1] MR2307: dlls/dwrite: Pass correct font key when adding glyph to cache.
by Philip Gruebele (＠pgruebele) March 1, 2023

March 1, 2023

Without this fix, the font cache was filling up with lots of duplicate entries, and getting cache misses, thereby causing font-intensive applications to be very slow (e.g. AvalonEdit) . This fix provides 30x speed increase when processing glyphs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2307

3 2

[PATCH 0/7] MR106: vkd3d-shader/hlsl: packoffset() support.
by Francisco Casas (＠fcasas) March 1, 2023

March 1, 2023

Support manually packing constant buffer elements through the `packoffset(·)` syntax. Support not included yet for simultaneously having semantics, `register(·)`, and `packoffset(·)`, for abnormalities such as: ```hlsl Texture2D tex; cbuffer buff { float4 a : packoffset(c0); sampler sam : packoffset(c0) : register(s1) : SEMANTIC; } float4 main() : sv_target { return tex.Sample(sam, float2(0, 0)) + a; } ``` but this motivated the addition of the `hlsl_ir_var.offset_reservation` field instead of reusing `hlsl_ir_var.reg_reservation`. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/106

4 25

[PATCH 0/1] MR2305: rpcrt4: Pass the binding handle to server call function.
by Yeshun Ye (＠yeyeshun) March 1, 2023

March 1, 2023

Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2305

4 7

[PATCH v3 0/1] MR2306: msado15: Implement _Recordset Open
by Alistair Leslie-Hughes (＠alesliehughes) March 1, 2023

March 1, 2023

-- v3: msado15: Implement _Recordset Open https://gitlab.winehq.org/wine/wine/-/merge_requests/2306

2 1

Re: [PATCH v7 0/1] MR2153: win32u: Invalidate all cached keys after input. - approved
by Rémi Bernon March 1, 2023

March 1, 2023

This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2153

1 0

[PATCH 0/1] MR2306: msado15: Implement _Recordset Open
by Alistair Leslie-Hughes (＠alesliehughes) March 1, 2023

March 1, 2023

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

3 2

[PATCH v2 0/1] MR2306: msado15: Implement _Recordset Open
by Alistair Leslie-Hughes (＠alesliehughes) March 1, 2023

March 1, 2023

-- v2: msado15: Implement _Recordset Open https://gitlab.winehq.org/wine/wine/-/merge_requests/2306

3 2

[PATCH 0/3] MR2304: widl: Add parameterized signatures for more basic types.
by Rémi Bernon March 1, 2023

March 1, 2023

Related to https://gitlab.winehq.org/wine/wine/-/merge_requests/2292. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2304

4 8

[PATCH v3 0/1] MR2081: Support relocatable fontconfig cache
by catsout (＠catsout) March 1, 2023

March 1, 2023

For flatpak: ``` bind mount: /run/host/fonts <- /usr/share/fonts /run/host/user-fonts <- ~/.local/share/fonts /run/host/fonts-cache <- /usr/lib/fontconfig/cache /run/host/user-fonts-cache <- ~/.cache/fontconfig ``` For fontconfig: https://bugs.freedesktop.org/show_bug.cgi?id=101889 https://github.com/flatpak/flatpak/issues/589 It supports relocatable cache. ``` FcConfigGetFontDirs( config ) -> /run/host/user-fonts/test,... FcDirCacheRead( /run/host/user-fonts/test, ... ) -> FcCacheCopySet -> pattern FcPatternGetString( pattern, FC_FILE, 0, &filename ) -> ~/.local/share/fonts/test/test.ttf ``` For wine: ``` FcPatternGetString -> unix_name -> add_unix_face( unix_name, ... ) ``` The valid file path for flatpak is `/run/host/user-fonts/test/test.ttf`. `~/.local/share/fonts/test/test.ttf` does not exist in flatpak sandbox. Add a check for this, and switch to right path. Test: ``` flatpak install org.winehq.Wine LANG=zh_CN.UTF-8 flatpak run org.winehq.Wine winecfg ``` ![image](/uploads/6679b2771e3400b02903faa308a1d1c5/image.png) -- v3: Support relocatable fontconfig cache https://gitlab.winehq.org/wine/wine/-/merge_requests/2081

3 7