HDR in Control (a patch released by a developer post-launch, not
actually in the game sadly) tries to set a video mode with
DXGI_FORMAT_R16G16B16A16_FLOAT.
This seemingly works on Windows, and based on FindClosestMode etc
documentaton, this seems required to work for any format that scanout
it supported for.
It's really not like the bpp is meaningful on Windows with the
distinction of 8bit and 10bit not working in GDI modes at all.
Nor does it end up actually setting anything on Linux/Deck where
modesets are emulated.
So, treat DXGI_FORMAT_R16G16B16A16_FLOAT as 32bpp so the
FindClosestMatchingMode and EnterFullscreenMode calls succeed.
For two reasons:
1) Some apps will only enable or attempt to enable HDR if BitsPerColor is >= 10.
2) Encouraging apps to create 10-bit swapchains for use in hardware dithering on Gamescope/Steam Deck and to have more precision thru scanout color transforms
Disable stdcall aliasing and enable kill-at to ensure our exported
functions don't have the @8, @40, etc suffixes.
This still keeps `--enable-stdcall-fixup` as otherwise the linker can
get confused trying to find exports from the .def. This does not result
in aliases being added, just for them to be found to add to the export
table.
This also switches d3d11 to use the MinGW provided dxgi.lib for linking
and d3d10 to use the MinGW provided d3d11.lib for linking.
Unfortunately the .a's we output seem to still have the @blah that we
killed so we cannot use them for internal linkage since using kill-at.
Tested that what we get out of MinGW now is what we want with dllexp.
Supercedes: #3590
Exports
```
➜ build git:(master) ✗ winedump -j export src/dxgi/dxgi.dll
Contents of src/dxgi/dxgi.dll: 129505860 bytes
Name: DXGI.DLL
Characteristics: 00000000
TimeDateStamp: 64C97A2D Tue Aug 1 22:33:33 2023
Version: 0.00
Ordinal base: 9
# of functions: 9
# of Names: 5
Addresses of functions: 00423028
Addresses of name ordinals: 00423060
Addresses of names: 0042304C
Entry Pt Ordn Name
00007C17 9 CreateDXGIFactory
00007BF3 10 CreateDXGIFactory1
00007B62 11 CreateDXGIFactory2
00007C3B 16 DXGIDeclareAdapterRemovalSupport
00007CD8 17 DXGIGetDebugInterface1
Done dumping src/dxgi/dxgi.dll
```
```
➜ build git:(fix-stdcall-32-bit) winedump -j export src/d3d11/d3d11.dll
Contents of src/d3d11/d3d11.dll: 263021637 bytes
Name: D3D11.DLL
Characteristics: 00000000
TimeDateStamp: 64C97A2E Tue Aug 1 22:33:34 2023
Version: 0.00
Ordinal base: 18
# of functions: 7
# of Names: 4
Addresses of functions: 005E3028
Addresses of name ordinals: 005E3054
Addresses of names: 005E3044
Entry Pt Ordn Name
00020045 18 D3D11CoreCreateDevice
000200AA 22 D3D11CreateDevice
0002010E 23 D3D11CreateDeviceAndSwapChain
0002025F 24 D3D11On12CreateDevice
Done dumping src/d3d11/d3d11.dll
```
Import of DXGI in D3D11
```
offset 005e1014 dxgi.dll
Hint/Name Table: 005E408C
TimeDateStamp: 00000000 (Thu Jan 1 01:00:00 1970)
ForwarderChain: 00000000
First thunk RVA: 005E4300
Thunk Ordn Name
005e4300 4 CreateDXGIFactory1
```
This trips up Stalker Anomaly for some reason, but initializing an output
is not meaningful anyway in this situation since we either know the output
in question already, or we don't and it cannot be in a non-default state.
Closes#3531.
If there are monitors on the system that are not associated with
any adapter, enumerate all monitors for all adatpers. May solve
some issues if device filter options are used on multi-GPU systems.
Death Stranding: Director's Cut crashes if HDR was last enabled in-game and CheckColorSpaceSupport reports support for HDR but it is not globally enabled in DXGIOutput::GetDesc1's ColorSpace.
It seems safer to just lock HDR behind an option to avoid any teething issues like this. It sucks, but it also makes sense in a way.
vkd3d-proton 2.8 released last year with support for the new swapchain
interface.
No need to keep support for this legacy interface hanging around when
it complicates adding DxgiOptions support to the swapchain.
Unreal Engine 4 titles use AGS/NVAPI to try and enable
HDR globally.
They can key this off IDXGIOutput::GetDesc1's ColorSpace
being HDR10.
Many of these UE4 games statically link against AGS.
This is a problem as when UE4 tries to enable HDR via AGS,
it does not check if AGSContext, and the display info etc
are nullptr unlike the rest of the code using AGS.
So we need to special-case UE4 titles to disable reporting a HDR
when they are in DX11 mode.
The simplest way to do this is to key off the fact that all
UE4 titles have an executable ending with "-Win64-Shipping".
We check if d3d12.dll is present, to determine what path in
UE4 we are on, as there are some games that ship both and support HDR.
(eg. The Dark Pictures: House of Ashes, 1281590)
Luckily for us, they only load d3d12.dll on the D3D12 render path
so we can key off that to force disable HDR only in D3D11.
Sometimes we can't get an EDID if things aren't plumbed fully, or some displays just have broken EDIDs.
This accounts for both of those cases by using some dummy data if we are missing information.
Fixes value reporting to match Windows on common displays such as LG OLEDs.
Adds the ability to punt the global colorspace into HDR from SetColorSpace1.
We have no way of checking the actual Windows colorspace as the
only public method for this *is* DXGI which we are re-implementing.
So we just pick our color space based on the DXVK_HDR env var
and the punting from SetColorSpace1.
We might expand on this in future, but this is good enough for an
initial implementation.
