restructure results

1 files changed, 0 insertions, 208 deletions

diff --git a/results/classifier/118/none/504368 b/results/classifier/118/none/504368
deleted file mode 100644
index 3dff5c34..00000000
--- a/results/classifier/118/none/504368
+++ /dev/null
@@ -1,208 +0,0 @@
-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.]
-