KVM: 0.755
other: 0.750
permissions: 0.741
performance: 0.693
graphic: 0.684
debug: 0.683
vnc: 0.675
network: 0.659
socket: 0.654
semantic: 0.646
device: 0.641
boot: 0.634
files: 0.629
PID: 0.610

sdl window intermittently scales instead of resizing

Binary package hint: qemu-kvm

Normally, the SDL output window for a VM resizes to match the VM's resolution.  However, intermittently the output is instead scaled within the window.  I can't seem to find any pattern to when the output is scaled versus when the window is resized.  I would prefer that the window be resized as needed to display the VM in a 1:1 manner.

ProblemType: Bug
Architecture: amd64
Date: Thu Jan  7 10:30:10 2010
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
KvmCmdLine:
 UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
 root     27618     1 38 241752 804668 1 10:05 ?        00:09:39 /usr/bin/kvm -S -M pc-0.11 -cpu qemu32 -m 768 -smp 1 -name win2k3 -uuid da414aa0-f18a-7a02-3d1b-1dbf13137bc9 -monitor unix:/var/run/libvirt/qemu/win2k3.monitor,server,nowait -localtime -boot c -drive file=/media/qpc-devel/testing/win2k3/testing.ovl,if=ide,index=0,boot=on -drive file=/media/qpc-devel/testing/win2k3/../../isos/en_win_srv_2003_r2_standard_cd1.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:d6:f5:60,vlan=0,model=ne2k_pci,name=ne2k_pci.0 -net tap,fd=18,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vga cirrus
 root     28306     1 54 177732 545520 1 10:28 ?        00:00:49 /usr/bin/kvm -S -M pc-0.11 -cpu qemu32 -m 512 -smp 1 -name win2k -uuid 153d6125-acb5-70bc-c7d2-bcbf87c5be86 -monitor unix:/var/run/libvirt/qemu/win2k.monitor,server,nowait -localtime -boot c -drive file=/media/qpc-devel/testing/win2k/testing.ovl,if=ide,index=0,boot=on -drive file=/media/qpc-devel/testing/win2k/../../isos/windows_2000.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=68:29:6b:13:50:c6,vlan=0,model=ne2k_pci,name=ne2k_pci.0 -net tap,fd=19,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vga cirrus
NonfreeKernelModules: nvidia
Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-16-generic root=UUID=30218f9a-6f90-4eab-9ba5-f54897e842cb ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-16-generic x86_64
dmi.bios.date: 02/20/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETB2WW (2.12 )
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7LETB2WW(2.12):bd02/20/2008:svnLENOVO:pn:pvrThinkPadT61p:rvnLENOVO:rn:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.version: ThinkPad T61p
dmi.sys.vendor: LENOVO



Reported upstream also: https://sourceforge.net/tracker/?func=detail&aid=2930756&group_id=180599&atid=893831

Anthony, can you explain the behavior here?

At the very least, we should be able to get something into the documentation.

On Karmic (qemu-kvm-0.11) I noticed some strange behavior.  If I physically "moved" the window before X was fully up in the guest, the image would be scaled in a strange way.

I do not see this behavior in Lucid's qemu-kvm 0.12.3.  Jamin, do you?

If you accidentally resize the window (even by 1-pixel), then it will stay in scaled mode even during guest geometry changes.

It sucks from a usability perspective.  Clever suggestions about how we can support scaling in a more friendly way are certainly appreciated.

@Dustin,
I've experienced the problem with a rebuild of the lucid package for karmic.  The package is in my PPA, https://launchpad.net/~jcollins/+archive/jaminppa.

@Anthony,
I can assure you that I've seen the scaling without resizing the client window in any way.  Simply starting the VM and leaving it untouched periodically results in a scaled display.

On Wed, Mar 3, 2010 at 8:03 AM, Jamin W. Collins
<email address hidden> wrote:
> @Anthony,
> I can assure you that I've seen the scaling without resizing the client window in any way.  Simply starting the VM and leaving it untouched periodically results in a scaled display.

Jamin-

What about 'moving' the client window?  I have not seen it rescale at
random, but I have seen it rescale if I move the window before X comes
up.

I frequently relocate my VM displays.  My host system's window manager is openbox.  Normally, for moving any window about my screen, I utilize the ALT+left-click feature to drag the window about.  This has the added benefit of ensuring I don't accidentally resize the window.

Most of my guests are Windows based at the moment.  When the display scales it tends to remain the size of the booting splash screen.

I just tried some different methods of starting the VMs and dragging the displays about.  If I'm performing an ALT+left-click drag when the display wants to resize it seems to switch to scaling instead.  So, this may be part of it, but I am very certain I've seen the same result when simply starting the VM and not touching the display in any way.

Just had it happen again.  Simply started the VM, didn't touch the SDL window for it at all, guest wound up scaled.  Here's the xwininfo output for the SDL window:

xwininfo: Window id: 0x6e00003 "QEMU (winxp-work)"

  Absolute upper-left X:  640
  Absolute upper-left Y:  367
  Relative upper-left X:  1
  Relative upper-left Y:  20
  Width: 720
  Height: 480
  Depth: 24
  Visual Class: DirectColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x6e0000c (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +640+367  -560+367  -560-353  +640-353
  -geometry 720x480+639+347


You can disable scaling by hitting ctrl-alt-u.

What's probably happening is that the window manager is generating an extraneous scaling event.  I'm going to move this to wishlist as we should provide better user controls of this behavior.

My window manager maximizes all windows. I am running kvm 0.14.

Initially the VM is displayed 1:1 in the top left corner leaving large portion of the window black.  Resizing the window or rebooting the VM causes the output to be scaled which is horrendous.

There are three issues here: there is no way to force the window to be the size of the VM output nor is there a way to display the VM output 1:1 regardless of window size nor  is there any possibility to make the VM output scale proportionally.

Pressing Ctrl+Alt+u definitely does not disable scaling for me although it causes the VM output to disappear momentarily causing the window to flash.

I guess setting window size  can be achieved with some WM hint (and should be a command line option and possibly a option configurable from the monitor). Obviously, not all outputs can set the hint and not all WMs will respect it. However, setting the hint *and* resizing to the desired size should give the correct size in most cases. http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#NORESIZE

The other issue is that scaling does not respect aspect ratio leading to horrendous VM output. I don't think there is any use case for non-proportional scaling.



I have the same problem too. Anything other than each guest pixel mapping to exactly one host pixel looks bad. There should be a way to ensure that this is always the case (in fact, perhaps it should be the default and there should be a command line switch to allow the possibility of the display being scaled).

VirtualBox gets this right.

This may be the root cause of bug 986192

I have attached a screenshot that shows the *contents* of a SDL window *not* being scaled despite the window being maximized. Is this the same issue or not? If not, can you attach a screenshot describing the issue?

On 26 April 2012 18:23, Serge Hallyn <email address hidden> wrote:
> This may be the root cause of bug 986192

I guess not. That bug is TwinView specific but this issue happens with
any graphics.

In fact, in qemu 1.5 this issue is no longer present.


As requested here's a screenshot of the scaled window.  The expected behavior is that the window be resized to the dimensions of the guest.

Pressing Ctrl+Alt+u within this window corrects the issue and the window is in fact resized to the guest dimensions.

Scaling can be triggered by:

- Pressing ctrl-alt-{minus,plus} (on certain keyboard layouts)
- a SDL_VIDEORESIZE event

SDL_VIDEORESIZE is always sent on an X ConfigureNotify event when a SDL_VideoSurface is active. (SDL_VideoSurface is NULL if a resize was done in SDL_SetVideoMode).

So it really must be a window manager or something sending this resize event. What WM are you using?

Notes, SDL_VIDEORESIZE (and other events) may be eaten:
- in the very early start-up stage[1] (causing the issue mentioned in comment 13)
- during switches to and from fullscreen
- (some other paths that do not affect QEMU)

 [1]: http://bugzilla.libsdl.org/show_bug.cgi?id=1859

Window manager varies.  In the original report it was openbox (as I believe I stated, in comment #7).  Current window manager is xfwm4.  For the screenshot provided, I intentionally moved the window with Alt+left_click as I knew this would trigger the issue (also indicated in comment #7).   However, as stated before, the issue happens seemingly randomly on its own without moving the window or interacting with it in any way.

I cannot reproduce with KWin FWIW, but have an openbox box somewhere (no pun intended).

Can you apply the attached debug patch, reproduce your bug (move with alt+click) and attach the output? If the log grows too large, try:

    uniq -f1 -c log
What version of SDL are you using?

Since support for SDL 1.2 has been removed from QEMU now, can you still reproduce this issue with the latest version of QEMU and SDL2 ?

[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.]

[Expired for QEMU because there has been no activity for 60 days.]