Repository navigation
qemu: tell the guest the host display's refresh rate - #7982
Open
dragoshont wants to merge 1 commit into
Open
dragoshont wants to merge 1 commit into
dragoshont wants to merge 1 commit into
Conversation
The guest learns its refresh rate from the EDID that QEMU generates. QEMU only fills in the host rate when the GTK or Cocoa display reports it; SPICE has no field for it, so with UTM every guest gets a made-up 75 Hz mode. Windows then lists only 75 Hz modes and composes at 75 Hz, so on a 60 Hz display about one frame in five is rendered and never shown, and a 120 Hz display cannot be used at all. Pass the main screen's refresh rate to virtio GPU devices with the new refresh_rate property, which QEMU uses when the display reports none. Assisted-by: GitHub Copilot:claude-opus-5.5
This was referenced Oct 18, 2026
Closed
dragoshont
marked this pull request as ready for review
October 18, 2026 13:04
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Guests in UTM always get a 75 Hz display, whatever the Mac's display runs at.
QEMU only puts the host refresh rate in the guest's EDID when the display frontend reports it, and SPICE can't, so the guest gets a made-up 75 Hz mode. Windows 11 ARM64 on viogpu3d then lists only 75 Hz modes:
This passes the main screen's refresh rate to virtio GPU devices through QEMU's new
refresh_rateproperty.Depends on utmapp/qemu#7; without it QEMU rejects the argument. Related: #7820.
Testing: macOS 27.0.1, MacBook Pro M5 Max, external 60 Hz display plus the built-in 120 Hz panel. Debug build with utmapp/qemu#7, disposable Alpine VM with
virtio-gpu-gl-pci:refresh_rate=60000refresh_rate=120000Windows 11 Pro ARM64 (build 26300, viogpu3d 100.6.101.58000, D3DMetal) on the same build:
The rate comes from
NSScreen.main, the screen with the key window when the VM starts. Moving the window to another display later doesn't change it until the next start.Test setup: an ad-hoc signed build has no app group, so UTM sets no
APP_SANDBOX_GROUP_ID, Neptune can't create shared memory and Windows shows "Display output is not active". For these runs I set the group by hand; release builds aren't affected.An AI agent ran these tests on my Mac.
I have read the AI contribution guidelines and have followed them to the best of my ability.