1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
KVM: 0.755
other: 0.750
mistranslation: 0.710
instruction: 0.688
graphic: 0.684
vnc: 0.675
network: 0.659
socket: 0.654
assembly: 0.651
semantic: 0.646
device: 0.641
boot: 0.634
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.]
|