Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's.
While MRs !359 and !360 implement getting the ContainerID of the IMMDevice, this MR implements getting the ContainerID from the HID device.
As for !360, I marked this MR as a draft because I understand that the way the ���GUID��� is generated is far from …
[View More]ideal. Furthermore, there is code duplication with !360 in the way the container's sysfspath is found and how a GUID is generated from it, so moving that part elsewhere would make sense. But as for !360, I think I will need help with those tasks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/535
[View Less]
And discard irrelevant parts in select request. We currently store something in CTX_PENDING and ignore it later in select request if we're currently running in wow context.
--
v5: ntdll/tests: Add tests for setting context on unsuspended thread.
server: Store both contexts in pending context object.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3566
Which I intend to use to support (and rewrite) instrument / wave downloads.
--
v2: dmusic: Implement IDirectMusicPortDownload_GetBuffer.
dmusic: Implement IDirectMusicPortDownload_(Download|Unload).
dmusic: Implement IDirectMusicPortDownload_AllocateBuffer.
dmusic: Implement synth port IDirectMusicPortDownload_GetDLId.
dmusic: Rename IDirectMusicDownloadImpl method prefix to download.
dmusic: Move IDirectMusicDownloadImpl struct to where it is used.
dmusic:…
[View More] Simplify and cleanup IDirectMusicDownload constructor.
dmusic: Always return S_FALSE from DllCanUnloadNow.
dmusic/tests: Test IDirectMusicPort_(Download|Unload)Instrument.
dmusic/tests: Test IDirectMusic(Port)Download interfaces.
include: Fix incorrect IDirectMusicPortDownload_Unload macro.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3722
[View Less]
This MR replaces `vkd3d_shader_register.immconst_type` with `vkd3d_shader_register.dimension` which is intended for all register types and not just immconsts.
This dimension is parsed in tpf.c, and initialized according to the register type in d3dbc.c.
Having this field in vkd3d_shader_register allows us to avoid hardcoding special cases for the register dimensions when writing sm4 bytecode (e.g. for the sampler src register in gather instructions). Also, it allows for some fixes to d3d_asm.…
[View More]c, which are introduced in part 2 (https://gitlab.winehq.org/fcasas/vkd3d/-/commits/add_vkd3d_reg_dim).
--
v2: vkd3d-shader: Initialize registers using shader_register_init().
vkd3d-shader: Make shader_register_init() extern.
vkd3d-shader/d3dbc: Initialize register dimension for all register types.
vkd3d-shader/tpf: Parse register dimension for all register types.
vkd3d-shader: Turn vkd3d_shader_register.immconst_type into vkd3d_shader_register.dimension.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/319
[View Less]
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could …
[View More]very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.
--
v2: vkd3d-shader: Validate source parameters.
vkd3d-shader: Validate destination parameters.
vkd3d-shader: Check that registers are valid.
vkd3d-shader: Check that instructions are valid.
vkd3d-shader: Introduce a boilerplate to validate the generated IR.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
[View Less]
The "GdiInterop" is a sample application (source code is avaiable in [Github][source_code], relative guide in [MSDN][msdn_guide]) that demostracts how to display DirectWrite text on a GDI surface. After set dpi to 168 in `winecfg`, and run sample application with wine, the font size is normal, but the position of glyph is incorrect.
| Dpi: 96 | Dpi: 168 |
|:----------------:|:-----------------:|
| ![ss1][sc_96dpi] | ![ss2][sc_168dpi] |
There is the sample application after …
[View More]compile: [Release_x64.tar.gz](/uploads/c70e32824efcaa5d16ab39bbb4b86e30/Release_x64.tar.gz)
After change transform matrix that pass to `IDWriteFactory7_CreateGlyphRunAnalysis`, it can display glyph correctly.
[source_code]: https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/Win7…
[msdn_guide]: https://learn.microsoft.com/en-us/windows/win32/directwrite/render-to-a-gdi…
[sc_96dpi]: /uploads/59cc343cfaa025f4ff4c32a84ab8cfeb/图片.png
[sc_168dpi]: /uploads/938be653362bb6ac58471b69ab66099a/图片.png
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3718
[View Less]
---
See the added comment for details what is going on.
--
v4: d3d9/tests: Wait longer in test_occlusion_query for software renderers.
d3d9/tests: The device window may restore behind our back in test_wndproc.
d3d9/tests: Work around test_reset_fullscreen failing on gitlab CI.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3565
--
v3: dmsynth/tests: Test DirectMusicSynth class in isolation.
dmsynth/tests: Test DirectMusicSynthSink class in isolation.
dmsynth/tests: Import and use a check_interface helper.
dmsynth/tests: Avoid dynamic format string.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3675
--
v2: dmsynth/tests: Test DirectMusicSynth class in isolation.
dmsynth/tests: Test DirectMusicSynthSink class in isolation.
dmsynth/tests: Import and use a check_interface helper.
dmsynth/tests: Avoid dynamic format string.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3675
Since Yousician's last update, it was throwing an error when initialising audio output. Unfortunately I don't have access to the old version, but they seem to have dropped win<10 support, and are using only IAudioClient3_InitializeSharedAudioStream. They also use IDeviceTopology to get the type of the first output connector.
This is the bare minimum I needed to get it working.
--
v9: mmdevapi: add stub for IDeviceTopology
mmdevapi/tests: add test for IDeviceTopology
…
[View More]mmdevapi: implement IAudioClient3_InitializeSharedAudioStream
mmdevapi/tests: add test for AudioClient3_InitializeSharedAudioStream
https://gitlab.winehq.org/wine/wine/-/merge_requests/3554
[View Less]
Sourced from shared/ksarm64.h in the Windows SDK. This header only has offsets and lacks any datatype info, so they may be incorrect.
--
v2: include: Add CHPEV2 CPU area definitions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3717
Fixes a bug where the statusbar doesn't correctly paint when the parent window is resized. This can be seen in wine notepad.
--
v6: comctl32/status: Invalidate entire status bar on WM_SIZE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3667
GCC expects __stack_chk_fail() to be noreturn[^1]. Returning from
__stack_chk_fail() can thus lead to subtle failures.
When crashing, use a volatile NULL pointer dereference. Ideally we
would like to "abort()" here, but doing so would require two more
syscall definitions just for a cold function. After all, the function
isn't even used at all if -fno-stack-protector is specified.
Also, don't say "stack smashing" (unlike glibc). The preloader
currently initializes the stack canary value to …
[View More]a fixed value (0), which
serves little value in protecting against actual buffer overrun attacks.
[^1]: https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gccint/Stack-Smashing-Protection.h…
--
v2: loader: Don't return from __stack_chk_fail() stub in preloader.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3708
[View Less]
GCC expects __stack_chk_fail() to be noreturn[^1]. Returning from
__stack_chk_fail() can thus lead to subtle failures.
When crashing, use a volatile NULL pointer dereference. Ideally we
would like to "abort()" here, but doing so would require two more
syscall definitions just for a cold function. After all, the function
isn't even used at all if -fno-stack-protector is specified.
Also, don't say "stack smashing" (unlike glibc). The preloader
currently initializes the stack canary value to …
[View More]a fixed value (0), which
serves little value in protecting against actual buffer overrun attacks.
[^1]: https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gccint/Stack-Smashing-Protection.h…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3708
[View Less]
This can then be used to run tests in an appx context, for instance for https://gitlab.winehq.org/wine/wine/-/merge_requests/3548
--
v2: windows.applicationmodel/tests: Test executing a WinRT package application.
windows.applicationmodel/tests: Test IPackageManager_RegisterPackageAsync.
makedep: Support generating .exe TESTDLL resources.
makedep: Use #pragma makedep testdll for TESTDLL resources.
windows.applicationmodel/tests: Add some IPackageManager tests.
…
[View More]windows.applicationmodel: Add stub DLL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3643
[View Less]
Now that we can write HLSL intrinsics in HLSL, cleaning up missing
functions becomes much easier.
This commit also extends the trigonometry tests a little bit to make
sure that tan works right.
--
v3: vkd3d-shader/hlsl: Implement intrinsic tan.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/321
Now that we can write HLSL intrinsics in HLSL, cleaning up missing
functions becomes much easier.
This commit also extends the trigonometry tests a little bit to make
sure that tan works right.
--
v2: vkd3d-shader/hlsl: Implement intrinsic tan.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/321
--
v2: mmdevapi: Move name string duplication in MMDevice_Create() from caller.
mmdevapi: Simplify load_driver_devices() by combining loops and removing unneeded allocation(s).
https://gitlab.winehq.org/wine/wine/-/merge_requests/3658
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v24: ntdll: wake up SRWLOCK waiters by thread id
ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v23: ntdll: wake up SRWLOCK waiters by thread id
ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v18: ntdll: allow SRWLOCKs to be quickly re-acquired
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v22: ntdll: wake up SRWLOCK waiters by thread id
ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v21: ntdll: wake up SRWLOCK waiters by thread id
ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v20: ntdll: wake up SRWLOCK waiters by thread id
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
On Thu Aug 31 17:45:59 2023 +0000, Zebediah Figura wrote:
> That's kind of surprising; win32 futexes are fair and we're using them
> internally. Why aren't our SRW locks fair?
So it's only unfair for a very specific test. It's a simple test where I just have threads constantly acquiring and releasing exclusive SRWLOCKs in s loop. What I observed is threads can loop back and immediately re-acquire the lock after releasing it, causing one thread at a time to dominate the lock.
This cannot …
[View More]happen with this MR. But if I make the change to allow it, this MR would get a lot faster.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_44021
[View Less]
Welcome to Princeland depends on that.
Added tests show that NtQueryDirectoryFile mask handling is different from FindFirstFile (even though it doesn't quite match Windows too, the details are different, e. g., on Windows mask "*." will select file "ea" with FindFirstFile but not with NtQueryDirectoryFile). So the correct way is probably do the wildcards matching in kernelbase directly without relying on NtQueryDirectoryFile.
Having files not apprearing in the output of FindFirstFile is not …
[View More]obvious on Windows as well as the mask matches generated short names and that might provide an unexpected output. However, the part with not returning the files with extension when mask requires so looks rather straightforward and depending on that is not probably supposed to semi-randomly break on Windows. While checking the tests before after the changes I was checking that besides not introducing new TODOs no test files are appearing in the missing part in todo tests (as starting to incorrectly missing some files in the output has an obvious regression potential).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3697
[View Less]
Now that we can write HLSL intrinsics in HLSL, cleaning up missing
functions becomes much easier.
This commit also extends the trigonometry tests a little bit to make
sure that tan works right.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/321
On Thu Aug 31 13:00:04 2023 +0000, Yuxuan Shui wrote:
> So is the native SRWLOCK. I can make a small change to this MR which
> makes it less fair, but brings the performance on par with native (for
> this one test that I have).
That's kind of surprising; win32 futexes are fair and we're using them internally. Why aren't our SRW locks fair?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43978
On Thu Aug 31 12:35:40 2023 +0000, Yuxuan Shui wrote:
> Another observation is current SRWLOCK is pretty unfair (again, in this
> one test).
So is the native SRWLOCK. I can make a small change to this MR which makes it less fair, but brings the performance on par with native (for this one test that I have).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43966
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could …
[View More]very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
[View Less]
On Thu Aug 31 12:26:04 2023 +0000, Yuxuan Shui wrote:
> I see, in current version all threads Waits on the same Address, so the
> address' futex queue is contended. Threads are spinning on
> `queue->lock`, so there is a chance for the lock to be released and the
> threads never actually call `futex` (in this synthetic test anyway).
> Whereas with this MR threads are generally waiting on different
> addresses, so they always enter futex.
Another observation is current …
[View More]SRWLOCK is pretty unfair (again, in this one test).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43962
[View Less]
On Thu Aug 31 12:25:16 2023 +0000, Yuxuan Shui wrote:
> oh my, native SRWLOCK is really really fast. Even when compared to the
> current, no wait list version.
> I noticed with exclusive locks, current SRWLOCK would show >100% CPU
> usage. I think this means there are some spinning going on?
I see, in current version all threads Waits on the same Address, so the address' futex queue is contended. Threads are spinning on `queue->lock`, so there is a chance for the lock to be …
[View More]released and the threads never actually call `futex` (in this synthetic test anyway).
Whereas with this MR threads are generally waiting on different addresses, so they always enter futex.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43958
[View Less]
Running the tests on AMD requires rebuilding the Docker image, unfortunately, so the pipelines for this MR won't work until the MR itself is accepted (and the image is regenerated).
--
v9: ci: Briefly document the CI setup.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/318
oh my, native SRWLOCK is really really fast. Even when compared to the current, no wait list version.
I noticed with exclusive locks, current SRWLOCK would show >100% CPU usage. I think this means there are some spinning going on?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43949
Running the tests on AMD requires rebuilding the Docker image, unfortunately, so the pipelines for this MR won't work until the MR itself is accepted (and the image is regenerated).
--
v8: ci: Briefly document the CI setup.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/318
--
v5: mshtml: Implement Cycle Collection for XMLHttpRequest.
mshtml: Implement Cycle Collection for HTMLPerformanceTiming.
mshtml: Move PerformanceTiming related fields to the window.
mshtml: Move HTMLPerformanceNavigation related fields to the window.
mshtml: Implement Cycle Collection for inner windows.
mshtml: Get rid of NULL checks for the dispex vtbl.
mshtml: Implement Cycle Collection for outer windows.
mshtml: Implement Cycle Collection for …
[View More]HTMLLocation.
mshtml: Separate the HTMLLocation from the outer window.
mshtml: Actually traverse the object-specific edges.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3645
[View Less]