My Linux system runs at a DPI/retina/"scale" of 150%. That sounds funny but it is very normal for Lenovo laptops. I have tried the gtk (default), SDL, and spice-app (virt-viewer) -display options, and I cannot find a way to get qemu to display the guest OS at its native size. By native size (my "**expected behavior**") I mean that 1 pixel in the guest OS display = 1 physical pixel on the screen. ## Host environment - Operating system: Debian GNU/Linux 13 (trixie) - OS/kernel version: 12.107+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.107-1 (2026-08-29) x86_64 GNU/Linux - Architecture: AMD64 - Desktop type: GNOME + Wayland (Mutter) - QEMU flavor: qemu-system-x86_64 - QEMU version: 10.0.13 (Debian 1:10.0.13+ds-0+deb13u1) - QEMU command line: `SDL_VIDEO_X11_DGAMOUSE=0 qemu-system-x86_64 -d cpu_reset,guest_errors -enable-kvm -smp 4 -m 2048 -chardev stdio,id=debug,signal=off,mux=on,"" -serial chardev:debug -mon chardev=debug -machine q35 -cpu host -device ich9-intel-hda -device hda-duplex -netdev user,id=net0 -device e1000,netdev=net0 -device nec-usb-xhci,id=xhci -drive file=`echo $PWD/redox_demo_x86_64_2024-09-07_1225_harddrive.img`,format=raw` ## Emulated/Virtualized environment - Operating system: Redox 0.9 demo image - Architecture: AMD64 ## Description of problem The OS image I am using lets you select the resolution it renders at. In my testing, I find when I launch, the GUI renders by default (and snaps to this size when I select the 100%/"normal size" option: `-display gtk` (default): I create a 320x200 desktop, it creates a window which is 480x300 real screen pixels. `-display SDL`: I request a 800x600 desktop, it creates a window which is 600x400 real screen pixels. `-display spice-app` (launches `virt-viewer`): I request a 640x400 desktop, it creates a window which is 480x300 pixels. In other words, Gtk is at "100%" actually blowing things up by 1.5x, and SDL and Spice at 100% are shrinking things by 1.5x. Both of these behaviors result in muddy, hard-to-read text and images. GTK's behavior, magnifying by 1.5x is probably intentional, and seems like an attempt to "help", because the magnification means the 320x200 guest pixels will display at a size of 320x200 "logical" pixels. On non-fractional displays, this might be what the user wants; on fractional displays it creates big problems because at a scale of 1.5 the content will always be blurry and hard to read, regardless of which zoom you pick. In both gtk qemu and virt-viewer (sdl can't resize, I think) resizing is only in 2x steps up or down meaning there is no way to zoom to the true 1x scale. (Also I have not tested this, but if I zoom in it remains blurry, as if it is scaling up by 1.5 and then scaling up again by 2.0.) SDL and virt-viewer's behavior I cannot explain and seems like a pure bug, possibly caused by failure to test with fractional scales. ## Steps to reproduce 1. Boot into GNOME, go in Settings, Displays, set Scale to 150% 2. Launch a VM with `-display gtk` (should be the default) 3. Take a screenshot (for me this is PrtSc button) of the displayed area in the VM 4. Open the screenshot and click the (i) to see how many actual pixels it had ## Additional information Launching in gtk with a 640x400 resolution this is what I see {width=680 height=600} If you open this in an image editor you will see (1) the image is 960x600, so 1.5x size (2) the pixels are scronched. Here it is zooming in one tick: {width=680 height=600} In an image editor this is 1280x800. That is 2x the guest OS screen size, so the pixels should be clean and clear. But they are all funky munged anti aliased as if they have been rescaled multiple times. I could be wrong but even if this is a linear upscale it doesn't look like a clean 2x upscale. By contrast, here is a screenshot I took in Windows 10 on a 1x/100% DPI screen, using qemu-w64-setup-20260811: Notice the pixels are exactly two colors. {width=642 height=457} Things I have not tried: - Turning off scaling on Linux (requires reboot) - Trying KDE (don't have it. but i hear its wayland is much better at fractional DPI)