[Spice-devel] QXL from spice-guest-tools-0.3, Code 52 - signing problem?
Hi, Is anyone having problems with the QXL driver from spice-guest-tools 0.3 under Windows 7 Pro? It is installing correctly but not running due to signing issues (code 52). If I disable Driver Enforcement (F8) it runs fine. All other drivers in that set, i.e., serial, net, storage, balloon are working with Driver Enforcement. Cheers Richard ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] settings for qxl memory size
2013/1/24 Alon Levy : >> Is the amount of MB in the first 3 lines as expected? In another test >> I tried 16M for both qxl-vga.ram_size and qxl-vga.vram_size but these >> lines didn't change. > > No, it isn't, good that you noticed (bad that I didn't). vram/64 can be > (should be - no driver knows how to map it yet unless you changed it) zero > but vram/32 should be > 0. How are the bars allocated? is it seabios or > something else? if seabios can you enable debugging messages by adding the > following to qemu command line (again - this is upstream, I have no idea how > it works with xen): -chardev > stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios Yes, it is seabios, but I can't pass those arguments: qemu invocation fails with "qemu-system-i386: -chardev stdio,id=seabios: invalid option". I tried both qemu 1.3.0 and 1.4 from git. I'm trying to understand if the problem is in the interaction with xen. I'll post the debugging messages as soon as it works, thanks, DC ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Establish a preferred default of 1024x768 correctly.
> I have one bit of due diligence I'm going to do as well;
> (I wanted to make sure the change to qxl_resize_primary_to_virtual
> shouldn't be it's own patch, and maybe see if that's what
> led to my NumHeads confusion), but I'll hopefully respin
> and submit today or tomorrow.
Blech. I'm glad I looked; that bit of code in my patch is wrong.
I used that as a crutch to get my frame buffer resized; I should
instead set the qxl->virtual_x and qxl->virtual_y to a different value.
I want to take a bit more time with this; I don't have a truly good
handle on how the virtual sizing should work.
I've attached my current 'best' patch if others are interested. I'll
try to follow through tomorrow or Monday.
Cheers,
Jeremy
>From db807800165777bbe2b55ed79db2d830c4a5bd36 Mon Sep 17 00:00:00 2001
From: Jeremy White
Date: Thu, 20 Sep 2012 19:51:58 -0500
Subject: [PATCH] Establish a preferred default of 1024x768 correctly.
This fixes a bug with x-spice where you could not specify
a default mode in an xorg.conf modeline that was greater
than 1024x768. This also eliminates (and partially
reverts) patch c1b537fc.
It may also fix bug 894421, where gnome modes flicker
and work poorly.
---
src/qxl_driver.c | 85 +-
1 file changed, 26 insertions(+), 59 deletions(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index e1893dc..ecc7797 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -135,6 +135,10 @@ const OptionInfoRec DefaultOptions[] =
};
+/* These constants govern which modes are reported to X as preferred */
+#define DEFAULT_WIDTH 1024
+#define DEFAULT_HEIGHT 768
+
static void qxl_update_monitors_config (qxl_screen_t *qxl);
@@ -1780,14 +1784,10 @@ qxl_screen_init (SCREEN_INIT_ARGS_DECL)
goto out;
if (!miSetPixmapDepths ())
goto out;
-pScrn->displayWidth = pScrn->virtualX;
#if 0
ErrorF ("allocated %d x %d %p\n", pScrn->virtualX, pScrn->virtualY, qxl->fb);
#endif
-
-pScrn->virtualX = pScrn->currentMode->HDisplay;
-pScrn->virtualY = pScrn->currentMode->VDisplay;
/* Set up resources */
qxl_reset_and_create_mem_slots (qxl);
@@ -2083,15 +2083,6 @@ qxl_output_get_modes (xf86OutputPtr output)
qxl_output_private *qxl_output = output->driver_private;
DisplayModePtr modes = xf86DuplicateModes (qxl_output->qxl->pScrn, qxl_output->qxl->x_modes);
-if (output &&
-output->crtc && output->crtc->enabled)
-{
- DisplayModePtr crtc_mode = &output->crtc->mode;
- crtc_mode = screen_create_mode (qxl_output->qxl->pScrn, crtc_mode->HDisplay, crtc_mode->VDisplay, M_T_PREFERRED);
- output->crtc->mode = *crtc_mode;
- modes = xf86ModesAdd (modes, crtc_mode);
-}
-
/* xf86ProbeOutputModes owns this memory */
return modes;
}
@@ -2322,12 +2313,6 @@ qxl_init_randr (ScrnInfoPtr pScrn, qxl_screen_t *qxl)
qxl_crtc->output = output;
}
-qxl->virtual_x = 1024;
-qxl->virtual_y = 768;
-
-pScrn->display->virtualX = qxl->virtual_x;
-pScrn->display->virtualY = qxl->virtual_y;
-
xf86InitialConfiguration (pScrn, TRUE);
/* all crtcs are enabled here, but their mode is 0,
resulting monitor config empty atm */
@@ -2339,6 +2324,7 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr pScrn,
{
int i;
int size;
+int preferred_flag;
*max_x = *max_y = 0;
/* Create a list of modes used by the qxl_output_get_modes */
@@ -2353,15 +2339,24 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr pScrn,
qxl->modes[i].x_res, qxl->modes[i].y_res);
continue;
}
-
+
+if (qxl->modes[i].x_res == DEFAULT_WIDTH && qxl->modes[i].y_res == DEFAULT_HEIGHT)
+preferred_flag = M_T_PREFERRED;
+else
+preferred_flag = 0;
+
qxl_add_mode (qxl, pScrn, qxl->modes[i].x_res, qxl->modes[i].y_res,
- M_T_DRIVER);
+ M_T_DRIVER | preferred_flag);
if (qxl->modes[i].x_res > *max_x)
*max_x = qxl->modes[i].x_res;
if (qxl->modes[i].y_res > *max_y)
*max_y = qxl->modes[i].y_res;
}
}
+
+pScrn->virtualX = pScrn->displayWidth = *max_x;
+pScrn->virtualY = *max_y;
+pScrn->virtualFrom = X_PROBED;
}
static Bool
@@ -2489,51 +2484,23 @@ qxl_pre_init (ScrnInfoPtr pScrn, int flags)
pScrn->monitor->vrefresh[0].hi = 75;
pScrn->monitor->nVrefresh = 1;
}
-
+
+/*
+ A 'normal' X driver uses xf86ValidateModes; we roll
+ our own so we can stash the results in qxl.
+ But we are obligated to to set the same values as
+ that call normally does. */
qxl_initialize_x_modes (qxl, pScrn, &max_x, &max_y);
-#if 0
-if (pScrn->display->virtualX == 0 && pScrn->display->virtualY == 0)
-{
- /* It is possible for the largest x + largest y size combined leading
- to a virtual size which will not fit into the framebuffer when this
- happens we
Re: [Spice-devel] Question about poor performance of Ubuntu VMs
Alon, - Original Message - > Which version of qxl is in the ubuntu vm and which in the fedora vm? are the > qemu > invocations exactly the same (other then the image)? Is there an xorg.conf in > the > fedora vm not in the ubuntu vm? I've used Fedora 16, 17, and 18 and they preform well. Here's the answers to the best of my knowledge. Xubuntu 12.04.1 - xserver-xorg-video-qxl 0.0.16-2 Fedora 18 - xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788 So far as the invocations go... whatever virt-manager produced. I used the defaults. I'm using NAT. Here's what ps tells me on the host node: # Xubuntu /usr/libexec/qemu-kvm -S -M rhel6.3.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name Xubuntu-1204-64bit -uuid 37e0aa81-113b-1f1b-08b6-078af8597c4b -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Xubuntu-1204-64bit.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/vmstorage/Xubuntu-1204-64bit.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a2:46:0f,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -spice port=5907,addr= 0.0.0.0 -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 # Fedora /usr/libexec/qemu-kvm -S -M rhel6.3.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name fedora18-64bit -uuid 6e7a2842-73ce-7b91-4d27-74539dfb7432 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fedora18-64bit.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/vmstorage/fedora18-64bit.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:46:77:97,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spic e port=5904,addr=0.0.0.0 -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 So far as the xorg.conf goes... I didn't do anything special. They auto-configured and so far as I know use a dynamic config rather than an actual file. xorg has been that way for some time now. I know you can make an xorg.conf and tell it to use that but it seems to do a fairly good job and if it ain't broke, I don't try to fix it. Well, in this case, maybe it is broke. :) The KVM host both of those are on is: Red Hat Enterprise Linux Server release 6.3 (Santiago) kernel-2.6.32-279.19.1.el6.x86_64 qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64 libvirt-0.9.10-21.el6_3.7.x86_64 So far as anything else goes... it is fully updated so whatever the current versions are in RHEL6. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Question about poor performance of Ubuntu VMs
Alon, - Original Message - > So on the same host a fedora vm works fast but the ubuntu is slow? That is correct. > I suspect the driver is not installed or not recognized in the ubuntu > vm. Can you provide the X log? The log is 94K so I just stuck it in my webspace. Here's the URL: http://scott.coe.montana.edu/kvm-xubuntu-12.04.1-guest-Xorg.0.log Please note our network often sucks so if you happen to have a problem loading that, just use wget with the -c option a few times. :( TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Question about poor performance of Ubuntu VMs
> Greetings, > > I'm a big Red Hat / clone slash Fedora guy... and I use use a lot of > KVM. I primarily create Fedora, RHEL/clone, and Windows KVM guests > and they work great... but every once in a while I like to try out > an Ubuntu release just to see what's new. I have tried their Unity > spin as well as their Xubuntu spin... for a few releases now. I'd > expect Unity to be slow because it is similar to GNOME 3 in that it > wants to do that 3D stuff. But with Xubuntu and XFCE, I'd expect it > to be snappy. That has NOT been my experience. It is really slow. > Moving a window around is extremely choppy and it can even lag out > (where it doesn't respond at all) for periods of time. I haven't > done much troubleshooting of this but I have done a few installs on > a variety of hardware (for the host node) and used a variety of > client machines and the pokey experience has been the same. > > I suspect it has something to do with the mouse emulation used > because the Xubuntu desktop seems to perform fairly well until the > mouse is moved. > > Any ideas? Maybe there is some configuration change either in KVM or > in Xubuntu that will improve the situation. I use virt-manager to > create the guests (on Fedora and RHEL) and pick the closest Ubuntu > version listed. So on the same host a fedora vm works fast but the ubuntu is slow? I suspect the driver is not installed or not recognized in the ubuntu vm. Can you provide the X log? > > TYL, > -- > Scott Dowdle > 704 Church Street > Belgrade, MT 59714 > (406)388-0827 [home] > (406)994-3931 [work] > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
Javaon, - Original Message - > already disabled, still slow response in GUI. :-( It didn't even work until recently (with the release of Fedora 17) as seen in this features page for Fedora 17: https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering As you probably know, GNOME 3 has the 3D required desktop and the Fallback mode desktop. I believe the Fallback mode is supposed to be discontinued if it hasn't been already... but if it is there, you can use that and it should be much faster. Other than that... NO there isn't anything you can do to fix it. You'd have the same problem pretty much with any composited desktop that wants hardware accelerated 3D. As someone already said, Windows works ok because it disables the Aero interface. KDE's 3D stuff seems to work fairly well in SPICE but KDE has two modes and doesn't require hardware accelerated 3D for one of them... which is the one that works. So, if putting a fork in your eye hurts, don't put a fork in your eye. You could run your GNOME 3 desktop on a really fast VM host and have a really fast client connect to it... with a really fast connection (1Gbit) and it'd probably work a little better... but until SPICE ads support for hardware 3D acceleration... or the GNOME 3 guys change it, you get what you get. In fact, there are a bunch physical machines withof video cards that don't work well on Linux that GNOME 3 either won't run on at all... or runs poorly. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Question about poor performance of Ubuntu VMs
Greetings, I'm a big Red Hat / clone slash Fedora guy... and I use use a lot of KVM. I primarily create Fedora, RHEL/clone, and Windows KVM guests and they work great... but every once in a while I like to try out an Ubuntu release just to see what's new. I have tried their Unity spin as well as their Xubuntu spin... for a few releases now. I'd expect Unity to be slow because it is similar to GNOME 3 in that it wants to do that 3D stuff. But with Xubuntu and XFCE, I'd expect it to be snappy. That has NOT been my experience. It is really slow. Moving a window around is extremely choppy and it can even lag out (where it doesn't respond at all) for periods of time. I haven't done much troubleshooting of this but I have done a few installs on a variety of hardware (for the host node) and used a variety of client machines and the pokey experience has been the same. I suspect it has something to do with the mouse emulation used because the Xubuntu desktop seems to perform fairly well until the mouse is moved. Any ideas? Maybe there is some configuration change either in KVM or in Xubuntu that will improve the situation. I use virt-manager to create the guests (on Fedora and RHEL) and pick the closest Ubuntu version listed. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
already disabled, still slow response in GUI. :-( On 01/24/2013 10:52 PM, Yonit Halperin wrote: Hi, On 01/24/2013 08:23 AM, javaon wrote: Thanks for replying, Alon. Yes, I found that 3d rendering in software. But.. is there any method to improve the response speed of Fedora GNOME desktop? You know, Windows XP/7 guest's speed is really pretty fast! Thanks. You can try disabling off screen surfaces for qxl in Xorg.conf Section "Device" Identifier "qxl" Driver "qxl" #Option "DPI" "96 x 96" #Option "ENABLE_IMAGE_CACHE" "True" #Option "ENABLE_FALLBACK_CACHE" "False" Option "ENABLE_SURFACES" "False" EndSection Regards, Yonit. On 01/24/2013 09:13 PM, Alon Levy wrote: hi list, I am running Fedora 18 (GNOME version) as a guest in a host with qemu 1.3. But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file.But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file. By the way, Fedora's XFCE version works smoothly. Does anyone know what the root cause is? Is it caused by spice/qxl 3D driver? The 3d rendering is done in the guest entirely, in software, you can verify by seeing there is no /dev/drm device being open, and looking at X log file should show it is using software emulation. Looking at the cpu usage in the guest it should be high as well. Thanks, ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
Hi, On 01/24/2013 08:23 AM, javaon wrote: Thanks for replying, Alon. Yes, I found that 3d rendering in software. But.. is there any method to improve the response speed of Fedora GNOME desktop? You know, Windows XP/7 guest's speed is really pretty fast! Thanks. You can try disabling off screen surfaces for qxl in Xorg.conf Section "Device" Identifier "qxl" Driver "qxl" #Option "DPI" "96 x 96" #Option "ENABLE_IMAGE_CACHE" "True" #Option "ENABLE_FALLBACK_CACHE" "False" Option "ENABLE_SURFACES" "False" EndSection Regards, Yonit. On 01/24/2013 09:13 PM, Alon Levy wrote: hi list, I am running Fedora 18 (GNOME version) as a guest in a host with qemu 1.3. But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file.But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file. By the way, Fedora's XFCE version works smoothly. Does anyone know what the root cause is? Is it caused by spice/qxl 3D driver? The 3d rendering is done in the guest entirely, in software, you can verify by seeing there is no /dev/drm device being open, and looking at X log file should show it is using software emulation. Looking at the cpu usage in the guest it should be high as well. Thanks, ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Establish a preferred default of 1024x768 correctly.
On 01/24/2013 05:37 AM, Hans de Goede wrote: Hi, Overall comments: 1) I've run several tests with this, and this looks good to go. Great, thanks! 2) As Alon said, please split of the #if 0 blocks removal, I agree they can be removed after this patch, but lets do so in a follow-up patch See my separate email on that. 3) I don't like the hardcoded 1024x768, yes I know it was there before, but while at it can you please add: #define DEFAULT_WIDTH 1024 #define DEFAULT_HEIGHT 768 To the top of qxl_driver.c and use those in the check to set the preferred flag? Sure. Also one small white spice issues, see comments inline. I hate people that send patches that make git am yarf :-/. I'll fix that as well. I have one bit of due diligence I'm going to do as well; (I wanted to make sure the change to qxl_resize_primary_to_virtual shouldn't be it's own patch, and maybe see if that's what led to my NumHeads confusion), but I'll hopefully respin and submit today or tomorrow. Cheers, Jeremy p.s. Hmm, I would expect the stock fc18 to work actually ... Any chance you perhaps also rebuild qemu between the 2 tries ? I'm glad it turned out not be my operator error, this time. That probably drops me from an average operator error rate of 99% to 98% . ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Establish a preferred default of 1024x768 correctly.
Is it possible to break out the #if 0 removals since I don't see any
relation between them and this patch?
I'm a huge fan of smaller, more surgical patches.
And yeah, I'll shift the first #if 0 removal to another patch.
But I think the larger and more material #if 0 removals are
related to this patch. The #if 0'd code has to do with
maximum resolution and default size, which is the code path
I'm directly affecting. But I do think my injected comment could
be a bit more clear, and I'll try to improve that on the
next round as well.
Cheers,
Jeremy
+
+/* Note that we replace the 'normal' xf86ValidateModes call,
+ so this function is obligated to set the same values as
+ that call normally does. */
qxl_initialize_x_modes (qxl, pScrn,&max_x,&max_y);
-#if 0
-if (pScrn->display->virtualX == 0&& pScrn->display->virtualY == 0)
-{
- /* It is possible for the largest x + largest y size combined leading
- to a virtual size which will not fit into the framebuffer when this
- happens we prefer max width and make height as large as possible */
- if (max_x * max_y * (pScrn->bitsPerPixel / 8)>
- qxl->rom->surface0_area_size)
- pScrn->display->virtualY = qxl->rom->surface0_area_size /
- (max_x * (pScrn->bitsPerPixel / 8));
- else
- pScrn->display->virtualY = max_y;
-
- pScrn->display->virtualX = max_x;
-}
-
-if (0>= xf86ValidateModes (pScrn, pScrn->monitor->Modes,
-pScrn->display->modes, clockRanges,
linePitches,
-128, max_x, 128 * 4, 128, max_y,
-pScrn->display->virtualX,
-pScrn->display->virtualY,
-128 * 1024 * 1024, LOOKUP_BEST_REFRESH))
- goto out;
-#endif
-
CHECK_POINT ();
xf86PruneDriverModes (pScrn);
qxl_init_randr (pScrn, qxl);
-#if 0
-/* If no modes are specified in xorg.conf, default to 1024x768 */
-if (pScrn->display->modes == NULL || pScrn->display->modes[0] == NULL)
- for (mode = pScrn->modes; mode; mode = mode->next)
- if (mode->HDisplay == 1024&& mode->VDisplay == 768)
- {
- pScrn->currentMode = mode;
- break;
- }
-#endif
-
-//xf86PrintModes (pScrn);
+
+qxl->virtual_x = pScrn->display->virtualX;
+qxl->virtual_y = pScrn->display->virtualY;
+
xf86SetDpi (pScrn, 0, 0);
if (!xf86LoadSubModule (pScrn, "fb")
--
1.7.10.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
> Thanks for replying, Alon. > > Yes, I found that 3d rendering in software. But.. is there any method > to improve the response speed of Fedora GNOME desktop? You know, > Windows XP/7 guest's speed is really pretty fast! Sadly the 3.x GNOME desktop requires 3d rendering and spice does not know how to speed that up, the usual spice approach of passing through commands all the way to the client only applies to 2d rendering. Windows XP/7 are not doing 3d rendering, hence the difference. > > Thanks. > > On 01/24/2013 09:13 PM, Alon Levy wrote: > >> hi list, > >> > >> I am running Fedora 18 (GNOME version) as a guest in a host with > >> qemu > >> 1.3. But the desktop is slow. I have already opened 3D > >> acceleration > >> in the guest's xml definition file.But the desktop is slow. I have > >> already opened 3D acceleration in the guest's xml definition file. > >> > >> By the way, Fedora's XFCE version works smoothly. > >> > >> Does anyone know what the root cause is? Is it caused by spice/qxl > >> 3D > >> driver? > > The 3d rendering is done in the guest entirely, in software, you > > can verify by seeing there is no /dev/drm device being open, and > > looking at X log file should show it is using software emulation. > > Looking at the cpu usage in the guest it should be high as well. > > > >> Thanks, > >> ___ > >> Spice-devel mailing list > >> Spice-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/spice-devel > >> > > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] server/red_parse_qxl.h: use SpiceCopyBits
---
server/red_parse_qxl.h | 4 +---
spice-common | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/server/red_parse_qxl.h b/server/red_parse_qxl.h
index 3adc9fa..58dc52d 100644
--- a/server/red_parse_qxl.h
+++ b/server/red_parse_qxl.h
@@ -43,9 +43,7 @@ typedef struct RedDrawable {
SpiceCopy copy;
SpiceTransparent transparent;
SpiceAlphaBlend alpha_blend;
-struct {
-SpicePoint src_pos;
-} copy_bits;
+SpiceCopyBits copy_bits;
SpiceBlend blend;
SpiceRop3 rop3;
SpiceStroke stroke;
diff --git a/spice-common b/spice-common
index b46d36b..0acd723 16
--- a/spice-common
+++ b/spice-common
@@ -1 +1 @@
-Subproject commit b46d36bc1c01ca17a64262e157022fd21ad1e795
+Subproject commit 0acd7234223fb184e15307924358a95472abb857
--
1.8.0.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH spice-common] common/draw.h: add SpiceCopyBits
Similar to the almost identity relation between QXLFoo and SpiceFoo for other
structs, this one has just been left out.
---
common/draw.h | 4
1 file changed, 4 insertions(+)
diff --git a/common/draw.h b/common/draw.h
index 3704358..1df42e8 100644
--- a/common/draw.h
+++ b/common/draw.h
@@ -275,6 +275,10 @@ typedef struct SpiceString {
SpiceRasterGlyph *glyphs[0];
} SpiceString;
+typedef struct SpiceCopyBits {
+SpicePoint src_pos;
+} SpiceCopyBits;
+
typedef struct SpiceText {
SpiceString *str;
SpiceRect back_area;
--
1.8.0.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] RFC: add QXLListCmd for batched commands
---
spice/qxl_dev.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/spice/qxl_dev.h b/spice/qxl_dev.h
index a3e91a5..c2fda3a 100644
--- a/spice/qxl_dev.h
+++ b/spice/qxl_dev.h
@@ -351,6 +351,12 @@ typedef struct SPICE_ATTR_PACKED QXLCursorCmd {
uint8_t device_data[QXL_CURSUR_DEVICE_DATA_SIZE]; //todo: dynamic size
from rom
} QXLCursorCmd;
+typedef struct SPICE_ATTR_PACKED QXLListCmd {
+QXLReleaseInfo release_info;
+uint16_t count;
+QXLPHYSICAL commands[0];
+} QXLListCmd;
+
enum {
QXL_DRAW_NOP,
QXL_DRAW_FILL,
--
1.8.0.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
Thanks for replying, Alon. Yes, I found that 3d rendering in software. But.. is there any method to improve the response speed of Fedora GNOME desktop? You know, Windows XP/7 guest's speed is really pretty fast! Thanks. On 01/24/2013 09:13 PM, Alon Levy wrote: hi list, I am running Fedora 18 (GNOME version) as a guest in a host with qemu 1.3. But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file.But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file. By the way, Fedora's XFCE version works smoothly. Does anyone know what the root cause is? Is it caused by spice/qxl 3D driver? The 3d rendering is done in the guest entirely, in software, you can verify by seeing there is no /dev/drm device being open, and looking at X log file should show it is using software emulation. Looking at the cpu usage in the guest it should be high as well. Thanks, ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
> hi list, > > I am running Fedora 18 (GNOME version) as a guest in a host with qemu > 1.3. But the desktop is slow. I have already opened 3D acceleration > in the guest's xml definition file.But the desktop is slow. I have > already opened 3D acceleration in the guest's xml definition file. > > By the way, Fedora's XFCE version works smoothly. > > Does anyone know what the root cause is? Is it caused by spice/qxl 3D > driver? The 3d rendering is done in the guest entirely, in software, you can verify by seeing there is no /dev/drm device being open, and looking at X log file should show it is using software emulation. Looking at the cpu usage in the guest it should be high as well. > > Thanks, > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] settings for qxl memory size
> 2013/1/23 Alon Levy : > > Looks like the client isn't supplying the correct password set > > below. You can also disable passwords by the "disable-ticketing" > > option, i.e. "-spice disable-ticketing,..." > > I didn't notice that warning, I should have disabled passwords for > the > sake of posting, but I did many tests and I'm sure it's not a > password > issue (I have the problem only with qxl enabled). > > This is a log with passwords disabled: > > qxl-0: ram/pri: 32 MB [region 0] > qxl-0: vram/32: 0 MB [region 1] > qxl-0: vram/64: 0 MB [unmapped] > main_channel_link: add main channel client > main_channel_handle_parsed: net test: latency 38.945000 ms, bitrate > 581983518 bps (555.022734 Mbps) > red_channel_client_pre_create_validate: Error client 0x7fe2d619a8f0: > duplicate channel type 2 id 0 > inputs_connect: inputs channel client create > red_channel_client_pre_create_validate: Error client 0x7fe2d619a8f0: > duplicate channel type 2 id 0 > red_dispatcher_set_cursor_peer: > red_dispatcher_set_cursor_peer: > red_channel_client_pre_create_validate: Error client 0x7fe2d619a8f0: > duplicate channel type 4 id 0 > > Is the amount of MB in the first 3 lines as expected? In another test > I tried 16M for both qxl-vga.ram_size and qxl-vga.vram_size but these > lines didn't change. No, it isn't, good that you noticed (bad that I didn't). vram/64 can be (should be - no driver knows how to map it yet unless you changed it) zero but vram/32 should be > 0. How are the bars allocated? is it seabios or something else? if seabios can you enable debugging messages by adding the following to qemu command line (again - this is upstream, I have no idea how it works with xen): -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios > > Qemu invocation: > > /usr/lib/xen/bin/qemu-system-i386 > -xen-domid > 3 > -chardev > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-3,server,nowait > -mon > chardev=libxl-cmd,mode=control > -name > W7 > -k > it > -spice > port=6002,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on > -device > qxl-vga > -global > qxl-vga.vram_size=65536 > -global > qxl-vga.ram_size=65536 > -boot > order=dc > -smp > 2,maxcpus=2 > -device > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:1a:b4:74 > -netdev > type=tap,id=net0,ifname=vif3.0-emu,script=no,downscript=no > --global > qxl-vga.debug=1 > -global > qxl-vga.guestdebug=20 > -M > xenfv > -m > 1920 > -drive > file=/mnt/vm/disks/prova/W7.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback > -drive > file=/mnt/vm/iso/XPSP3PRO.iso,if=ide,index=1,media=cdrom,format=raw,cache=writeback,id=ide-832 > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH xf86-video-qxl 2/2] qxl: Don't add the current mode to the modelist as preferred-mode (rhbz#894421)
Hi, On 01/24/2013 12:54 PM, Hans de Goede wrote: Adding the current mode to the monitor modelist as "extra" preferred mode means that each time the modelist gets queried, and the resolution has changed, a different modelist is returned for the output. A different modelist gets seen as a different monitor by gnome-settings-daemon, causing it to think that the monitor has been unplugged and replaced with another one and to re-do any auto-configuration for that monitor. This causes undesirable "funny" side-effects such as described in detail here: https://bugzilla.redhat.com/show_bug.cgi?id=894421#c7 This patch fixes the "initial resolution too large" problem the adding of the current mode to the list was added for, by instead marking 1024x768, which is our default resolution, as preferred mode. Signed-off-by: Hans de Goede This is a minimal fix for 894421, which I intended to already send yesterday (and I referred to in some other threads). Since we will likely go with Jeremy's more complete "Establish a preferred default of 1024x768 correctly." Patch, this one is sort of obsolete, but I still wanted to send it out here since I referred to it on other threads. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xf86-video-qxl 2/2] qxl: Don't add the current mode to the modelist as preferred-mode (rhbz#894421)
Adding the current mode to the monitor modelist as "extra" preferred
mode means that each time the modelist gets queried, and the resolution
has changed, a different modelist is returned for the output. A different
modelist gets seen as a different monitor by gnome-settings-daemon, causing
it to think that the monitor has been unplugged and replaced with another
one and to re-do any auto-configuration for that monitor.
This causes undesirable "funny" side-effects such as described in detail
here: https://bugzilla.redhat.com/show_bug.cgi?id=894421#c7
This patch fixes the "initial resolution too large" problem the adding
of the current mode to the list was added for, by instead marking 1024x768,
which is our default resolution, as preferred mode.
Signed-off-by: Hans de Goede
---
src/qxl_driver.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index c383c14..063e7a6 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -61,6 +61,9 @@
extern void compat_init_scrn (ScrnInfoPtr);
+#define DEFAULT_WIDTH 1024
+#define DEFAULT_HEIGHT 768
+
#ifdef WITH_CHECK_POINT
#define CHECK_POINT() ErrorF ("%s: %d (%s)\n", __FILE__, __LINE__,
__FUNCTION__);
#else
@@ -2083,15 +2086,6 @@ qxl_output_get_modes (xf86OutputPtr output)
qxl_output_private *qxl_output = output->driver_private;
DisplayModePtr modes = xf86DuplicateModes (qxl_output->qxl->pScrn,
qxl_output->qxl->x_modes);
-if (output &&
-output->crtc && output->crtc->enabled)
-{
- DisplayModePtr crtc_mode = &output->crtc->mode;
- crtc_mode = screen_create_mode (qxl_output->qxl->pScrn,
crtc_mode->HDisplay, crtc_mode->VDisplay, M_T_PREFERRED);
- output->crtc->mode = *crtc_mode;
- modes = xf86ModesAdd (modes, crtc_mode);
-}
-
/* xf86ProbeOutputModes owns this memory */
return modes;
}
@@ -2322,8 +2316,8 @@ qxl_init_randr (ScrnInfoPtr pScrn, qxl_screen_t *qxl)
qxl_crtc->output = output;
}
-qxl->virtual_x = 1024;
-qxl->virtual_y = 768;
+qxl->virtual_x = DEFAULT_WIDTH;
+qxl->virtual_y = DEFAULT_HEIGHT;
pScrn->display->virtualX = qxl->virtual_x;
pScrn->display->virtualY = qxl->virtual_y;
@@ -2339,6 +2333,7 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr
pScrn,
{
int i;
int size;
+int preferred_flag;
*max_x = *max_y = 0;
/* Create a list of modes used by the qxl_output_get_modes */
@@ -2354,8 +2349,13 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr
pScrn,
continue;
}
+if (qxl->modes[i].x_res == 1024 && qxl->modes[i].y_res == 768)
+preferred_flag = M_T_PREFERRED;
+else
+preferred_flag = 0;
+
qxl_add_mode (qxl, pScrn, qxl->modes[i].x_res, qxl->modes[i].y_res,
- M_T_DRIVER);
+ M_T_DRIVER | preferred_flag);
if (qxl->modes[i].x_res > *max_x)
*max_x = qxl->modes[i].x_res;
if (qxl->modes[i].y_res > *max_y)
--
1.8.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xf86-video-qxl 1/2] Send correct count in qxl_update_monitors_config
When we've for example only output qxl-0 and qxl-2 enabled, the heads array of the QxlMonitorsConfig struct we send will be sparse, containing a 0 width and height entry at index 1. Since the qxl-dev (and subsequently the spice-client) will only look at QxlMonitorsConfig.count entries in the heads array (ignoring any 0x0 sized heads), the count must be 3 for this example not 2 as we currently send. Signed-off-by: Hans de Goede --- src/qxl_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qxl_driver.c b/src/qxl_driver.c index e1893dc..c383c14 100644 --- a/src/qxl_driver.c +++ b/src/qxl_driver.c @@ -1101,7 +1101,7 @@ qxl_update_monitors_config (qxl_screen_t *qxl) head->height = crtc->mode.CrtcVDisplay; head->x = crtc->x; head->y = crtc->y; - qxl->monitors_config->count++; + qxl->monitors_config->count = i + 1; qxl_output->status = XF86OutputStatusConnected; } } -- 1.8.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [vdagent-win 2/2] spec: Automatically substitute version
This commit generates a .spec file with the right version number
when configure is run.
---
configure.ac| 1 +
mingw-spice-vdagent.spec| 94 -
mingw-spice-vdagent.spec.in | 92
3 files changed, 93 insertions(+), 94 deletions(-)
delete mode 100644 mingw-spice-vdagent.spec
create mode 100644 mingw-spice-vdagent.spec.in
diff --git a/configure.ac b/configure.ac
index 3fb17ee..12329b4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,6 +74,7 @@ dnl
---
AC_CONFIG_SUBDIRS([spice-protocol])
AC_CONFIG_FILES([
Makefile
+mingw-spice-vdagent.spec
])
AC_OUTPUT
diff --git a/mingw-spice-vdagent.spec b/mingw-spice-vdagent.spec
deleted file mode 100644
index 1351419..000
--- a/mingw-spice-vdagent.spec
+++ /dev/null
@@ -1,94 +0,0 @@
-%{?mingw_package_header}
-
-#define _version_suffix -e198
-
-Name: mingw-spice-vdagent
-Version:0.7.0
-Release:1%{?dist}%{?extra_release}
-Summary:MinGW Windows SPICE guest agent
-
-License:GPLv2+
-URL:http://spice-space.org/
-Source0:vdagent-win-%{version}%{?_version_suffix}.tar.xz
-
-BuildRequires: mingw32-filesystem >= 23
-BuildRequires: mingw64-filesystem >= 23
-BuildRequires: mingw32-cximage-static
-BuildRequires: mingw64-cximage-static
-BuildRequires: mingw32-jasper-static
-BuildRequires: mingw64-jasper-static
-BuildRequires: mingw32-libjpeg-turbo-static
-BuildRequires: mingw64-libjpeg-turbo-static
-BuildRequires: mingw32-libpng-static
-BuildRequires: mingw64-libpng-static
-BuildRequires: mingw32-libtiff-static
-BuildRequires: mingw64-libtiff-static
-BuildRequires: mingw32-zlib-static
-BuildRequires: mingw64-zlib-static
-BuildRequires: pkgconfig
-
-BuildArch: noarch
-
-%package -n mingw32-spice-vdagent
-Summary:MinGW Windows SPICE guest agent
-
-%package -n mingw64-spice-vdagent
-Summary:MinGW Windows SPICE guest agent
-
-%description
-Spice agent for Windows guests offering the following features:
-
-Features:
-* Client mouse mode (no need to grab mouse by client, no mouse lag)
- this is handled by the daemon by feeding mouse events into the kernel
- via uinput.
-* Automatic adjustment of the Windows desktop resolution to the client
resolution
-* Support of copy and paste (text and images) between the active Windows
- session and the client
-
-%description -n mingw32-spice-vdagent
-Spice agent for Windows guests offering the following features:
-
-Features:
-* Client mouse mode (no need to grab mouse by client, no mouse lag)
- this is handled by the daemon by feeding mouse events into the kernel
- via uinput.
-* Automatic adjustment of the Windows desktop resolution to the client
resolution
-* Support of copy and paste (text and images) between the active Windows
- session and the client
-
-%description -n mingw64-spice-vdagent
-Spice agent for Windows guests offering the following features:
-
-Features:
-* Client mouse mode (no need to grab mouse by client, no mouse lag)
- this is handled by the daemon by feeding mouse events into the kernel
- via uinput.
-* Automatic adjustment of the Windows desktop resolution to the client
resolution
-* Support of copy and paste (text and images) between the active Windows
- session and the client
-
-%prep
-%setup -q -n vdagent-win-%{version}%{?_version_suffix}
-
-%{mingw_debug_package}
-
-%build
-%mingw_configure
-%mingw_make %{?_smp_mflags} V=1
-
-
-%install
-%mingw_make_install DESTDIR=$RPM_BUILD_ROOT
-
-%files -n mingw32-spice-vdagent
-%defattr(-,root,root)
-%{mingw32_bindir}/vdagent.exe
-%{mingw32_bindir}/vdservice.exe
-
-%files -n mingw64-spice-vdagent
-%defattr(-,root,root)
-%{mingw64_bindir}/vdagent.exe
-%{mingw64_bindir}/vdservice.exe
-
-%changelog
diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
new file mode 100644
index 000..d1bcf70
--- /dev/null
+++ b/mingw-spice-vdagent.spec.in
@@ -0,0 +1,92 @@
+%{?mingw_package_header}
+
+#define _version_suffix -e198
+
+Name: mingw-spice-vdagent
+Version:@VERSION@
+Release:1%{?dist}%{?extra_release}
+Summary:MinGW Windows SPICE guest agent
+
+License:GPLv2+
+URL:http://spice-space.org/
+Source0:vdagent-win-%{version}%{?_version_suffix}.tar.xz
+
+BuildRequires: mingw32-filesystem >= 23
+BuildRequires: mingw64-filesystem >= 23
+BuildRequires: mingw32-cximage-static
+BuildRequires: mingw64-cximage-static
+BuildRequires: mingw32-jasper-static
+BuildRequires: mingw64-jasper-static
+BuildRequires: mingw32-libjpeg-turbo-static
+BuildRequires: mingw64-libjpeg-turbo-static
+BuildRequires: mingw32-libpng-static
+BuildRequires: mingw64-libpng-static
+BuildRequires: mingw32-libtiff-static
+BuildRequires: mingw64-libtiff-static
+BuildRequires: mingw32-zlib-static
+BuildRequires: mingw64-zlib-static
+BuildRequi
[Spice-devel] [vdagent-win 1/2] spec: Add missing call to %mingw_debug_packages
This automatically generates the needed debug packages for .debug
files. Without this, the rpm build fails.
---
mingw-spice-vdagent.spec | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-spice-vdagent.spec b/mingw-spice-vdagent.spec
index 7674ba0..1351419 100644
--- a/mingw-spice-vdagent.spec
+++ b/mingw-spice-vdagent.spec
@@ -71,6 +71,7 @@ Features:
%prep
%setup -q -n vdagent-win-%{version}%{?_version_suffix}
+%{mingw_debug_package}
%build
%mingw_configure
--
1.8.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Establish a preferred default of 1024x768 correctly.
Hi,
Overall comments:
1) I've run several tests with this, and this looks good to go.
2) As Alon said, please split of the #if 0 blocks removal, I agree they can
be removed after this patch, but lets do so in a follow-up patch
3) I don't like the hardcoded 1024x768, yes I know it was there before, but
while at it can you please add:
#define DEFAULT_WIDTH 1024
#define DEFAULT_HEIGHT 768
To the top of qxl_driver.c and use those in the check to set the preferred
flag?
Also one small white spice issues, see comments inline.
I believe that with the above items fixed this patch can be pushed.
On 01/23/2013 11:40 PM, Jeremy White wrote:
This fixes a bug with x-spice where you could not specify
a default mode in an xorg.conf modeline that was greater
than 1024x768. This also eliminates (and partially
reverts) patch c1b537fc.
It may also fix bug 894421, where gnome modes flicker
and work poorly.
Signed-off-by: Jeremy White
---
src/qxl_driver.c | 90 --
1 file changed, 20 insertions(+), 70 deletions(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index e1893dc..546be6b 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -951,13 +951,6 @@ qxl_resize_primary_to_virtual (qxl_screen_t *qxl)
{
ScreenPtr pScreen;
long new_surface0_size;
-
-if ((qxl->primary_mode.x_res == qxl->virtual_x &&
- qxl->primary_mode.y_res == qxl->virtual_y) &&
-qxl->device_primary == QXL_DEVICE_PRIMARY_CREATED)
-{
- return TRUE; /* empty Success */
-}
ErrorF ("resizing primary to %dx%d\n", qxl->virtual_x, qxl->virtual_y);
@@ -1780,15 +1773,7 @@ qxl_screen_init (SCREEN_INIT_ARGS_DECL)
goto out;
if (!miSetPixmapDepths ())
goto out;
-pScrn->displayWidth = pScrn->virtualX;
-#if 0
-ErrorF ("allocated %d x %d %p\n", pScrn->virtualX, pScrn->virtualY,
qxl->fb);
-#endif
-
-pScrn->virtualX = pScrn->currentMode->HDisplay;
-pScrn->virtualY = pScrn->currentMode->VDisplay;
-
/* Set up resources */
qxl_reset_and_create_mem_slots (qxl);
ErrorF ("done reset\n");
@@ -2083,15 +2068,6 @@ qxl_output_get_modes (xf86OutputPtr output)
qxl_output_private *qxl_output = output->driver_private;
DisplayModePtr modes = xf86DuplicateModes (qxl_output->qxl->pScrn,
qxl_output->qxl->x_modes);
-if (output &&
-output->crtc && output->crtc->enabled)
-{
- DisplayModePtr crtc_mode = &output->crtc->mode;
- crtc_mode = screen_create_mode (qxl_output->qxl->pScrn,
crtc_mode->HDisplay, crtc_mode->VDisplay, M_T_PREFERRED);
- output->crtc->mode = *crtc_mode;
- modes = xf86ModesAdd (modes, crtc_mode);
-}
-
/* xf86ProbeOutputModes owns this memory */
return modes;
}
@@ -2322,12 +2298,6 @@ qxl_init_randr (ScrnInfoPtr pScrn, qxl_screen_t *qxl)
qxl_crtc->output = output;
}
-qxl->virtual_x = 1024;
-qxl->virtual_y = 768;
-
-pScrn->display->virtualX = qxl->virtual_x;
-pScrn->display->virtualY = qxl->virtual_y;
-
xf86InitialConfiguration (pScrn, TRUE);
/* all crtcs are enabled here, but their mode is 0,
resulting monitor config empty atm */
@@ -2339,6 +2309,7 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr
pScrn,
{
int i;
int size;
+int preferred_flag;
*max_x = *max_y = 0;
/* Create a list of modes used by the qxl_output_get_modes */
@@ -2353,15 +2324,24 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr
pScrn,
qxl->modes[i].x_res, qxl->modes[i].y_res);
continue;
}
-
+
You're changing whitespace here. Either don't change it all, or if you do, nuke
it all (other then the newline). What you do now makes git am complain, and
rightfully so.
+if (qxl->modes[i].x_res == 1024 && qxl->modes[i].y_res == 768)
+preferred_flag = M_T_PREFERRED;
+else
+preferred_flag = 0;
+
qxl_add_mode (qxl, pScrn, qxl->modes[i].x_res, qxl->modes[i].y_res,
- M_T_DRIVER);
+ M_T_DRIVER | preferred_flag);
if (qxl->modes[i].x_res > *max_x)
*max_x = qxl->modes[i].x_res;
if (qxl->modes[i].y_res > *max_y)
*max_y = qxl->modes[i].y_res;
}
}
+
+pScrn->virtualX = pScrn->displayWidth = *max_x;
+pScrn->virtualY = *max_y;
+pScrn->virtualFrom = X_PROBED;
}
static Bool
@@ -2489,51 +2469,21 @@ qxl_pre_init (ScrnInfoPtr pScrn, int flags)
pScrn->monitor->vrefresh[0].hi = 75;
pScrn->monitor->nVrefresh = 1;
}
-
+
+/* Note that we replace the 'normal' xf86ValidateModes call,
+ so this function is obligated to set the same values as
+ that call normally does. */
qxl_initialize_x_modes (qxl, pScrn, &max_x, &max_y);
-#if 0
-if (pScrn->display->virtualX == 0 && pScrn->di
[Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
hi list, I am running Fedora 18 (GNOME version) as a guest in a host with qemu 1.3. But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file.But the desktop is slow. I have already opened 3D acceleration in the guest's xml definition file. By the way, Fedora's XFCE version works smoothly. Does anyone know what the root cause is? Is it caused by spice/qxl 3D driver? Thanks, ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [video-qxl 2/2] Default to only one head, not 4.
Hi, On 01/23/2013 07:47 PM, Jeremy White wrote: Aha! I built a qxl_driver from git tip, put that on my fc18 guest, and now I see 4 displays in my drop down list. (I had mistakenly presumed that by up to date fc18 guest, you wanted those stock qxl packages, but the fc18 qxl driver is fairly old). Ok, I figured out the problem, the F-18 packages build with spice-protocol-0.12.1 in the buildroot rather then 0.12.2 causing support for the new dynamic monitor stuff to be turned off compile time. Once we've your fix upstream I'll do a new Fedora build including some fixes from git. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] settings for qxl memory size
2013/1/23 Alon Levy : > Looks like the client isn't supplying the correct password set below. You can > also disable passwords by the "disable-ticketing" option, i.e. "-spice > disable-ticketing,..." I didn't notice that warning, I should have disabled passwords for the sake of posting, but I did many tests and I'm sure it's not a password issue (I have the problem only with qxl enabled). This is a log with passwords disabled: qxl-0: ram/pri: 32 MB [region 0] qxl-0: vram/32: 0 MB [region 1] qxl-0: vram/64: 0 MB [unmapped] main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 38.945000 ms, bitrate 581983518 bps (555.022734 Mbps) red_channel_client_pre_create_validate: Error client 0x7fe2d619a8f0: duplicate channel type 2 id 0 inputs_connect: inputs channel client create red_channel_client_pre_create_validate: Error client 0x7fe2d619a8f0: duplicate channel type 2 id 0 red_dispatcher_set_cursor_peer: red_dispatcher_set_cursor_peer: red_channel_client_pre_create_validate: Error client 0x7fe2d619a8f0: duplicate channel type 4 id 0 Is the amount of MB in the first 3 lines as expected? In another test I tried 16M for both qxl-vga.ram_size and qxl-vga.vram_size but these lines didn't change. Qemu invocation: /usr/lib/xen/bin/qemu-system-i386 -xen-domid 3 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-3,server,nowait -mon chardev=libxl-cmd,mode=control -name W7 -k it -spice port=6002,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on -device qxl-vga -global qxl-vga.vram_size=65536 -global qxl-vga.ram_size=65536 -boot order=dc -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:1a:b4:74 -netdev type=tap,id=net0,ifname=vif3.0-emu,script=no,downscript=no --global qxl-vga.debug=1 -global qxl-vga.guestdebug=20 -M xenfv -m 1920 -drive file=/mnt/vm/disks/prova/W7.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback -drive file=/mnt/vm/iso/XPSP3PRO.iso,if=ide,index=1,media=cdrom,format=raw,cache=writeback,id=ide-832 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [video-qxl 2/2] Default to only one head, not 4.
Hi, On 01/23/2013 07:07 PM, Jeremy White wrote: I currently have qemu-1.3 + spice server 0.12-2, with spice client gtk and virt-viewer from git tip of yesterday. I am running a fully up to date fc18 guest. Hmm that should be new enough I think... I launch qemu from the command line, adding the -global qxl-vga.revision flag as you suggested. I still don't see the extra displays show up. Anything else? What is your qemu cmdline ? Have you enabled: 1) spice as display protocol (-spice) 2) qxl as vga adapter (-vga qxl) 3) The spice agent chardevice (see below) Here's my command line: qemu-system-x86_64 -machine accel=kvm:tcg -cpu kvm64 -m 1G -hda fedora18.qcow2 \ -usb -spice port=5900,disable-ticketing -vga qxl \ -global qxl-vga.revision=4 \ -device virtio-serial \ -chardev spicevmc,id=vdagent,name=vdagent \ -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 Any chance I've got a configure glitch? I've checked my config.log outputs and haven't seen anything obvious, but perhaps I'm compiling the feature out. You need to have the latest spice-protocol and spice-server headers installed when building qemu, maybe you build them in the wrong order? Also replying to your next mail here as it is related: On 01/23/2013 07:47 PM, Jeremy White wrote:> Aha! I built a qxl_driver from git tip, put that on my fc18 guest, and > now I see 4 displays in my drop down list. > > (I had mistakenly presumed that by up to date fc18 guest, you wanted > those stock qxl packages, but the fc18 qxl driver is fairly old). Hmm, I would expect the stock fc18 to work actually ... Any chance you perhaps also rebuild qemu between the 2 tries ? /me goes and checks F-18 as guest (I've been using F-17 with qxl-drv + agent from git sofar) Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [video-qxl 2/2] Default to only one head, not 4.
Hi, On 01/23/2013 11:39 PM, Jeremy White wrote: BTW reading patch 1 again, I wonder what exactly it tries to solve, since currently when using spice with qemu (no experience with x-spice) you can already set modes > 1024x768 without problems. Alright, I've spent my day relearning this code, and feel I have a better grasp. The issue is primarily this code here: http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/tree/src/qxl_driver.c#n2325 That sets the current virtual x/y to 1024x768, and calls Xorg's code to process the initial configuration. One of the things that code does is read the configured modelines in the supplied xorg.conf file, and finds a mode that fits within that virtual size. However, having had the virtual display set to 1024, that code will apply that as a maximum, and will pick a modeline from the spiceqxl.xorg.conf file that is within 1024x768. You *can* use xrandr to change to a larger resolution later on, but you cannot specify a default starting resolution in the spiceqxl.xorg.conf file. As far as I can tell, virt-viewer usage never uses an xorg.conf file, so you guys never see this problem. You've always got gnome-settings-daemon or someone else resizing displays for you (which does, in fact work). In my humble opinion, the current code attempts to set a default mode of 1024x768 in a crude and incorrect fashion. This led to Marc-André's patch of last July (c1b537fc, Return a preferred mode matching the current mode), which I think in turn triggers bug 894421. Agreed. The good news is that I ever so humbly think my patch 1 fixes all of these issues. Agreed too, I actually send a patch yesterday which borrows part of your patch to fix bug 894421. Essentially, it sets the M_T_PREFERRED flag on a 1024x768 mode in a non invasive way. In my testing, it works correctly for my case, and for the cases I tried with virt viewer and fc18. I was able to reproduce the behavior Marc-André reported last summer, and confirm that my patch seems to also correct for it. Good! I do have some mysteries. fc18 doesn't seem to restore screen resolution after reboot, which surprises me. (This is true both with and without my patch). This is normal behavior. The screen resolution "restoring" is done by gnome-settings-daemon (or something similar if running another desktop environment) and gnome-settings-manager will only restore the last resolution set through gnome-display-settings. So if you've changed the size by simply resizing the window this won't get restored since it never got stored in the gnome-settings. So you end up with the default 1024x768, unless you've actually used gnome-display-settings before, and then you end up with whatever you picked the last time you ran gnome-display-settings. This is all not very pretty, but basically the agent and the gnome-settings stuff are running independent of each other, and integrating them is tricky because we don't want to dependent on a certain desktop environment. I also could not reproduce bug 894421, I can and I'm going to try your patch now instead of my more minimal fix. > although without my patch I see a variation of it, where default window sizes are often perversely small. Yes I just hit that too, but only once. I'm happy to hear that your patch fixes this too :) I am resubmitting my patch 1 as a new patch, which partially reverts c1b537fc; I would appreciate it if others could review that code. I've reviewed it and it looks good, but I'm a bit unfamiliar with some of the parts of xorg involved. I'm going to do some testing with your patch now on both RHEL-6.4 and F-18 guests and then I'll reply to the mail where you send the new version of the patch. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Establish a preferred default of 1024x768 correctly.
On Wed, Jan 23, 2013 at 04:40:38PM -0600, Jeremy White wrote:
> This fixes a bug with x-spice where you could not specify
> a default mode in an xorg.conf modeline that was greater
> than 1024x768. This also eliminates (and partially
> reverts) patch c1b537fc.
>
> It may also fix bug 894421, where gnome modes flicker
> and work poorly.
Is it possible to break out the #if 0 removals since I don't see any
relation between them and this patch?
>
> Signed-off-by: Jeremy White
> ---
> src/qxl_driver.c | 90
> --
> 1 file changed, 20 insertions(+), 70 deletions(-)
>
> diff --git a/src/qxl_driver.c b/src/qxl_driver.c
> index e1893dc..546be6b 100644
> --- a/src/qxl_driver.c
> +++ b/src/qxl_driver.c
> @@ -951,13 +951,6 @@ qxl_resize_primary_to_virtual (qxl_screen_t *qxl)
> {
> ScreenPtr pScreen;
> long new_surface0_size;
> -
> -if ((qxl->primary_mode.x_res == qxl->virtual_x &&
> - qxl->primary_mode.y_res == qxl->virtual_y) &&
> -qxl->device_primary == QXL_DEVICE_PRIMARY_CREATED)
> -{
> - return TRUE; /* empty Success */
> -}
>
> ErrorF ("resizing primary to %dx%d\n", qxl->virtual_x, qxl->virtual_y);
>
> @@ -1780,15 +1773,7 @@ qxl_screen_init (SCREEN_INIT_ARGS_DECL)
> goto out;
> if (!miSetPixmapDepths ())
> goto out;
> -pScrn->displayWidth = pScrn->virtualX;
>
> -#if 0
> -ErrorF ("allocated %d x %d %p\n", pScrn->virtualX, pScrn->virtualY,
> qxl->fb);
> -#endif
> -
> -pScrn->virtualX = pScrn->currentMode->HDisplay;
> -pScrn->virtualY = pScrn->currentMode->VDisplay;
> -
> /* Set up resources */
> qxl_reset_and_create_mem_slots (qxl);
> ErrorF ("done reset\n");
> @@ -2083,15 +2068,6 @@ qxl_output_get_modes (xf86OutputPtr output)
> qxl_output_private *qxl_output = output->driver_private;
> DisplayModePtr modes = xf86DuplicateModes (qxl_output->qxl->pScrn,
> qxl_output->qxl->x_modes);
>
> -if (output &&
> -output->crtc && output->crtc->enabled)
> -{
> - DisplayModePtr crtc_mode = &output->crtc->mode;
> - crtc_mode = screen_create_mode (qxl_output->qxl->pScrn,
> crtc_mode->HDisplay, crtc_mode->VDisplay, M_T_PREFERRED);
> - output->crtc->mode = *crtc_mode;
> - modes = xf86ModesAdd (modes, crtc_mode);
> -}
> -
> /* xf86ProbeOutputModes owns this memory */
> return modes;
> }
> @@ -2322,12 +2298,6 @@ qxl_init_randr (ScrnInfoPtr pScrn, qxl_screen_t *qxl)
> qxl_crtc->output = output;
> }
>
> -qxl->virtual_x = 1024;
> -qxl->virtual_y = 768;
> -
> -pScrn->display->virtualX = qxl->virtual_x;
> -pScrn->display->virtualY = qxl->virtual_y;
> -
> xf86InitialConfiguration (pScrn, TRUE);
> /* all crtcs are enabled here, but their mode is 0,
> resulting monitor config empty atm */
> @@ -2339,6 +2309,7 @@ qxl_initialize_x_modes (qxl_screen_t *qxl, ScrnInfoPtr
> pScrn,
> {
> int i;
> int size;
> +int preferred_flag;
>
> *max_x = *max_y = 0;
> /* Create a list of modes used by the qxl_output_get_modes */
> @@ -2353,15 +2324,24 @@ qxl_initialize_x_modes (qxl_screen_t *qxl,
> ScrnInfoPtr pScrn,
> qxl->modes[i].x_res, qxl->modes[i].y_res);
> continue;
> }
> -
> +
> +if (qxl->modes[i].x_res == 1024 && qxl->modes[i].y_res == 768)
> +preferred_flag = M_T_PREFERRED;
> +else
> +preferred_flag = 0;
> +
> qxl_add_mode (qxl, pScrn, qxl->modes[i].x_res, qxl->modes[i].y_res,
> - M_T_DRIVER);
> + M_T_DRIVER | preferred_flag);
> if (qxl->modes[i].x_res > *max_x)
> *max_x = qxl->modes[i].x_res;
> if (qxl->modes[i].y_res > *max_y)
> *max_y = qxl->modes[i].y_res;
> }
> }
> +
> +pScrn->virtualX = pScrn->displayWidth = *max_x;
> +pScrn->virtualY = *max_y;
> +pScrn->virtualFrom = X_PROBED;
> }
>
> static Bool
> @@ -2489,51 +2469,21 @@ qxl_pre_init (ScrnInfoPtr pScrn, int flags)
> pScrn->monitor->vrefresh[0].hi = 75;
> pScrn->monitor->nVrefresh = 1;
> }
> -
> +
> +/* Note that we replace the 'normal' xf86ValidateModes call,
> + so this function is obligated to set the same values as
> + that call normally does. */
> qxl_initialize_x_modes (qxl, pScrn, &max_x, &max_y);
>
> -#if 0
> -if (pScrn->display->virtualX == 0 && pScrn->display->virtualY == 0)
> -{
> - /* It is possible for the largest x + largest y size combined leading
> -to a virtual size which will not fit into the framebuffer when this
> -happens we prefer max width and make height as large as possible */
> - if (max_x * max_y * (pScrn->bitsPerPixel / 8) >
> - qxl->rom->surface0_area_size)
> - pScrn->display->virtualY = q
Re: [Spice-devel] cut/paste failure on Windows 7 guest
On 23/01/2013 15:34, Christophe Fergeau wrote: On Wed, Jan 23, 2013 at 01:10:15PM +0100, Han Pilmeyer wrote: I'm really happy that Cole made available the latest Windows drivers. However, as a naïve Fedora user, this is really confusing. For as far as I can tell the virtio-win package is no longer shipping with Fedora. Did it ever ship with Fedora? Ah, good point. I switched distros when I started to use KVM, so I'm actually not sure. Could be that the virtio-win as a package is only available with RHEL through RHN, perhaps. It would be nice for the Fedora users if there was an easy way to get to the Windows guest drivers with a version that is appropriate for their host os. It would probably help if I sync the guest tools installer version number with the virtio-win version number. It will probably be harder to do that for qxl and the agent though. Christophe I can just say that the spice-guest-tools seem to be a very nice way to get the guest drivers installed on Windows. If the version number somehow matches the version of the drivers from virtio-win, that would be a plus. Cheers, Han ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
