FFXIV depends on this. It calls SetFullscreenState when it receives WM_WINDOWPOSCHANGED. Through luck the recursion aborts after two calls. The user-visible bug is that after leaving fullscreen, the game's window is still TOPMOST because we overwrite the stored pre-fullscreen window flags.
--
v3: dxgi/tests: Test nested SetFullscreenState from the same thread.
dxgi/tests: Test nested fullscreen application from different thread.
dxgi: Catch nested SetFullscreenState invocations.
dxgi: Unlock the wined3d mutex after storing the new target.
dxgi/tests: Run test_swapchain_window_messages on d3d12.
dxgi/tests: Run test_resize_target_wndproc on d3d12 too.
dxgi/tests: Fix UnregisterClass call in test_resize_target_wndproc.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1964
--
v5: dxgi: Reset the back buffer index to zero on ResizeBuffers().
dxgi/tests: Test that ResizeBuffers() resets the back buffer index to zero.
dxgi: Always assume that a D3D12 swapchain always uses user images.
dxgi: Immediately error out when creating a D3D12 swapchain on a non-immediate queue.
d3d12/tests: Test that D3D12 swapchains can only be created on direct command queues.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2296
A couple of tests (ntdll, psapi, dbghelp) were failing when running
on Windows 11 platform.
These tests were creating a new process out of
c:\windows\syswow64\notepad.exe and expecting a wow64 32bit child
process.
Under Windows 11, notepad has been migrated into the UWP framework
and the operation above creates a 64bit process.
This series replace all the cases above with msinfo32.exe which
still have the properties we expected for such an application.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2252
The idea I have is to use this module to declare class stubs until there is a good reason to split them to dedicated modules. WinRT modules aren't usually loaded directly, and instead the registry is queried to figure which module to load for which class.
This would help avoiding unnecessary proliferation of stub WinRT modules, while at the same time allowing to factor WinRT foundation code (such as vector / async, etc...) between the modules that seem to deserve to be implemented separately.
The relevant classes could then be split out to dedicated modules on a as-needed basis, when they get fleshed out.
--
v2: winewinrt: Move Vector<HSTRING> from windows.media.speech.
windows.media.speech: Use Vector<IInspectable> from winewinrt.
winewinrt: Rename Vector<IInspectable> structs and methods.
winewinrt: Move Vector<IInspectable> from windows.gaming.input.
winewinrt: Introduce new WinRT common module.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2298
--
v5: winegstreamer: Implement ProcessInput and ProcessOutput for WMV decoder DMO.
winegstreamer: Create wg_transform for WMV decoder.
winegstreamer: Better handle framerate.
winegstreamer: Add format field to wmv wg_format.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2258
Needed by the VR games Forewarned and Überlaüfer.
I had to put the parameters of the header functions on newlines because they're too long. Did the same for the other headers for consistency. windows.security.cryptography.idl uses a similar style.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2292
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v19: windows.media.speech: Implement Vosk create and release functions in the unixlib.
windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine.
windows.media.speech/tests: Get rid of duplicated hresult.
windows.media.speech: Add unixlib stub.
windows.media.speech: Add Vosk checks to autoconf.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
This change only implements case-sensitivity of technique keywords and related checks when corresponding profile is used. My immediate plan is to add some synthetic type for technique variables, for example as {object, void}, then add named techniques as variables. This is useful because these names are participating in global scope, and should not collide with normal variables. After that "pass_list" will be split, at least in two variants because of how much d3d9 syntax differs. Some trivial changes will be need later to have some top level fx compilation helper that considers only fx objects and calls ps/vs/gs compiler to create inner shader blobs on same original source.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/111