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
--
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
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
--
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
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