February 2023 - Wine-GitLab

[PATCH 0/3] MR2133: Draft: ntdll/tests: Minimize the stack size for test_tp_multi_wait().
by Francois Gouget (＠fgouget) Feb. 14, 2023

Feb. 14, 2023

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

4 7

[PATCH 0/2] MR2182: ntdll: Use the thread pool stack information.
by Francois Gouget (＠fgouget) Feb. 14, 2023

Feb. 14, 2023

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

2 2

[PATCH 0/2] MR2180: winetest: Avoid an infinite loop in vstrfmtmake() when the format is NULL.
by Francois Gouget (＠fgouget) Feb. 14, 2023

Feb. 14, 2023

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

2 2

[PATCH 0/1] MR2178: winevulkan: Add a trailing linefeed to some FIXME() thunk messages.
by Francois Gouget (＠fgouget) Feb. 14, 2023

Feb. 14, 2023

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

2 1

[PATCH 0/1] MR90: vkd3d-shader/hlsl: Improve mul vs dp* selection for dot().
by Nikolay Sivov (＠nsivov) Feb. 14, 2023

Feb. 14, 2023

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

4 3

[PATCH v10 0/10] MR66: vkd3d-shader/hlsl: Broaden resources support v2 (PART 1).
by Francisco Casas (＠fcasas) Feb. 14, 2023

Feb. 14, 2023

First part of v2 of !27, which aims to: * Allow allocation of variables of complex types that contain both numerics and objects across multiple register sets (regsets). * Support the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions. * Support for arrays of resources for both SM1 and SM4 (not to be confused with the resource-arrays of SM 5.1, which can have non-constant indexes). * Support for resources declared within structs. * Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of structs. * Imitate the way the native compiler assigns the register indexes of the resources on allocation, which proved to be the most difficult thing. * Support for object components within complex input parameters. * Small fixes to corner cases. This part consists on parsing the `tex2D()` and `tex3D()` intrinsics and beginning to support the allocation of variables across multiple regsets. The whole series, is on my [master6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6) branch. -- v10: vkd3d-shader/hlsl: Allocate register reservations in a separate pass. vkd3d-shader/hlsl: Respect object reservations even if the object is unused. tests: Test allocation of unused objects. vkd3d-shader/hlsl: Allocate objects according to register set. vkd3d-shader/hlsl: Keep an hlsl_reg for each register set in hlsl_ir_var. vkd3d-shader/hlsl: Store the type's register size for each register set. vkd3d-shader/hlsl: Leave offset empty for array and struct derefs. vkd3d-shader/hlsl: Parse the tex3D() intrinsic. vkd3d-shader/hlsl: Parse the tex2D() intrinsic. vkd3d-shader/hlsl: Avoid segfault on missing sampler. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66

4 11

[PATCH 0/5] MR2177: win32u: Get monitor name from EDID when possible
by Paul Gofman (＠gofman) Feb. 14, 2023

Feb. 14, 2023

There are two common ways I observe how games get monitor name to display: 1. Registry key under Enum/Display (also present in EnumDisplayDevicesA result for monitors). On Windows this key is derived from edid as 'Manufacturer ID' (3 letters) combined with "Manufacturer product code" (4 hex digits). We currently have 'Default_Display' there for all the displays; 2. DisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME). Windows sets friendlyNameFromEdid flag and returns a name from 'EDID Display Descriptor' with code 0xfc ("Display name"). As far as I could see by searching through the Windows registry this name doesn't seem to be explicitly present anywhere in registry (besides binary raw edid of course). The first patch removes name from the gdi driver's display structure. Now none of the drivers set anything genuine there. x11 and winemac always end up with "Generic Non-Pnp Monitor" string, wineandroid sets NULL there and "Generic Non-Pnp Monitor" is set in win32u in this case. That "Generic Non-Pnp Monitor" goes to "DeviceDesc" registry value. While our value doesn't match Windows string exactly, Windows also doesn't have any meaningful name under DeviceDesc (and contains "Generic Non-Pnp Monitor" as a part of it). So this patch is essentially a no-op currently. Going forward my idea is that we just want to have edid from drivers. If the raw one is not available we can generate fallback one ourselves based on the info about the monitor we might have from elsewhere in the drivers. My motivation is: - EDID is sometimes queried by apps directly, and it is better to provide a true one or a synthetic one with as much of accurate info as possible / reasonable; - There is more info in EDID, e. g., colorimetry for HDR support in d3d. As far as I can tell, there is no documented way to query HDR info on Windows besides dxgi interfaces (which in case on Wine are based on gdi drivers for such things and can hardly become a genine source of such info in Wine) and WinRT interface (for which I don't know where it takes the info on Windows but we probably don't want to make it a lower level source of such info in Wine). The alternative would be, instead of basing higher level win32u on EDID, parse EDID in drivers instead and add all the necessary info into gdi_monitor structure (instead of removing display name from there), but so far it seems less straightforward to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2177

2 5

[PATCH v5 0/1] MR2175: oleaut32: fix VarAbs function for BSTR with positive values
by Jason Millard (＠jsm174) Feb. 13, 2023

Feb. 13, 2023

While working in vbscript, I noticed abs on a `BSTR` value with a positive number would come back with an invalid value. Given the following script: ``` Dim x x = "30000" Debug.Print "x" & "=" & abs(x) ``` Outputs: ``` Script.Print 'x=3.08221696253945E-314' ``` After debugging, `pVarIn` gets the R8 value but is never shallow copied into `pVarOut`. I'm not sure how to write a test case in `oleaut32`, so I included a test case in `vbscript`. -- v5: oleaut32: fix VarAbs function for BSTR with positive values https://gitlab.winehq.org/wine/wine/-/merge_requests/2175

2 1

[PATCH v4 0/1] MR2175: oleaut32: fix VarAbs function for BSTR with positive values
by Jason Millard (＠jsm174) Feb. 13, 2023

Feb. 13, 2023

While working in vbscript, I noticed abs on a `BSTR` value with a positive number would come back with an invalid value. Given the following script: ``` Dim x x = "30000" Debug.Print "x" & "=" & abs(x) ``` Outputs: ``` Script.Print 'x=3.08221696253945E-314' ``` After debugging, `pVarIn` gets the R8 value but is never shallow copied into `pVarOut`. I'm not sure how to write a test case in `oleaut32`, so I included a test case in `vbscript`. -- v4: oleaut32: fix VarAbs function for BSTR with positive values https://gitlab.winehq.org/wine/wine/-/merge_requests/2175

3 2

[PATCH v3 0/1] MR2175: oleaut32: fix VarAbs function for BSTR with positive values
by Jason Millard (＠jsm174) Feb. 13, 2023

Feb. 13, 2023

While working in vbscript, I noticed abs on a `BSTR` value with a positive number would come back with an invalid value. Given the following script: ``` Dim x x = "30000" Debug.Print "x" & "=" & abs(x) ``` Outputs: ``` Script.Print 'x=3.08221696253945E-314' ``` After debugging, `pVarIn` gets the R8 value but is never shallow copied into `pVarOut`. I'm not sure how to write a test case in `oleaut32`, so I included a test case in `vbscript`. -- v3: oleaut32: fix VarAbs function for BSTR with positive values https://gitlab.winehq.org/wine/wine/-/merge_requests/2175

3 2