http://bugs.winehq.org/show_bug.cgi?id=60222 Bug ID: 60222 Summary: dxgi_output_GetDisplayModeList is a partial stub: applications that require a mode list never create a swapchain Product: Wine Version: 11.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@list.winehq.org Reporter: hedgar2017@gmail.com Target Milestone: --- Created attachment 81923 --> http://bugs.winehq.org/attachment.cgi?id=81923 +dxgi trace excerpt, game process, full call sequence `dxgi_output_GetDisplayModeList` is a partial stub. Two application-visible consequences follow, one fatal and one an accessibility hazard. ## 1. No swapchain is ever created Assassin's Creed Liberation Remastered (`ACLiberation.exe`, x86_64, D3D11) reaches its main menu — audio plays — and renders nothing: a black fullscreen window that accepts no input, ~35% of one core, 1.6 GB resident, 51 threads, GPU utilisation 0%. The attached `+dxgi` excerpt is the game process's complete call sequence: create factory, `EnumAdapters1`, `DXGID3D10CreateDevice` (feature levels 11_1 down to 9_1, device created), `EnumOutputs`, then `dxgi_output_GetDisplayModeList` — twice per output, once with `modes NULL` for the count and once to fill — hitting the stub every time, across three outputs, followed by output, adapter, device and factory all released to refcount 0. **`CreateSwapChain` is never called**, and no further DXGI activity occurs in the minutes the process keeps running. The application then writes `1280x720 / RefreshRate=0` into its own configuration — a fallback, not a detection. **Control:** `ACIII.exe` (Assassin's Creed III Remastered), a different executable in the same directory launched the same way, runs correctly at 3440x1440. It tolerates the stub; this title requires a mode list and has no fallback path. ## 2. Applications are handed modes the display does not have Assassin's Creed Liberation HD, a different 32-bit D3D11 build of the same game, does run — and its in-game resolution list offers `2560x1440@60` on a display whose only 2560x1440 mode is 240 Hz, verified against the platform's own mode enumeration including hidden and duplicate modes, 170 modes total. Selecting that entry makes the application retry the mode change every frame, producing full-screen white strobing at roughly 30–60 Hz. The returned list is not empty, it is fictional, and applications cannot detect that they have been misled. ## Environment Observed under CrossOver 26.3 (`cxoffice-26.3.0rc2`, built 2026-07-15) on macOS 26.6.2, Apple M2 Max. I have no upstream Wine build on this hardware to retest against, so the behavioural observations come from that Wine-derived build; the stub itself is in Wine's `dxgi` and is verifiable from source. Happy to test a patch and report back. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.