ref:main

Real guest behavior: what was fixed, what's correct, what's left #15

open Opened by cole.christensen@gmail.com

Things found while making the VM behave like a real display rather than a demo. Each was measured on the desktop guest; the ones already fixed are listed so nobody re-investigates them.

Fixed

  • The VM now renders at the size the client streams at (REQ-CAP-007, 4fe9720b). Scaling a 1080p guest to 720p and back measured 20.1 dB PSNR against QEMU’s framebuffer where matching sizes give 37.6 dB; bitrate made no difference between 8 and 100 Mbps.
  • A VM that goes away no longer floods the log (f60daa42): 673 error lines in twelve seconds became one.
  • The desktop rig exits when its VM dies instead of serving a black screen, and runs with Restart=on-failure.

Checked, behaving correctly, no work needed

  • HDR: ServerCodecModeSupport advertises H.264, HEVC and AV1 without Main10, which is right for an SDR VM framebuffer. YUV 4:4:4 is advertised, and it’s worth telling users to enable it in Moonlight for text-heavy VMs.
  • A paused VM (QMP stop) looks like a frozen picture: the client streamed for 100 s, decoded 1364 repeated frames, no errors, and the session stays healthy for when the VM resumes.
  • A VM killed mid-stream ends the session cleanly: “CLIENT DISCONNECTED”, “Session ended”, and the client exits rather than hanging.
  • Screen blanking: the test guest has its screensaver off and DPMS disabled, so a long idle stream doesn’t go black. A user’s own VM may not; that’s the guest’s business, as it is for a physical host.

Open

  • Sunshine keeps serving after its VM is gone. With libvirt, the hook stops the unit when the domain stops; a raw QEMU instance stays up, still advertised over mDNS, and a client that connects gets a failed launch. Exiting would let the unit’s sunshine-qemu-wait-vm wait for the VM and Restart=on-failure bring it back. That’s a policy choice: good for the systemd deployment, surprising for someone running Sunshine by hand, so it probably wants a config key.
  • The client’s refresh rate never reaches the guest. SetUIInfo carries only a size, so a guest may render at 75 Hz while the client asks for 120. Worth checking whether a mode with the right rate can be offered.
  • No DPI hint. SetUIInfo‘s width_mm/height_mm are sent as 0. A HiDPI client could get sensible guest scaling if these carried the client’s physical size.
  • Guests need a display agent to follow the size. GNOME and KDE do it themselves; tests/e2e/qemu/desktop/sq-follow-resolution is the example for anything else, and Windows guests need QEMU’s guest tools. Worth shipping guidance, or a small agent, rather than leaving each user to write one.