Ozone/Wayland: Vsync refresh rate caps at first available mode instead of using the active compositor refreshRate on headless/virtual displays

[Stefano Merino]

Product / Component: Chromium -> UI > Shell > Platform > Wayland (Ozone)

Description: Under native Wayland sessions (--ozone-platform=wayland), Chromium seems to source its Vsync/frame rendering interval strictly from the first index of the advertised screen modes (availableModes) instead of respecting the actual active refreshRate reported by the desktop compositor for the target output.

This causes throttling issues on headless configurations, virtual displays, or virtual desktops (e.g., used for remote access or mirroring) where a non-standard or high refresh rate is configured dynamically by the compositor, but the driver fallback mode lists standard static values (like 1920...@60.00Hz).

Steps to Reproduce:

1. Create a headless or virtual display using a Wayland compositor (e.g., Hyprland headless backend).

2. Set the active display refresh rate to a high value (e.g., 160Hz).

3. Ensure the hardware/driver emulation layer reports static available display modes capping at 60Hz.

4. Launch Chromium natively on Wayland (--ozone-platform=wayland).

5. Navigate to a frame-rate diagnostic tool like testufo.com or check chrome://gpu performance.

Expected Result: Chromium should desynchronize or bind its Vsync interval to the compositor's active refreshRate (160Hz) or adapt via the wp_presentation feedback loop protocol.

Actual Result: Chromium locks the rendering pipeline down to 60 FPS, matching the availableModes metadata array.

Note: This limitation does NOT happen when running Chromium through XWayland compatibility layer (--ozone-platform=x11), where it smoothly achieves the full 160Hz.

Environment details (Example logs from Hyprland compositor hyprctl monitors -j):

JSON

[{ "id": 1, "name": "virtual-fallback-display", "width": 1920, "height": 1080, "refreshRate": 160.00000, "focused": true, "dpmsStatus": true, "disabled": false, "mirrorOf": "none", "availableModes": ["1920...@60.00Hz"] }]

As shown above, while the compositor explicitly targets an active "refreshRate": 160.00000, Chromium prioritizes the fallback array structure "availableModes": ["1920...@60.00Hz"], resulting in artificial 60 FPS capping.