Add support for D3DFMT_CxV8U8, which is required for the game Biorage.
Also add support for loading DDS files with header flag values of `DDS_PF_FOURCC` alongside other flag values.
--
v3: d3dx11/tests: Add more DDS pixel format tests.
d3dx10/tests: Add more DDS pixel format tests.
d3dx9: Ignore all other DDS pixel format flags if DDS_PF_FOURCC is set.
d3dx9/tests: Add a test for DDS_PF_FOURCC flag handling.
d3dx9/tests: Add tests for ATI{1,2} DDS files.
d3dx9: Replace D3DFMT_CxV8U8 with D3DFMT_X8L8V8U8 when creating textures.
d3dx9: Add support for D3DFMT_CxV8U8.
d3dx9/tests: Add tests for D3DFMT_CxV8U8.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8966
A much cleaner result (written by hand) that we can reuse where needed later (_i.e._ `GetNumaProcessorNode` which also crashes with [a similar MAV](https://gist.github.com/wasertech/f894ce8d6250e72a01a861c0e4eb6064) on multi-node systems).
Took me a while to understand where I should put everything, not even sure I got it right. Let me know.
I thought I was going to need `FileNumaNodeInformation` but turns out it's not really needed. I can remove it if you want.
This is what I see when I try to get a node count read:
```log
0024:fixme:ntdll:init_numa_info node affinity; using node 0.
GetNumaHighestNodeNumber: 1
```
I only see this fixme if I try to access `FILE_NUMA_NODE_INFORMATION`. I would really prefer such a behavior for our compatibility layer on any multi-node system.
A big thanks to @besentv and @zfigura for their invaluable feedback on this.
--
v5: ntdll: simplify return handling from `init_numa_info` in `NtQuerySystemInformationEx( SystemNumaProcessorMap )`
ntdll: refactor init_numa_info to return NTSTATUS and improve error handling
ntdll: remove unused definition
https://gitlab.winehq.org/wine/wine/-/merge_requests/8995
H.264 uses a 16-pixel alignment, and the stream sink media type should
have the aligned height after the session has started.
--
v7: mf/tests: Test H.264 decoder alignment.
mf/tests: Test H.264 sink media type height alignment.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8887
This series covers various fixes & improvements when a crash
happens in a program which fires up winedbg in auto mode.
Firstly, winedbg is a bit too strict for detecting the startup sequence
(and fails to display the backtrace in these stricter cases).
Third patch relaxes the startup conditions in that case.
Secondly, if failing programs is a GUI, winedbg is launched in a new
console (since GUI are now detached from console), but console
is closed after winedbg terminates (which is after printing the
crash details). So rather not useful :-(
To work around this, conhost in its configuration dialog has
tab 'Configuration' / 'End of program' / 'Close console' checkbox
But which is not implemented.
Second patch add supports for this in conhost.
Lastly, conhost has the ability to store configuration per application.
Hence, one can configure conhost with specific settings for winedbg.
Interesting options are:
- setting very high buffer zone so that conhost keeps track of all
winedbg output,
- unchecking the 'Close console' option.
To set it for winedbg,
- start it with './wine wineconsole winedbg'
- use 'Properties' from the menu (right-click in conhost) to set the
options for winedbg
Since 68f3a8e699904bd308de0da4a1e1d2c9eb91ea96, conhost doesn't pick
the registry entry for winedbg (if it exists) when started with
'./wine wineconsole winedbg'.
Third patch solves that in a somehow hacky way, but couldn't find a
better option that doesn't break
https://bugs.winehq.org/show_bug.cgi?id=10941
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9006