January 2024 - Wine-GitLab - list.winehq.org

[PATCH v10 0/2] MR4720: Implement test_continue() for amd64
by Dāvis Mosāns Jan. 23, 2024

Jan. 23, 2024

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

2 2

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

Jan. 23, 2024

-- 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) Jan. 23, 2024

Jan. 23, 2024

-- 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) Jan. 23, 2024

Jan. 23, 2024

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

[PATCH 0/1] MR4919: dssenh: Finalize the hash if necessary in CPVerifySignature().
by Hans Leidekker (＠hans) Jan. 23, 2024

Jan. 23, 2024

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

2 1

[PATCH v2 0/6] MR4904: dinput/tests: Add tests for HID keyboard/mouse and touchscreen.
by Rémi Bernon Jan. 23, 2024

Jan. 23, 2024

-- v2: dinput/tests: Add a test with a virtual HID touch screen. include: Add more HID digitizer usage definitions. dinput/tests: Add a test with a virtual HID keyboard. dinput/tests: Add a test with a virtual HID mouse. dinput/tests: Enforce ordering of concurrent read IRPs. dinput/tests: Introduce a new helper to create a foreground window. https://gitlab.winehq.org/wine/wine/-/merge_requests/4904

2 8

[PATCH v8 0/1] MR4672: include: Add msdelta.h header file.
by Vijay Kiran Kamuju (＠infyquest) Jan. 23, 2024

Jan. 23, 2024

Add the header file needed for implementation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56007 -- v8: https://gitlab.winehq.org/wine/wine/-/merge_requests/4672

3 2

[PATCH 0/1] MR4916: winex11: Sync with gdi_display before closing the threads display.
by Rémi Bernon Jan. 23, 2024

Jan. 23, 2024

This is a synchronization point that was missed in a6bc5f34b87393e04ff46659f518f2e7094cc7e4, as XCloseDisplay implies the destruction any every remaining top-level window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4916

1 1

[PATCH v2 0/2] MR4876: user32/tests: Test GetKeyboardLayout() in CJK locales.
by Zhiyi Zhang (＠zhiyi) Jan. 23, 2024

Jan. 23, 2024

GetKeyboardLayout() is also tested manually on Windows 10 with Korean, Chinese, and Japanese IME activated. -- v2: win32u: Don't set the high word of keyboard layout to 0xe001 in CJK locales. user32/tests: Test keyboard layout in CJK locales. https://gitlab.winehq.org/wine/wine/-/merge_requests/4876

5 10

[PATCH 0/1] MR4914: ntdll: Avoid sending context in wait_suspend() when not required.
by Paul Gofman (＠gofman) Jan. 23, 2024

Jan. 23, 2024

Currently usr1_handler always delivers the context to server. With AVX enabled the single context size is around 1k (while there are two of those for wow64). I am now working on a more generic xstate support in contexts (mostly motivated by AVX512), with AVX512 the single context to be transferred to server is ~1k bigger. The context is needed to be passed to the server from usr1_handler only for NtGetContextThread, NtSetContextThread and NtSuspendThread handling (e. g., when stop_thread is called on the server). The vast majority of usr1_handler usage is for kernel APCs (e. g., APC_ASYNC_IO involved in every async operation) that don't need the thread context transferred to the server and back. My measurements of single SERVER_START_REQ( select ) in server_select() shows that the turnaround time of the request with the context (on native x64 without wow context) is almost two times bigger on average when currently supported AVX context is involved (that is, on every usr1_handle invocation on a machine supporting AVX). So, this patch is expected to increase the time of relatively rare calls which actually need contexts by roughly 50% but decrease the turnaround time of frequent calls involving system APCs by 50%. The difference will be more in favour of this patch once huge AVX512 contexts are added. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4914

3 2