January 2024 - wine-gitlab

[PATCH v5 0/2] MR4022: wined3d: Expose the image view usage to the Vulkan driver.
by Giovanni Mascellani (＠giomasce) 23 Jan '24

23 Jan '24

Some driver, e.g. MoltenVK, fail in some cases if the image view usage is too broad or unknown. -- v5: wined3d: Expose the image view usage for non-default views. https://gitlab.winehq.org/wine/wine/-/merge_requests/4022

3 4

Re: [PATCH v2 0/1] MR4834: ntdll: NtQuerySystemInformation(SystemProcessorPerformanceInformation) fix return value
by Dāvis Mosāns (davispuh) (＠davispuh) 23 Jan '24

23 Jan '24

On Tue Jan 23 13:57:14 2024 +0000, Fabian Maurer wrote: > It copies but then gives `STATUS_INFO_LENGTH_MISMATCH`? And returning > `STATUS_ACCESS_VIOLATION` has priority over `STATUS_INFO_LENGTH_MISMATCH`? > Not saying you're wrong, just wondering. Would you mind adding tests for that? This is current behavior on Windows 10 22H2: ``` NULL buffer and size = 0 -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) NULL buffer and size > 0 -> STATUS_ACCESS_VIOLATION, ReturnLength=0 valid buffer and size = 0 -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size > 0 -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size < 1*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size = 1*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_SUCCESS, ReturnLength= 1*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size > 1*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size = 2*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_SUCCESS, ReturnLength= 2*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size < cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size = cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_SUCCESS, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) valid buffer and size > cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_INFO_LENGTH_MISMATCH, ReturnLength=cpus*sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) ``` Wine has few differences regarding this but here this MR fixes only single case ``` size % sizeof(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) -> STATUS_SUCCESS ``` Handling of `STATUS_ACCESS_VIOLATION` and `ReturnLength` is not changed. And regarding test, actually Wine already has such test, see [info.c#752](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/te… ```c ok( status == STATUS_SUCCESS || status == STATUS_INFO_LENGTH_MISMATCH /* vista */, "Expected STATUS_SUCCESS or STATUS_INFO_LENGTH_MISMATCH, got %08lx\n", status); ``` It looks like before Vista it returned `STATUS_SUCCESS` which is current Wine implementation, but since Vista it started to return `STATUS_INFO_LENGTH_MISMATCH` instead -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4834#note_58632

1 0

[PATCH v2 0/3] MR589: vkd3d-shader/dxil: Implement DX intrinsic SplitDouble.
by Conor McCarthy (＠cmccarthy) 23 Jan '24

23 Jan '24

-- v2: vkd3d-shader/spirv: Handle split double bitcast in spirv_compiler_emit_load_ssa_reg(). tests/shader-runner: Add split double test to 64-bit cast tests. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/589

3 6

[PATCH 0/1] MR4920: ntdll: Fix KiUserCallbackDispatcher on arm
by Martin Storsjö (＠mstorsjo) 23 Jan '24

23 Jan '24

This was broken in 78c2b7dfe2f2d5d76400564be547fd8287d62d67. Signed-off-by: Martin Storsjö <martin(a)martin.st> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4920

3 2

[PATCH 0/1] MR4913: gdi32: Ignore Datatype when StartDoc is called
by Brendan McGrath (＠redmcg) 23 Jan '24

23 Jan '24

This change causes StartDoc to ignore the requested DataType and to always use EMF. This fixes a printing issue within Quicken Classic. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4913

5 4

[PATCH 0/3] MR591: vkd3d-shader/dxil: Do not use ascii_strcasecmp().
by Conor McCarthy (＠cmccarthy) 23 Jan '24

23 Jan '24

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

3 5

[PATCH v10 0/2] MR4720: Implement test_continue() for amd64
by Dāvis Mosāns (davispuh) (＠davispuh) 23 Jan '24

23 Jan '24

Currently there is `NtContinue()` test only for `aarch64` so implement it for amd64 aswell. This implementation is very similar to `aarch64` and it's very basic test. It doesn't change/test `ContextFlags` so it won't catch https://bugs.winehq.org/show_bug.cgi?id=56050 but that can be implemented later on top of this. -- v10: Apply 3 suggestion(s) to 1 file(s) https://gitlab.winehq.org/wine/wine/-/merge_requests/4720

3 2

[PATCH v2 0/4] MR584: vkd3d-shader/dxil: Support for isinf, isnan and isfinite.
by Conor McCarthy (＠cmccarthy) 23 Jan '24

23 Jan '24

-- v2: vkd3d-shader/spirv: Handle the ISINF and ISNAN instructions in spirv_compiler_emit_alu_instruction(). vkd3d-shader/spirv: Implement the ISFINITE instruction. tests/shader-runner: Add tests for floating point special values. vkd3d-shader/dxil: Handle floating point special value comparisons in sm6_parser_emit_dx_unary(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/584

3 5

[PATCH 0/1] MR4918: bcrypt: Fix private data size in wow64 thunks.
by Hans Leidekker (＠hans) 23 Jan '24

23 Jan '24

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

3 2

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 23 Jan '24

23 Jan '24

On Mon Jan 22 01:58:30 2024 +0000, Zhiyi Zhang wrote: > > For what it's worth, I haven't seen any adapter to report TRUE here on > Windows. So it might be safer to default to FALSE instead. > That's fine. You can add tests for this as well. I'm trying to follow the suggestion to read SetupAPI registry data but I'm having some difficulties, with the major one being: I'm not actually sure where that data is. Your sample code doesn't seem to read the registry and just returns/enumerates an empty device set. What am I missing here? On the other hand, I had a look at where win32u writes stores information when `add_gpu` is called and figured that I can (probably) use whatever this function writes. This gives me two possible leads: 1. `HKML\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\${gpu_id}`. Although easier to enumerate, this doesn't have the most important piece of data: GPU LUID, which I'd have to retrieve from the second key anyway and it doesn't have any links to second keys I could use to open it directly, so it's not very viable for my purposes here. 2. `HKML\System\CurrentControlSet\Enum\PCI\${pci_id}\${gpu_idx}`. This does have GPU LUID I can easily retrieve but some of the other data is kept only as wide strings which I'd need to parse if I wanted to use them (if only for bookkeeping purposes). E.g. the only way I see to retrieve PCI vendor and device IDs would be parsing `${pci_id}` but as far as I can tell, I can't just use `snwscanf` to process 2-byte wide strings in Unixlibs. Of course, I could pick the second version and read only the LUID while ignoring PCI IDs and GPU ID/index completely, but I'd like to ask first if it's correct thing to do before I commit to that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58603

1 0

2025

2024

2023

2022

wine-gitlab January 2024