diff options
Diffstat (limited to 'results/classifier/118/none/504368')
| -rw-r--r-- | results/classifier/118/none/504368 | 208 |
1 files changed, 208 insertions, 0 deletions
diff --git a/results/classifier/118/none/504368 b/results/classifier/118/none/504368 new file mode 100644 index 000000000..3dff5c342 --- /dev/null +++ b/results/classifier/118/none/504368 @@ -0,0 +1,208 @@ +KVM: 0.755 +permissions: 0.741 +risc-v: 0.736 +user-level: 0.728 +architecture: 0.722 +mistranslation: 0.710 +virtual: 0.707 +register: 0.705 +performance: 0.693 +hypervisor: 0.689 +graphic: 0.684 +debug: 0.683 +vnc: 0.675 +TCG: 0.670 +network: 0.659 +ppc: 0.657 +socket: 0.654 +assembly: 0.651 +arm: 0.649 +x86: 0.648 +semantic: 0.646 +device: 0.641 +kernel: 0.635 +boot: 0.634 +files: 0.629 +peripherals: 0.623 +PID: 0.610 +VMM: 0.573 +i386: 0.511 + +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.] + |