-
Notifications
You must be signed in to change notification settings - Fork 1k
Fixes for building with clang-cl and wine headers. #4402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Eh I was indeed curious why these casts were not missing in the first place, looks like it'll need to be fixed differently... |
|
I don't think we include |
|
For some reason they end up in the namespace when I build with clang-cl, and it definitely fails to build. But I'll look into it. |
f9fc69b to
b365ef3
Compare
MinGW dxgi import lib advertises some D3DKMT functions, which our dxgi doesn't implement, that later will crash when the functions are resolved and we should instead pull them from gdi32.dll.
And provide dummy fallbacks for non-Win32 platforms. This also updates the definitions to better match the Windows SDK headers, making future additions easier.
Setting shared resource runtime private data is normally not possible and is implemented using a Wine-specific D3DKMTEscape code instead.
Setting shared resource runtime private data is normally not possible and is implemented using a Wine-specific D3DKMTEscape code instead.
Reading the shared resource runtime private data should work with native D3D resource handles, although the runtime private data format is still different.
002cccf to
98cccf2
Compare
This loads the acquire / release functions lazily as they have only been recently added to Wine GDI32 exports.
A couple of compilation failures found while experimenting with clang msvc mode.