Bug 2389415 - QXL: Windows 10/11 UI freezes with HiDPI scaling (125–150%) on Fedora 42 qemu-9.2.4 — please backport the fix from 10.0.x
Summary: QXL: Windows 10/11 UI freezes with HiDPI scaling (125–150%) on Fedora 42 qemu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 42
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL: https://bugs.debian.org/cgi-bin/bugre...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-08-19 14:38 UTC by Hike
Modified: 2025-09-07 23:37 UTC (History)
11 users (show)

Fixed In Version: qemu-9.2.4-2.fc42
Clone Of:
Environment:
Last Closed: 2025-09-07 00:52:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Hike 2025-08-19 14:38:38 UTC
When using QXL + SPICE on Windows guests with display scaling set to 125% or 150%, the UI freezes after a few minutes of normal use. The VM remains alive on the network (ARP/RDP responds), so it looks like a display path freeze, not a full guest hang. Switching the display adapter to virtio(-vga)/virtio-gpu avoids the issue but loses QXL auto-resize behavior. This appears related to the QXL/cursor path regression discussed upstream for 9.1.x and fixed in the 10.0.x series. Environment: Fedora 42, qemu-9.2.4-1.fc42, libvirt/virt-manager, Windows 10 22H2 and Windows 11 24H2 guests, spice-vdagent installed in the guest.

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084199
QEMU issue: https://gitlab.com/qemu-project/qemu/-/issues/1628

Reproducible: Always

Steps to Reproduce:
1 - Create or run a VM with Video set to QXL and SPICE display.
2 - In the Windows guest, set display scaling to 125% or 150%.
3 - Use the system (Explorer, browser). After some minutes, the guest UI stops updating and input no longer affects the on-screen UI, while the VM continues to respond on the network.
Actual Results:
The guest UI freezes after a short period; CPU usage stays low; libvirt reports the domain as running; the VM is reachable over the network (e.g., via RDP/ARP).

Expected Results:
No freezes when using QXL with 125–150% scaling; display should remain responsive.

Additional Information:
Package/version: qemu-9.2.4-1.fc42 (Fedora 42).
Workaround: switch the display to virtio(-vga)/virtio-gpu or access the guest via RDP.
Upstream references for the regression/fix:

Debian bug 1084199 (marked fixed in qemu 1:10.0.0~rc2+ds-1): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084199

QEMU upstream issue 1628 (cursor/graphics stream desync discussion): https://gitlab.com/qemu-project/qemu/-/issues/1628

Request: please backport the relevant QXL fix from 10.0.x to Fedora 42 (or temporarily revert the problematic change). I can test updates-testing builds.

Comment 1 Fedora Update System 2025-09-04 20:10:58 UTC
FEDORA-2025-f89cd6d138 (qemu-9.2.4-2.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-f89cd6d138

Comment 2 Fedora Update System 2025-09-05 02:01:51 UTC
FEDORA-2025-f89cd6d138 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-f89cd6d138`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-f89cd6d138

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 3 Hike 2025-09-05 17:31:58 UTC
Works for me on Fedora 42 host. QEMU 9.2.4-2.fc42, virt-manager 5.0.0. Windows 11 24H2 guest with QXL and 125–150% Display Scale no longer freezes; previously froze within minutes. Thanks for the backport.

Comment 4 Fedora Update System 2025-09-07 00:52:18 UTC
FEDORA-2025-f89cd6d138 (qemu-9.2.4-2.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Hike 2025-09-07 23:37:02 UTC
Thanks!


Note You need to log in before you can comment on or make changes to this bug.