--
v2: gdi32/tests: Add an EMREXTCREATEPEN test.
gdi32: EMREXTCREATEPEN contains a 32 bit EXTLOGPEN.
gdi32: Set EMREXTCREATEPEN offBmi and offBits.
gdi32: Windows adds an extra 4 bytes to EMREXTCREATEPEN.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7183
This should fix [bug 54339](https://bugs.winehq.org/show_bug.cgi?id=54339) for desktop models.
PCI IDs were obtained from https://devicehunt.com/view/type/pci/vendor/10DE/ and additionally verified against https://techpowerup.com/vgabios/ except for the 40xx SUPER line models that were obtained only from https://techpowerup.com/vgabios/ .
I tested the patch on Debian trixie against wine-9.0 and 10.0~rc2 with my 3090: my card was correctly recognized and there were some performance gains when playing SC2. I've also created a [ppa with patched packages for Ubuntu noble and oracular](https://launchpad.net/~morgwai/+archive/ubuntu/wine) and posted links on reddit to [r/linux_gaming](https://www.reddit.com/r/linux_gaming/comments/1i37g2q/pls_… and [r/ubuntu](https://www.reddit.com/r/Ubuntu/comments/1i3ifkx/pls_help_testing… asking for help with testing with other models, but the posts were removed and [my account was banned](https://www.reddit.com/user/morgwai666/) for "posting spam" (I tried to appeal, but never got a reply). I am however completely almost sure that other 30xx models will work correctly as well since this is the same GPU architecture. 40xx models should work correctly as long as
`DRIVER_NVIDIA_KEPLER` is able to support them: I believe this to be the case, but was not able to test it.
As both 30xx and 40xx series are really messed up in terms of different variants within the same "base models" (things "Ti", "LHR", VRAM size *may* correspond to different PCI IDs), constant names and string descriptions became really long which in turn messed up the code formatting/alignment. Please let me know if the current formatting is acceptable or if I should change it somehow or maybe even add one more commit that increases spacing between fields in all other rows to make it all aligned.
I skipped mobile models for now: honestly putting this together was extremely tedious and frustrating (especially as it was unfolding before my eyes how messed up the mapping is due to different variants), so I didn't want to dedicate more time to this until I received some positive feedback.
--
v4: wined3d: Add Nvidia RTX40xx series desktop models data.
wined3d: Add Nvidia RTX30xx series desktop models data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7171
This is an alternative proposal to !5830. It fixes the same glitches in Horizon Zero Dawn, but attempts to do that by implementing the proper behavior expected from the swapchain. More precisely, it fixes a few mistakes I had made the last time I touched this code, it implements the frame latency waitable with a semaphore instead of an event (as it should be) and at last it uses the frame latency waitable to implement an appropriate wait after presentation when the client didn't request to manage the waitable directly.
This implementation is not yet complete, because the semaphore should be released when the frame is presented. Knowing when this is the case would require using `VK_KHR_present_wait`. We currently approximate that with the moment in which the frame is submitted for presentation to Vulkan, which as far as I can tell is good enough. Eventually I'll try to write the proper thing.
This MR depends on https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/1343, which has been submitted in the meantime to vkd3d. The vkd3d change is included in the first commit, so this MR is already functional.
--
v2: dxgi: Wait on the frame latency semaphore when the client doesn't do it.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7152
Before this patch, WM_COPYDATA message data was packed at the end of the message and then passed
to KeUserModeCallback() to call user mode callbacks. However, WM_COPYDATA can contain a large amount
of data so KeUserModeCallback() can cause stack overflows. Manual tests on Windows show that
WM_COPYDATA messages with data <= 2048 bytes do have their data packed at the end of the message.
But for WM_COPYDATA messages with data > 2048 bytes, KiUserCallbackDispatcher() gets a 120 bytes
packed arguments, which is the same size when packing WM_COPYDATA messages with no data. So for
WM_COPYDATA messages with data > 2048 bytes, the data must be packed differently.
Fix FCSExpress hangs after sending WM_COPYDATA messages.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7189