This MR introduces support for OpenGL in the Wayland driver.
Since the MR started to become somewhat long I have left some things for a subsequent part 13.2:
* wgl(Get)SwapIntervalEXT (which means everything is vsync-ed at the moment)
* wglShareLists
* wglCreateContextAttribsARB
* Fix for some apps appearing translucent in certain compositors (typically when fullscreen).
Missing features not planned to be part of the 13.x MRs:
* Offscreen rendering through pbuffers or pixmaps, since Wayland EGL doesn't support them (perhaps we can simulate with FBOs instead?).
* Front buffer rendering. Again Wayland EGL doesn't support this, and certainly not in the form needed (i.e., the surface should be available for additional rendering with GDI). In the experimental branch I implemented a workaround that seemed to work for many cases, but will need to revisit and reevaluate options. IIRC, the most common case I have seen for this is when using wined3d/gl for older (Direct)2D games, so perhaps we can find a better solution at that layer.
* Child window rendering (this needs infrastructure in Wayland driver core which will enable both GL and Vulkan rendering in child windows).
* Cross-process rendering.
Thanks!
--
v2: winewayland.drv: Handle resizing of OpenGL content.
winewayland.drv: Implement wglSwapBuffers.
winewayland.drv: Implement wglMakeCurrent and wglMakeContextCurrentARB.
winewayland.drv: Implement OpenGL context creation.
winewayland.drv: Implement wglSetPixelFormat(WINE).
winewayland.drv: Implement wglDescribePixelFormat.
winewayland.drv: Implement wglGetProcAddress.
winewayland.drv: Implement wglGetExtensionsString{ARB,EXT}.
winewayland.drv: Initialize core GL functions.
winewayland.drv: Add skeleton OpenGL driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5177
Yakuza 6's Puyo Puyo minigame creates a texture from a DDS file that is the equivalent format of `DXGI_FORMAT_B4G4R4A4_UNORM`, which windowscodecs does not support.
This patch converts the texture into the equivalent of `DXGI_FORMAT_R8G8B8A8_UNORM` DDS file at the start of `load_texture_data()`, which allows us to avoid having an entirely separate code path for this specific image type. This current patch just handles the most basic of DDS files, if this approach seems reasonable I will flesh it out more, I just wanted to see if it was a good/bad idea before putting anymore work into it. :)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5022
Test module references created by resolving forwarded exports.
The following diagram explains what happens in bug #52094 under the hood:
```mermaid
graph TB
subgraph state_00["Initial"]
direction LR
s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll]
end
state_00 -. "1. <strong><code><span style='color:#28f'>Load</span>Library("</code></strong>configured Python version (e.g., python311.dll)<strong><code>")</code></strong>" .-> state_01
subgraph state_01["python311.dll loaded"]
direction LR
s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll]
s01_ida -- "<em>dynamic</em> ref" --> s01_py311
end
state_01 -. "2. <strong><code><span style='color:#28f'>Load</span>Library("</code></strong>idapython64.dll<strong><code>")</code></strong>" .-> state_02
subgraph state_02["idapython64.dll loaded"]
direction LR
s02_ida[ida64.dll] -- "<em>dynamic</em> ref" --> s02_idapy[idapython64.dll] -- "<em><strong>static</strong></em> ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll]
s02_ida -- "<em>dynamic</em> ref" --> s02_py311
s02_idapy -- "<span style='color:red'><em><strong>static forwarded</strong></em> ref</span>" --> s02_py311
end
state_02 -. "3. <strong><code><span style='color:#d70'>Free</span>Library("</code></strong>configured Python version (e.g., python311.dll)<strong><code>")</code></strong>" .-> state_03
subgraph state_03["python311.dll reference removed"]
direction LR
style s03_py311 color:#f00,stroke:#f00
s03_ida[ida64.dll] -- "<em>dynamic</em> ref" --> s03_idapy[idapython64.dll] -- "<em><strong>static</strong></em> ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll]
s03_ida -. "<del><em>dynamic</em> ref (deleted)</del>" .-> s03_py311
s03_idapy -- "<span style='color:red'><em><strong>static forwarded</strong></em> ref</span>" --> s03_py311
end
```
On Windows, the <em><strong>static forwarded</strong></em> ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition.
---
### Alternative options
1. Find existing DLLs satisfying this scenario: I haven't found any in wine tree. Let me know if I missed anything.
2. Construct PE for the DLLs on-the-fly: This sounds more complicated than a handful of test DLLs.
--
v6: kernel32/tests: Test module refcounting with forwarded exports.
https://gitlab.winehq.org/wine/wine/-/merge_requests/364