sdl window intermittently scales instead of resizing

Bug #504368 reported by Jamin W. Collins
72
This bug affects 15 people
Affects Status Importance Assigned to Milestone
QEMU
Expired
Wishlist
Unassigned
qemu-kvm (Ubuntu)
Expired
Low
Unassigned

Bug Description

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

Revision history for this message
Jamin W. Collins (jcollins) wrote :
Revision history for this message
Jamin W. Collins (jcollins) wrote :
Scott Moser (smoser)
Changed in qemu-kvm (Ubuntu):
importance: Undecided → Low
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

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?

Changed in qemu-kvm (Ubuntu):
status: New → Incomplete
Revision history for this message
Anthony Liguori (anthony-codemonkey) wrote :

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.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

@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.

Revision history for this message
Dustin Kirkland  (kirkland) wrote : Re: [Bug 504368] Re: sdl window intermittently scales instead of resizing

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.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

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.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

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

Revision history for this message
Anthony Liguori (anthony-codemonkey) wrote :

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.

Changed in qemu:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Michal Suchanek (hramrach) wrote :

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.

Revision history for this message
Prateek Karandikar (prateek.karandikar) wrote :

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.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

This may be the root cause of bug 986192

Changed in qemu-kvm (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Peter Wu (lekensteyn) wrote :

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?

Revision history for this message
Michal Suchanek (hramrach) wrote : Re: [Bug 504368] Re: sdl window intermittently scales instead of resizing

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.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

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.

Revision history for this message
Peter Wu (lekensteyn) wrote :

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

Revision history for this message
Jamin W. Collins (jcollins) wrote :

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.

Revision history for this message
Peter Wu (lekensteyn) wrote :

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?

Revision history for this message
Thomas Huth (th-huth) wrote :

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 ?

Changed in qemu:
status: Triaged → Incomplete
Changed in qemu-kvm (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in qemu-kvm (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.