Re: [Spice-devel] [ovirt-users] Re: remote-viewer Spice Problem on MacOS
+Spice devel mailing list. On Thu, Jun 21, 2018, 11:57 PM John Florian wrote: > > On 2018-06-21 08:20, Michal Skrivanek wrote: > > Any connectivity issue should no really be dependent on what you do in > guest > Agreed > > Still, please bring that up to SPICE team - > https://www.spice-space.org/support.html > > I was just trying to do so myself. If I do a Simple Search at > https://bugs.freedesktop.org/query.cgi I can choose the "Spice" product, > but I found nothing. So I attempted to file a new bug and I must pick a > product on which to enter the bug, but there "Spice" is not an option. > Huh? > ___ > Users mailing list -- us...@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/us...@ovirt.org/message/ZZKIRK3CHZTJ6AAEQAOZOSXFFAGLIRE4/ > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-list] Fwd: [ovirt-users] Fwd: VM hanging at boot - [drm] Initialized qxl
On Wed, Jun 20, 2018 at 12:26 PM, Christophe Fergeau wrote: > On Tue, Jun 19, 2018 at 06:36:26AM -0400, David Blechter wrote: > > re-directing to the correct upstream list. In the future all ovirt/spice > > related issue should be address in the spice-de...@freedesktop.org > list. > > > > > > Thank you, > > David Blechter > > 978-392-3182 <(978)%20392-3182> > > > > On Tue, Jun 19, 2018 at 2:26 AM, Yaniv Kaul wrote: > > > > > Anyone monitoring oVirt mailing list for Spice related issues? > > > Y. > > > > > > -- Forwarded message - > > > From: Leo David > > > Date: Thu, Jun 14, 2018, 9:36 AM > > > Subject: [ovirt-users] Fwd: VM hanging at boot - [drm] Initialized qxl > > > To: users > > > > > > > > > > > > -- Forwarded message -- > > > From: Leo David > > > Date: Wed, Jun 13, 2018 at 8:24 PM > > > Subject: VM hanging at boot - [drm] Initialized qxl > > > To: us...@ovirt.org > > > > > > > > > Hello everyone, > > > I have some Centos7 vms created from template ( CentOS 7 Generic Cloud > > > Image v1802 for x86_64 ) > > > I have alocated planty of resources to them, but they all have this > issue > > > when starting, they hang with the following message in console about > 5-7 > > > minutes. > > > > > > [drm] Initialized qxl 0.1.0 20120117 for :00:02:0 on mirror 0 > > > > > > After a while, vm eventually boots up... > > > Running self-hosted ovirt-node 4.2 > > > Does anyone know what could be the issue for this behavior ? > > > Thank you ! > > There were recently some hangs at startup due to a kernel bug in the qxl > driver related to atomic modesetting, no idea if centos could be > impacted by this or not. Does the issue go away when using another > graphics device than QXL? > Can you please respond on the oVirt users mailing list? Y. > > Christophe > > > > -- > > > Best regards, Leo David > > > > > > So i have installed both ovirt-guest-agent-common and spice-vdagent. > It > > > makes no difference, kernel hangs exaclty 5 minutes at each reboot, > with > > > this message. > > > Any thoghts on this ? > > > Being a bit stucked on this issue, I can't move forward in configuring > > > vms and getting them into testing/production. > > > > > > > > > > > > -- > > > Best regards, Leo David > > > ___ > > > Users mailing list -- us...@ovirt.org > > > To unsubscribe send an email to users-le...@ovirt.org > > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > > > oVirt Code of Conduct: https://www.ovirt.org/ > community/about/community- > > > guidelines/ > > > List Archives: https://lists.ovirt.org/archives/list/us...@ovirt.org/ > > > message/DYB4YXQ4CQBL5FSLH34SUCDOGVK3QFVW/ > > > > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Failure to compile spice-gtk: spicy.c:1711:10: error: ignoring return value of ‘write’
CC spicy-spicy.o spicy.c: In function ‘port_data’: spicy.c:1711:10: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors Latest commit: commit a9b7e4cbb31a3457a90582ebe5cdb177393edbd2 Author: Dunrong Huang riegama...@gmail.com Date: Wed Dec 5 19:01:00 2012 +0800 spice-widget: Fix rendering issue with X11 backend enabled commit 5ec6e4d fixes a rendering issue on win32 platform, but raises another bug on linux platform. If X11 backend is enabled, app window will becomes while screen when draging it. This bug can be reproduced easily: compile spice-gtk using: $ ./configure --with-gtk=2.0 --with-x11 $ make $ gtk/spicy -h host -p port Signed-off-by: Dunrong Huang riegama...@gmail.com ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spice-xpi features
Windows support would be nice, so one could use oVirt web admin on Windows without IE. Y. - Original Message - Hello folks, I would like to ask you all: Do you have any feature/improvement in mind, that can be added to spice-xpi plugin? Maybe, it is the time, when the plugin can have it's minor version bumped up. Thank you. -- Peter Hatina EMEA ENG-Base Operating Systems Red Hat Czech, Brno ___ 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] Failure to compile [was: [Spice-commits] gtk/channel-display.c]
On 09/10/2012 11:57 AM, Christophe Fergeau wrote: Hey, On Sat, Sep 08, 2012 at 04:54:53PM -0400, Yaniv Kaul wrote: channel-display.c: In function 'spice_display_channel_reset_capabilities': channel-display.c:685:247: error: 'SPICE_DISPLAY_CAP_A8_SURFACE' undeclared (first use in this function) channel-display.c:685:247: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [channel-display.lo] Error 1 spice/spice-gtk should now be fixed, thanks for the report! Christophe Confirmed, great and thanks. I'd be happy if we could avoid such situations in the future. I know we (used to?) have a build-bot for Spice. Is it alive and working? Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failure to compile [was: [Spice-commits] gtk/channel-display.c]
On 09/10/2012 05:57 PM, Alon Levy wrote: On Mon, Sep 10, 2012 at 12:08:30PM +0300, Yaniv Kaul wrote: Confirmed, great and thanks. I'd be happy if we could avoid such situations in the future. I know we (used to?) have a build-bot for Spice. Is it alive and working? It was working a few weeks ago since I got a broken build email after a commit I made. Maybe the 'broken build' emails should go to some mailing list though, I think they only notify the committer currently. Note that a build bot won't avoid such situations, it will only make them known sooner. I'll ask for a spice-builds mailing list? We could do what other build systems do - have commits pushed by jenkins and have committers push to a jenkins monitored repository (via push with a git rule probably). How does that sound? Great - and Jenkins could also run the tests that Spice has. Y. Christophe ___ 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] Failure to compile [was: [Spice-commits] gtk/channel-display.c]
channel-display.c: In function 'spice_display_channel_reset_capabilities': channel-display.c:685:247: error: 'SPICE_DISPLAY_CAP_A8_SURFACE' undeclared (first use in this function) channel-display.c:685:247: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [channel-display.lo] Error 1 I'm sure it's something I'm again failing to understand. I have it in spice-protocol repository, but not in ./spice-common/spice-protocol/spice/protocol.h so I reckon the spice-protocol module within spice-gtk is not updated? Same with spice itself: [ykaul@ykaul spice]$ grep -R SPICE_DISPLAY_CAP_A8_SURFACE * client/display_channel.cpp:set_capability(SPICE_DISPLAY_CAP_A8_SURFACE); server/red_worker.c:if (red_channel_client_test_remote_cap(rcc, SPICE_DISPLAY_CAP_A8_SURFACE)) server/red_worker.c:SET_CAP(caps, SPICE_DISPLAY_CAP_A8_SURFACE); And it fails compilation as well. Y. - Original Message - gtk/channel-display.c |1 + 1 file changed, 1 insertion(+) New commits: commit 1bcb20fd74502642bc057b16058c89aa43a4b819 Author: Søren Sandmann Pedersen s...@redhat.com Date: Sun Sep 2 16:38:28 2012 -0400 Advertise SPICE_DISPLAY_CAP_A8_SURFACE diff --git a/gtk/channel-display.c b/gtk/channel-display.c index 99fe9c9..326ad22 100644 --- a/gtk/channel-display.c +++ b/gtk/channel-display.c @@ -682,6 +682,7 @@ static void spice_display_channel_reset_capabilities(SpiceChannel *channel) spice_channel_set_capability(SPICE_CHANNEL(channel), SPICE_DISPLAY_CAP_SIZED_STREAM); spice_channel_set_capability(SPICE_CHANNEL(channel), SPICE_DISPLAY_CAP_MONITORS_CONFIG); spice_channel_set_capability(SPICE_CHANNEL(channel), SPICE_DISPLAY_CAP_COMPOSITE); +spice_channel_set_capability(SPICE_CHANNEL(channel), SPICE_DISPLAY_CAP_A8_SURFACE); } static void spice_display_channel_init(SpiceDisplayChannel *channel) ___ Spice-commits mailing list spice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-commits ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Error while updating spice-gtk
Updating 836a18d..4b39f32 error: The following untracked working tree files would be overwritten by merge: doc/reference/spice-gtk-overrides.txt Please move or remove them before you can merge. Anything i'm doing wrong? Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE session hanging randomly
Any chance one of the participants (either the server or the client, but most likely the client) is heavily swapping? It's enough for a VM to have parts of its memory swapping to crawl. Alternatively, are you over-committing with CPU? For example, running a 4vCPU VM on a 2pCPU host? What do you see in 'top' ? 'kvm_stat' ? Y. - Original Message - Hello All, I was wondering if anyone else has experienced similar behavior to what I'm seeing. Randomly, while I'm connected to a remote VM using SPICE, the screen and all input will freeze/hang for about 30 seconds to 1 minute. When it returns to normal any key presses or mouse clicks that happened while the session was hung are acted upon. I've looked through the VM's log file located in /var/log/libvirt/qemu but do not see anything that looks like an error. Additional information: Host: CentOS 6.3 qemu-kvm-0.12.1.2-2.295.el6_3.1.x86_64 spice-server-0.10.1-10.el6.x86_64 libvirt-0.9.10-21.el6_3.3.x86_64 VM Guest: Windows 7 and Windows 2008 R2 Client: CentOS 6.3 virt-viewer-0.5.2-9.el6.x86_64 Just curious if anyone else has seen this behavior and could point me in the right direction for troubleshooting. Thanks, Anthony ___ 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] change the Monitor refresh rate of VM
It's just a number, I don't think we are doing anything with it. miniport/qxl.c: video_mode-Frequency = 100; And we don't do a lot with it later, I think. The real question is what the client refresh rate is, which I don't think we touch. Y. - Original Message - I just want to make sure that is could be changed or not. And, I think 100HZ is too high, normally 75~85HZ is OK for PC, and 60HZ for laptop. 2012/8/16 Michael Tokarev m...@tls.msk.ru 2012/8/15 flooding Controlled flooding2...@gmail.com mailto: flooding2...@gmail.com Hi all: I am now using spice now, but stucked by some problems. My vm is XP, and I can the monitor refresh rate! It is always 100HZ, and it it too high, How can I decrease it ? What problem are you trying to solve by changing the refresh rate? /mjt ___ 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] Mouse failure happens when mouse hovers on some Apps like Kaspersky Anti-virus tool.
- Original Message - Hi Naga, Tested and reproduced it on Win7. I bet you'd see this in any many personal FW / Antivirus, to prevent a malicious software from manipulating it via the mouse (and disable it, for example). I'd try with ZoneAlarm (http://www.zonealarm.com/security/en-us/zonealarm-pc-security-free-firewall.htm#) for example, which I know has such protection. Y. I don't have a patch yet for solving it, but you comment out the line: //ret = _running = false; so vdagent won't exit, although mouse will not be effective on such apps. If it's a must, meanwhile you can always switch back to server mouse mode by stopping vdservice. You can also use usbtablet in case you don't need vdagent functionality (multi mon, cp etc.) I'll update you when I have a patch ready (currently not top priority). Regards, Arnon Naga Mohan Pothula wrote: Hi Arnon, Have you checked installing kaspersky trail version? Here is the eror that causes vdagent.exe to be terminated abruptly. VDAgent::send_input::SendInput failed: 0 VDAgent::run::Agent stopped I've checked integrity level of Kaspersky UI process and it is lesser than VDAgent.exe Thanks/Naga. From: Arnon Gilboa agil...@redhat.comfail due to UIPI blocking To: Naga Mohan Pothula nagamohan.poth...@yahoo.com Cc: spice-devel@lists.freedesktop.org spice-devel@lists.freedesktop.org Sent: Sunday, August 5, 2012 9:54 AM Subject: Re: [Spice-devel] Mouse failure happens when mouse hovers on some Apps like Kaspersky Anti-virus tool. Naga Mohan Pothula wrote: Hi, VDAgent in Windows 7 guest gets terminated when mouse hovers on some applications like Kaspersky Anti-virus tool. Noticed SendInput Windows API fails whenever any mouse operation performs on this tool. handle_mouse_event method returns with failure due to this and causes VDAgent to terminate. what's the error logged in %windir%\temp\vdagent.log? look for SendInput failed: ...) Initially, I thought it is UIPI ie., Process Integrity Level issue and observed as follows: VDService with SYSTEM a/c creates VDAgent with SYTEM a/c Kaspersky tool is service-based app with SYSTEM a/c creates process to handle UI with logged-on user and with 'Medium' Integrity level. Don't understand why SendInput API fails even VDAgent with higher integrity level than Kaspersky tool? Is there any other way to make VDAgent works for all applications installed in windows guest? will give it a look and update you accordingly. Thanks\Naga. ___ 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] Mouse failure happens when mouse hovers on some Apps like Kaspersky Anti-virus tool.
On 08/15/2012 01:05 PM, Arnon Gilboa wrote: Yaniv Kaul wrote: - Original Message - Hi Naga, Tested and reproduced it on Win7. I bet you'd see this in any many personal FW / Antivirus, to prevent a malicious software from manipulating it via the mouse (and disable it, for example). I'd try with ZoneAlarm (http://www.zonealarm.com/security/en-us/zonealarm-pc-security-free-firewall.htm#) for example, which I know has such protection. Y. Seems you are right. So the only option we have is (auto)fallback to server mode / usbtablet for such apps? If you can do it automatically, I guess so. Y. I don't have a patch yet for solving it, but you comment out the line: //ret = _running = false; so vdagent won't exit, although mouse will not be effective on such apps. If it's a must, meanwhile you can always switch back to server mouse mode by stopping vdservice. You can also use usbtablet in case you don't need vdagent functionality (multi mon, cp etc.) I'll update you when I have a patch ready (currently not top priority). Regards, Arnon Naga Mohan Pothula wrote: Hi Arnon, Have you checked installing kaspersky trail version? Here is the eror that causes vdagent.exe to be terminated abruptly. VDAgent::send_input::SendInput failed: 0 VDAgent::run::Agent stopped I've checked integrity level of Kaspersky UI process and it is lesser than VDAgent.exe Thanks/Naga. From: Arnon Gilboa agil...@redhat.comfail due to UIPI blocking To: Naga Mohan Pothula nagamohan.poth...@yahoo.com Cc: spice-devel@lists.freedesktop.org spice-devel@lists.freedesktop.org Sent: Sunday, August 5, 2012 9:54 AM Subject: Re: [Spice-devel] Mouse failure happens when mouse hovers on some Apps like Kaspersky Anti-virus tool. Naga Mohan Pothula wrote: Hi, VDAgent in Windows 7 guest gets terminated when mouse hovers on some applications like Kaspersky Anti-virus tool. Noticed SendInput Windows API fails whenever any mouse operation performs on this tool. handle_mouse_event method returns with failure due to this and causes VDAgent to terminate. what's the error logged in %windir%\temp\vdagent.log? look for SendInput failed: ...) Initially, I thought it is UIPI ie., Process Integrity Level issue and observed as follows: VDService with SYSTEM a/c creates VDAgent with SYTEM a/c Kaspersky tool is service-based app with SYSTEM a/c creates process to handle UI with logged-on user and with 'Medium' Integrity level. Don't understand why SendInput API fails even VDAgent with higher integrity level than Kaspersky tool? Is there any other way to make VDAgent works for all applications installed in windows guest? will give it a look and update you accordingly. Thanks\Naga. ___ 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] Performance of Xspice - some results, and a potential patch
- Original Message - I don't know what were the network conditions you tested, but it would be great if you could repeat your test with lower bandwidth (you can use tc), and also, you can try disabling off-screen surfaces in the driver. I do have a test network constructed for just that purpose, so I can manage and measure all aspects of the network. It was with the latency set to 80 ms that I probed the issue with the ack window size. For the tests I ran, though, I was on an uncrippled network, using all default settings for Xspice. I do not know what form of image compression was in use; only that it would be whatever default would be chosen (I believe the default is auto lz, and my sense is that I was mostly seeing lz and quic images going across the wire, but don't quote me on that). I forgot to ask that you measure CPU consumption on the server: You could have (manually) enable better compression schemes for the images, which would have reduced the total bytes sent. That costs CPU, though. BTW, if you could post a (compressed) capture of your traffic, should be fairly easy to evaluate how many images were sent, how many were cached, and how many other commands were sent. May help focus on the important stuff to optimize, from bandwidth point of view. Y. As far as I recall, disabling surfaces prevented Xspice from working properly, so I did not test that mode. I did not really understand how to analyze the effectiveness of surface caching, so while I saw the ability to gather those statistics, I didn't do that exercise. I haven't tried throttling bandwidth; it's interesting to know that the code may respond to that condition. In the same matter, another improvement we planned is to change the limit for the size of the queue of messages directed to the client: currently it is limited to a constant number of messages. When we reach the limit, we stop reading from the driver command ring. We planned to change it to use a limit based on the estimation of the total size that is pending to be sent to the client. Maybe we should consider limiting it by the time duration from the head to tail. In this manner we can have more control of the refresh rate, and maybe be able to drop more commands than today. That said, if the scenario is composed of commands that don't hide one another, all the above wouldn't help. Right; the worst case scenario I hit was a set of 27,000 draw operations, each one next to the other, none hiding another. What I found as I probed typical use cases for most Linux apps was that solid() calls dominated the use case; with a typical run containing a few thousand 'other' calls, and then 100,000 or more calls to solid(). (Of course, a case I care strongly about, MS Office in Wine, turns out to devolve into a lot of surfaces and copies, so it wasn't strictly true :-/). How are you verifying that the user experience remains the same? That there is no tearing, distortion, missing elements, etc.? That's a good question; I don't have a great answer. It Works For Me (TM) is pretty lame grin. Seriously, we plan to do some QA around this whole stack, so I expect to uncover a few further issues. The test code I posted does include an option to record the user session to a movie file; I plan to use a video diff tool to compare the resulting movie to a capture of a session running purely on an Xvfb server. That will give me a number to use to compare to 'correct'. I hope to use that to quantify the 'quality' of various solutions. Note that this sounds nice on paper; I have yet to actually do this, so it may not work all that well in practice. The session capture software seems to work only so-so, and the diff software costs money that I haven't spent yet. But I would very much appreciate other suggestions on how best to test and verify that the solution is working well. Cheers, Jeremy ___ 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 4/7] spice-ppc: fix glz magic endianess
On 08/08/2012 12:34 PM, Christophe Fergeau wrote: On Wed, Aug 08, 2012 at 05:24:30AM -0400, Yaniv Kaul wrote: - Original Message - On Tue, Aug 07, 2012 at 03:43:11PM -0300, Erlon Cruz wrote: From: Erlon Cruz erlon.c...@br.flextronics.com Signed-off-by: Erlon R. Cruz erlon.c...@br.flextronics.com Signed-off-by: Fabiano Fidêncio Fabiano.Fidên...@fit-tecnologia.org.br Signed-off-by: Rafael F. Santos rafael.san...@fit-tecnologia.org.br --- server/glz_encoder.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/server/glz_encoder.c b/server/glz_encoder.c index 1ec1f9b..f8415a8 100644 --- a/server/glz_encoder.c +++ b/server/glz_encoder.c @@ -261,7 +261,7 @@ int glz_encode(GlzEncoderContext *opaque_encoder, encoder-cur_image.id = dict_image-id; encoder-cur_image.first_win_seg = dict_image-first_seg; -encode_32(encoder, LZ_MAGIC); +encode_32(encoder, htole32(LZ_MAGIC)); The correct thing to do here is drop LZ_MAGIC. No one needs it. And the version stuff that follows it as well. It's useless. It's not useless to old clients as they won't be able to communicate with the server if these fields are not there. I think some people would hate us if we broke that ;) Christophe Of course - this should all have a if you are already touching this field notice/pledge. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/7] spice-ppc: Fixing endianess for channel startup negotiation
- Original Message -
Signed-off-by: Erlon R. Cruz erlon.c...@br.flextronics.com
Signed-off-by: Fabiano Fidêncio
Fabiano.Fidên...@fit-tecnologia.org.br
Signed-off-by: Rafael F. Santos rafael.san...@fit-tecnologia.org.br
---
server/reds.c | 82
-
1 files changed, 69 insertions(+), 13 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index e3ea154..9df6e2d 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -36,6 +36,7 @@
#include errno.h
#include ctype.h
#include stdbool.h
+#include endian.h
#include openssl/bio.h
#include openssl/pem.h
@@ -1216,6 +1217,23 @@ static void
reds_channel_init_auth_caps(RedLinkInfo *link, RedChannel *channel)
red_channel_set_common_cap(channel,
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
}
+#define WORD32_MASK 0x03
+static inline void buf_swap_htole32(void *buf, size_t len){
+
+uint32_t *pos = buf;
+
+if(WORD32_MASKlen){
+printf(error swapping unaligned 32 bits word: len
%d\n,(int)len);
+exit(0);
+}
+
+while(len 0){
+*pos = htole32(*pos);
+pos++;
+len -= 4;
+}
+}
+
static int reds_send_link_ack(RedLinkInfo *link)
{
SpiceLinkHeader header;
@@ -1224,12 +1242,12 @@ static int reds_send_link_ack(RedLinkInfo
*link)
RedChannelCapabilities *channel_caps;
BUF_MEM *bmBuf;
BIO *bio;
-int ret = FALSE;
+int ret = FALSE, *commom_caps = -1, *caps = -1;
header.magic = SPICE_MAGIC;
header.size = sizeof(ack);
-header.major_version = SPICE_VERSION_MAJOR;
-header.minor_version = SPICE_VERSION_MINOR;
+header.major_version = htole32(SPICE_VERSION_MAJOR);
+header.minor_version = htole32(SPICE_VERSION_MINOR);
If you are already touching it, move it to 1 byte each
(http://spice-space.org/page/ProtocolChanges#Protocol_Version_field_.28minor_.26_major.29_should_be_1_byte_sized_each)
Y.
ack.error = SPICE_LINK_ERR_OK;
@@ -1243,10 +1261,12 @@ static int reds_send_link_ack(RedLinkInfo
*link)
reds_channel_init_auth_caps(link, channel); /* make sure common
caps are set */
channel_caps = channel-local_caps;
-ack.num_common_caps = channel_caps-num_common_caps;
-ack.num_channel_caps = channel_caps-num_caps;
-header.size += (ack.num_common_caps + ack.num_channel_caps) *
sizeof(uint32_t);
-ack.caps_offset = sizeof(SpiceLinkReply);
+ack.num_common_caps = htole32(channel_caps-num_common_caps);
+ack.num_channel_caps = htole32(channel_caps-num_caps);
+header.size += (channel_caps-num_common_caps +
channel_caps-num_caps) * sizeof(uint32_t);
+ack.caps_offset = htole32(sizeof(SpiceLinkReply));
+
+header.size = htole32(header.size);
if (!(link-tiTicketing.rsa = RSA_new())) {
spice_warning(RSA nes failed);
@@ -1264,8 +1284,20 @@ static int reds_send_link_ack(RedLinkInfo
*link)
i2d_RSA_PUBKEY_bio(bio, link-tiTicketing.rsa);
BIO_get_mem_ptr(bio, bmBuf);
+
memcpy(ack.pub_key, bmBuf-data, sizeof(ack.pub_key));
+commom_caps = spice_memdup(channel_caps-common_caps,
+channel_caps-num_common_caps *
sizeof(uint32_t));
+buf_swap_htole32(commom_caps,
+channel_caps-num_common_caps *
sizeof(uint32_t));
+
+caps = spice_memdup(channel_caps-caps,
+channel_caps-num_caps * sizeof(uint32_t));
+
+buf_swap_htole32(commom_caps,
+channel_caps-num_caps * sizeof(uint32_t));
+
if (!sync_write(link-stream, header, sizeof(header)))
goto end;
if (!sync_write(link-stream, ack, sizeof(ack)))
@@ -1275,6 +1307,9 @@ static int reds_send_link_ack(RedLinkInfo
*link)
if (!sync_write(link-stream, channel_caps-caps,
channel_caps-num_caps * sizeof(uint32_t)))
goto end;
+free(commom_caps);
+free(caps);
+
ret = TRUE;
end:
@@ -1288,11 +1323,12 @@ static int reds_send_link_error(RedLinkInfo
*link, uint32_t error)
SpiceLinkReply reply;
header.magic = SPICE_MAGIC;
-header.size = sizeof(reply);
-header.major_version = SPICE_VERSION_MAJOR;
-header.minor_version = SPICE_VERSION_MINOR;
+header.size = htole32(sizeof(reply));
+header.major_version = htole32(SPICE_VERSION_MAJOR);
+header.minor_version = htole32(SPICE_VERSION_MINOR);
memset(reply, 0, sizeof(reply));
-reply.error = error;
+reply.error = htole32(error);
+
return sync_write(link-stream, header, sizeof(header))
sync_write(link-stream, reply,
sizeof(reply));
}
@@ -1315,7 +1351,9 @@ static void reds_info_new_channel(RedLinkInfo
*link, int connection_id)
static void reds_send_link_result(RedLinkInfo *link, uint32_t error)
{
-sync_write(link-stream, error, sizeof(error));
+
Re: [Spice-devel] [PATCH 4/7] spice-ppc: fix glz magic endianess
- Original Message - On Tue, Aug 07, 2012 at 03:43:11PM -0300, Erlon Cruz wrote: From: Erlon Cruz erlon.c...@br.flextronics.com Signed-off-by: Erlon R. Cruz erlon.c...@br.flextronics.com Signed-off-by: Fabiano Fidêncio Fabiano.Fidên...@fit-tecnologia.org.br Signed-off-by: Rafael F. Santos rafael.san...@fit-tecnologia.org.br --- server/glz_encoder.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/server/glz_encoder.c b/server/glz_encoder.c index 1ec1f9b..f8415a8 100644 --- a/server/glz_encoder.c +++ b/server/glz_encoder.c @@ -261,7 +261,7 @@ int glz_encode(GlzEncoderContext *opaque_encoder, encoder-cur_image.id = dict_image-id; encoder-cur_image.first_win_seg = dict_image-first_seg; -encode_32(encoder, LZ_MAGIC); +encode_32(encoder, htole32(LZ_MAGIC)); The correct thing to do here is drop LZ_MAGIC. No one needs it. And the version stuff that follows it as well. It's useless. if you insist on keeping them, change to 1 byte each and then there's one less endianity issue (http://spice-space.org/page/ProtocolChanges#QUIC_and_GLZ_RGB_version_numbers_should_use_1_byte_per_number) Y. LZ_MAGIC really should be a string that we encode using something like encode_array(encoder, LZ_MAGIC, sizeof(LZ_MAGIC)), but we don't have such facilities in glz_encoder.c, so why not. Have you tested that a ppc encoded glz stream can be decoded on an x86 client? (thinking of it, it might be the only setup you have tested for now). Christophe ___ 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] Performance of Xspice - some results, and a potential patch
- Original Message - I've spent several weeks analyzing the network performance of Xspice against two test cases. I also crafted a patch which implements an alternate mode for the xf86-video-qxl driver that dramatically improves network performance. The two test cases are simple [1]; a script drives either Libre Office or Microsoft Office 2007. They have a few minutes of typing, a bit of graphics (the test case draws a smiley face), and a little bit of interaction with the UI. How are you verifying that the user experience remains the same? That there is no tearing, distortion, missing elements, etc.? For now, I'm focused on measuring network performance; I plan to later do some analysis to try to get at the quality of the user experience as well. Network performance, particularly the total # of packets, has a dramatic effect on Spice performance over a remote network. Indeed - but also take into consideration the number of messages (luckily, some of them are aggregated by TCP). You can use the dissector in Wireshark to see (and count) the number of Spice messages (or add counters in the server, of course). For a test involving 5 minutes of light use of LibreOffice, the results are as follows: Packets Bytes Xspice148,428 19,647,168 Tight VNC 19,980 4,724,880 SSH -X 48,894 77,733,200 SSH -CX21,445 5,096,702 You can see that Xspice network performance is pretty bad. This is partly by design; Spice is designed to replicate the philosophy of the X server, wherein graphics operations themselves - not pixmaps - are transmitted across the wire. Which image compression is being utilized? Is the caching effective? Further, Spice as a whole is really built around qemu and Windows qxl running on a local LAN; Xspice is really just an experimental feature, and I'm pretty much the first person to examine it's network flow. However, if I modify the xf86-video-qxl driver to shift modes into a render and send mode, whereby only changed pixmaps are sent across the wire (and that on a periodic basis), I get dramatically better results. That patch is attached; these are the results: Xspice + deferred_fps 14,910 2,971,886 As you can see, with that change, Spice vaults into the lead. Again - any difference in user experience? Y. The numbers for Office 2007 are somewhat similar, although ssh -CX does not fare nearly as well. (The underlying behaviors are quite different; Office 2007 is surface + render heavy; Libre Office is fill region heavy). Additionally, I spent a lot of energy trying to decide if this mode could be injected into the Spice server itself, where it could potentially benefit the whole stack. I'm grateful to Alon and Soren for helping me privately with that effort. However, in the end, I could not see a path to do this with the kind of tight efficiency that I think is required. I had a test case where an ill behaved X application (fluxbox) would do 27,000 pixel draws; and I just couldn't find a way to run those draws through the Spice server efficiently. My old nemesis, red_worker.c, defeats me again :-/. I also spent some energy experimenting with modes where we kicked the spice server into a video streaming mode. I had only limited success with that. But I did do some analysis that shows that the test case (Libre Office) requires about 3,000,000 bytes to stream a high quality Theora video. Given that the deferred_fps patch matches that, and it is much lighter on the CPU, I've decided to not pursue that approach for now. At any rate, I would appreciate any comments or feedback on the basic approach outlined by the patch. Cheers, Jeremy [1] The tests are repeatable, automated scripts, and can be found here: git://people.freedesktop.org/~jwhite/spice-measure They are not at all user friendly or easy to parse, I'm afraid. They rely on some crude mechanisms (e.g. I have a dedicated machine, and I measure bandwidth by sampling ifconfig results before + after). You can try it by having the gtk spice client connected to an 800x600 system with a minimal window manager, with LibreOffice maximized. Then try running make ./limeasure spice display 0 and don't blame me if it destroys your system grin. ___ 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] Failure to compile spice-gtk : desktop-integration.c:175:30: error: unused variable 'self'
Git hash 2157ea0bf87989ccc29814aece3fa7f434f25840: CC spice-widget-enums.lo desktop-integration.c: In function 'spice_desktop_integration_dispose': desktop-integration.c:175:30: error: unused variable 'self' [-Werror=unused-variable] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] xf86-video-qxl performance
- Original Message - I am going to dive into the xf86 driver performance in a serious way starting next week. This is great news - good luck! I'm planning on building instrumentation to let me build sample data sets. I want to see what sort of X operations result from a typical work load, and how the pipes fill up, so I can start to try to find patterns where optimization would be appropriate. I have looked at Alon's initial patch set, thanks; I think I still need to understand the code more deeply before I can truly grok it. Are there any other tools I should be aware of, or inbound patch sets that would change things significantly? I suspect different workloads would produce different 'hotspots' to be handled. (for example, video streaming, vs. Internet browsing, vs. office workload). Make sure you have a decent mix (unless you plan to concentrate on a specific use case). Y. Cheers, Jeremy ___ 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] Add support for A8 bitmap format
On 06/17/2012 12:03 PM, Alon Levy wrote: On Sat, Jun 16, 2012 at 01:57:49AM -0400, Yaniv Kaul wrote: - Original Message - Hello, The following patches add support for a new A8 bitmap format, and for LZ compression of it. This format is heavliy used by the X server Render extension for glyphs and geometry information. I have verified that the patches with an experiemental version of the QXL X driver that can generate such pixmaps in the video memory of the QXL device. Thanks, Soren - I'm not sure I understand how'll it work with older clients (need feature negotiation, but from guest driver to server and from server to client?). The driver would have to follow whatever the client that is connected to it can work with? I guess we need to solve the general problem of how a new feature in the driver that affects the client should be handled, this is a private case of it. Y. Perhaps this is really required in this case. We could do something like the following: Device memory: add client_capabilities == SPICE_DISPALY_CAP_* Device added INTERRUPT_CLIENT_CAPS_UPDATED Server QXLInterface-update_client_capabilities Server Client SPICE_DISPLAY_CAP_A8 Only problem with this approach is that the driver doesn't have an interrupt handler, and it won't until we move to KMS. Heavy handed alternative: - Filter the messages in the server and translate any A8 message to ?? I'm in favor of this one. However, I also forgot about the following scenario: Running old spice server, old QXL driver in VM on host A VM migrates to host B, which has a new spice server, supporting A8. User updates driver to get A8 functionality. VM migrates back to host A (reminder: has old server that is not aware of A8). Not sure what happens now. Y. - Don't allow clients to connect without CAP_A8 if server advertises it, advertise it iff some magic qemu command line, i.e. -device qxl,use_a8=1 . Driver will see the same parameter. I guess I'm advocating the last option - for older client support we run without use_a8=1, also for windows guests. For better performing new xf86 driver we use use_a8=1 and require new clients as a result. ___ 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] Add support for A8 bitmap format
- Original Message - Hello, The following patches add support for a new A8 bitmap format, and for LZ compression of it. This format is heavliy used by the X server Render extension for glyphs and geometry information. I have verified that the patches with an experiemental version of the QXL X driver that can generate such pixmaps in the video memory of the QXL device. Thanks, Soren - I'm not sure I understand how'll it work with older clients (need feature negotiation, but from guest driver to server and from server to client?). The driver would have to follow whatever the client that is connected to it can work with? I guess we need to solve the general problem of how a new feature in the driver that affects the client should be handled, this is a private case of it. Y. ___ 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] Failure to compile: error: 'SpiceUsbDeviceManagerPrivate' has no member named 'auto_conn_filter_rules'
F17/x64, git hash faa2599188a91102945e607e765e3caf0ba1071d: make[4]: Entering directory `/home/ykaul/spice-gtk/gtk' CC decode-glz.lo CC usb-device-manager.lo usb-device-manager.c: In function 'spice_usb_device_manager_finalize': usb-device-manager.c:239:14: error: 'SpiceUsbDeviceManagerPrivate' has no member named 'auto_conn_filter_rules' Any ideas? TIA, Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Announcing the first version of spice-html5
- Original Message - *blush* Yes, sorry, the keyboard code is truly awful. It's a matter of translating web key codes into scan codes; I didn't find a good way to do it, and just used a brute force hack. If you're at all a programmer, it would be easy to extend the hack and fix the key codes for yourself; that code is in utils.js. No escape to get the scancode from the browser? have to wait for html6? None that I found (which is not necessarily !== none grin). All I could find were faqs that said key codes in general are a mess and not standardized (they apparently vary by browser), and certainly nothing to go from key codes to scan codes. I agree - and this is why I did not implement the translation in the Wireshark dissector for the protocol. If you do find something sane, I'll try and adopt it too. Y. My thought was to later explore some of the third party libraries that try to mitigate these issues, and see if riffing off one of those leads to a slightly less ugly solution. There are also some tricky issues around keyboard handling I didn't even begin to think about (e.g. tab, escape, alt-tab, and so on). Cheers, Jeremy ___ 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] Announcing the first version of spice-html5
- Original Message - I am happy to announce that Alon has committed my initial version of the spice html5 client. Wow. Bravo! It has many limitations and it requires a modern browser (up to date Firefox or Chrome). However, it certainly makes an interesting proof of concept, and I am hopeful that over time it will become a valuable alternate client for Spice. You can learn more about it (and try it) by reading further here: http://www.spice-space.org/page/Html5 The source code is available here: http://cgit.freedesktop.org/spice/spice-html5 Do you think the auto-generated code should be kept in the repo, or be generated upon 'make' ? (of course, it'd require emscripten to build it). Y. Cheers, Jeremy ___ 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] xf86-video-qxl performance
- Original Message - I need to improve the performance of the xf86-video-qxl driver; aka xspice; by a fairly substantial margin. What performance characteristic would you like to improve? 1. Performance over WAN (high latency and/or low bandwidth) ? 2. CPU usage (on the server and/or the client and/or the guest) ? 3. Other? I suggest trying to figure out what is it that you wish to 'attack' first. Some of the decisions taken during the development of Spice certainly did not take into account WAN conditions, for example. It was initially mostly concerned with providing physical-like experience, on decent servers and clients over LAN. I've set up a test case - LibreOffice over an 80 ms latency connection - that demonstrates that it's got quite a long way to go. (The current case appears to suffer from an excessive set of draw fill operations). Sounds familiar - I've seen it in a case where I expected to see a video stream sent instead. Not sure what is more efficient, though. Y. Has any work been done on the 'Current plan' listed in the TODO? Can I help in any way? Also, as a crazy idea, has anyone considered implementing a pure streaming video driver? That is, what if we had a frame buffer driver, and then a thread that fired 29 times a second to drive a theora or vp8 encoder, simply feeding the current frame at those intervals. The advantage to that crazy proposal is that it would likely make the pure html5 client work 'perfectly'. The obvious disadvantage is that it would consume a lot more cpu resources on the host, although it's not clear to me how substantial that would be. Thoughts? Cheers, Jeremy ___ 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] Minor fix to the SpiceClip/type field
- Original Message - This patch should make it reflect the on wire size. This one cost me an hour and some hair; hopefully it'll save someone else in the future. I suggest taking a look at the Wireshark Spice dissector, which is more aligned with the wire format than the Spice code (and certainly its documentation) is, surprisingly. Y. Cheers, Jeremy ___ 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] Client Graphics Filtering
On 04/25/2012 10:41 AM, Yonit Halperin wrote: On 04/25/2012 08:32 AM, Noel Van Hook wrote: If I recall my windows drivers correctly, I don't think the driver even knows what application owns the buffer it is drawing into. IIUC, the implementation involves guest components that track down the relevant bitmaps. Yonit. The RDP implementation for it is available (open source) @ http://www.cendio.com/seamlessrdp/ Y. Noel On Tue, Apr 24, 2012 at 11:43 AM, Yonit Halperinyhalp...@redhat.com wrote: Hi, On 04/24/2012 09:12 AM, Alon Levy wrote: On Tue, Apr 24, 2012 at 09:47:47AM +0800, 蒋媛园 wrote: Hi I want to filter the graphics to the client. For example, only the graphics of a calculator(in guest OS Win7) are send to the client. I know that there is always the possibility of falling all the way back to CPU drawing to a memory bitmap which is then copied to the client. Now, I have filtered the drawing commands on device-managed surfaces which belong to some app.exe. However I don't know how to control the engine-managed surfaces, namely those pre-rendered bitmaps. I didn't find related code in QXL driver. Could you please give me some advice? I really need some help. I'm not sure I understand exactly what you mean. I guess that by engine-managed, you mean gdi bitmaps? When the destination of a drawing operation is a gdi bitmap, the client doesn't know about this operation. The driver renders the src* of the operation if needed (if it is a device managed bitmap), copies the relevant src area to a new gdi bitmap, and fallback to a Gdi call, with the copied src and original dest. If the destination is a device managed bitmap, and the src* is a gdi managed bitmap, the gdi bitmap is copied to the device memory, and the corresponding qxl drawing command is sent to the server together with the reference to the copied bitmap. * There can be multiple references to bitmaps in one qxl command (src/mask/brush), and each one can be a bitmap (gdi/device) Regards, Yonit. Great to hear someone is working on this, I don't have an answer though, Yonit, any idea maybe? Thanks in advance Best Regards! 网易Lofter，专注兴趣，分享创作！ ___ 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] Change xorg-macros - xorg-x11-util-macros in configure error message
On 04/24/2012 07:30 PM, Christophe Fergeau wrote: On Tue, Apr 24, 2012 at 02:28:42PM +0300, Alon Levy wrote: On Tue, Apr 24, 2012 at 01:22:41PM +0300, Yaniv Kaul wrote: At least in Fedora 17, the correct RPM name is xorg-x11-util-macros We could use the upstream name too, xorg-util-macros (kinda): http://cgit.freedesktop.org/xorg/util/macros/tree/configure.ac#n25 But this is better anyway. ACK. How does that help on a Debian or openSUSE system? Christophe It does not harm them in any way, AFAIK - I could not find similar named packages in either. So better get the name right on one distribution than none. Y. diff --git a/configure.ac b/configure.ac index cb874f7..a97f477 100644 --- a/configure.ac +++ b/configure.ac @@ -36,7 +36,7 @@ AC_CONFIG_HEADERS([config.h]) # Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) + [m4_fatal([must install xorg-x11-util-macros 1.4 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.4) XORG_DEFAULT_OPTIONS ___ 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
[Spice-devel] [PATCH] Change xorg-macros - xorg-x11-util-macros in configure error message
At least in Fedora 17, the correct RPM name is xorg-x11-util-macros diff --git a/configure.ac b/configure.ac index cb874f7..a97f477 100644 --- a/configure.ac +++ b/configure.ac @@ -36,7 +36,7 @@ AC_CONFIG_HEADERS([config.h]) # Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) + [m4_fatal([must install xorg-x11-util-macros 1.4 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.4) XORG_DEFAULT_OPTIONS ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Change xorg-macros - xorg-x11-util-macros in configure error message
That's for xf86-video-qxl . Y. On 04/24/2012 01:22 PM, Yaniv Kaul wrote: At least in Fedora 17, the correct RPM name is xorg-x11-util-macros diff --git a/configure.ac b/configure.ac index cb874f7..a97f477 100644 --- a/configure.ac +++ b/configure.ac @@ -36,7 +36,7 @@ AC_CONFIG_HEADERS([config.h]) # Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) + [m4_fatal([must install xorg-x11-util-macros 1.4 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.4) XORG_DEFAULT_OPTIONS ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failing to compile spice-gtk: ../common/client_marshallers.h:27:24: fatal error: marshaller.h: No such file or directory
On 04/01/2012 10:41 PM, Marc-André Lureau wrote: Hi - Mensaje original - Indeed - that was the problem - thank you. I don't know how it was not removed during 'git pull'. (and already found a spice-gtk bug - the 'shift+F12' combination seems to work only as 'left-shift+F12', not 'right-shift+F12'). Because that's how it is binded: seq = spice_grab_sequence_new_from_string(Shift_L+F12); OK, so the text at the bottom is wrong. It just says 'shift'. Btw, spicy is not a client we are focusing on, but rather virt-viewer/remote-viewer. Good to know - I'll get its source and try it out. Thanks, Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Failing to compile spice-gtk: ../common/client_marshallers.h:27:24: fatal error: marshaller.h: No such file or directory
This time, even 'git clean -dfx' didn't save me. And 'make clean' does not seem to work. Tried also ./autogen.sh and ./configure, but no luck: make[4]: Entering directory `/home/ykaul/spice-gtk/gtk' CC bio-gsocket.lo CC glib-compat.lo CC spice-audio.lo In file included from spice-channel-priv.h:36:0, from spice-audio.c:44: ../common/client_marshallers.h:27:24: fatal error: marshaller.h: No such file or directory compilation terminated. make[4]: *** [spice-audio.lo] Error 1 configure: Spice-Gtk 0.11.49-9f7c-dirty == prefix: /usr/local c compiler: gcc -std=gnu99 Coroutine:ucontext Audio:pulse Target: Unix SASL support: yes Smartcard support:yes USB redirection support: no Gtk: 3.0 Now type 'make' to build spice-gtk ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Users] Really need serious help with spice (its just not working !!) - attached ~/.spicec/spicec.log
On 03/21/2012 05:52 PM, David Jaša wrote: Hi, Itamar Heim píše v St 21. 03. 2012 v 17:28 +0200: cc'ing spice-devel On 03/20/2012 07:01 PM, Morgan Cox wrote: Hi. My Setup - 3 servers 1 Frontend (ovirt engine) - Fedora 16- external + local IP 1 Ovirt node (using the node .iso) - external + local IP 1 NFS storage - external + local IP - I attached the storage using the Local IP (10.0.0.190) I have launched firefox with - SPICEC_LOG_LEVEL=0 firefox I create a VM, turn it on - click the spice console button - it crashes I can see Warning: failed to connect: Connection refused (111) ~/.spicec/spicec.log ( I have removed the IP / domain name) - 1332262683 INFO [5895:5895] Application::main: starting 0.10.0 1332262683 DEBUG [5895:5895] Application::Application: 1332262683 DEBUG [5895:5895] HotKeysParser::HotKeysParser: hotkeys = toggle-fullscreen=shift+f11,release-cursor=shift+f12 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = f11 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = f12 1332262683 DEBUG [5895:5895] Platform::init: 1332262683 INFO [5895:5895] init_key_map: using evdev mapping 1332262683 INFO [5895:5895] MultyMonScreen::MultyMonScreen: platform_win: 104857601 1332262683 INFO [5895:5895] ForeignMenu::ForeignMenu: Creating a foreign menu connection /tmp/SpiceForeignMenu-5895.uds 1332262683 DEBUG [5895:5895] LinuxListener::LinuxListener: listening socket - /tmp/SpiceForeignMenu-5895.uds, added to events_loop 1332262683 INFO [5895:5895] Controller::Controller: Creating a controller connection /tmp/spicec-y6x224/spice-xpi 1332262683 DEBUG [5895:5895] LinuxListener::LinuxListener: listening socket - /tmp/spicec-y6x224/spice-xpi, added to events_loop 1332262684 DEBUG [5895:5895] LinuxListener::on_event: New connection created, fd: 22 1332262686 DEBUG [5895:5895] Application::set_host_cert_subject: subject entry: O=frontend.ovirt.domain.co.ukhttp://frontend.ovirt.domain.co.uk 1332262686 DEBUG [5895:5895] Application::set_host_cert_subject: subject entry: CN=91.***.***.*** 1332262686 DEBUG [5895:5895] HotKeysParser::HotKeysParser: hotkeys = release-cursor=shift+f12,toggle-fullscreen=shift+f11 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = f12 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = f11 1332262686 DEBUG [5895:5896] RedPeer::connect_to_peer: Trying 91.***.***.***.*** 65535 ^^^ this looks suspicious. It seems like no port is passed to the client from User Portal and spice-xpi subsequently tries 65535. David 1332262686 INFO [5895:5896] RedPeer::connect_to_peer: Connect failed: Connection refused (111) But then why would the connection be REFUSED? You should get (AFAIR), timeout (110). I suggest getting the VM's QEMU logs as well. Y. 1332262686 WARN [5895:5896] RedChannel::run: failed to connect: Connection refused (111) 1332262686 INFO [5895:5895] main: Spice client terminated (exitcode = 3) 1332262686 DEBUG [5895:5895] cleanup: - The IP it seems to be trying is the external IP of the Ovirt node... ~/.spicec/spice-xpi.log shows - 2012-03-20 16:58:03,134 ERROR nsPluginInstance::Connect: ERROR failed to run spice-xpi-client 2012-03-20 16:58:06,260 ERROR nsPluginInstance::CallOnDisconnected: OnDisconnected is not object - Any ideas ? Also is there any way of adding a ovirt node via host name rather than IP - I can't seem to using the ovirt node / ovirt engine. Any help will be welcomed Regards ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ 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] spice-gtk core dump
Using spice-gtk b9b658f6ea41a2473853149b41fef2cb808ec4f2 spice 914e50814f151a9a5680018e2f264fd900885af9 qemu 33cf629a3754b58a1e2dbbe01d91d97e712b7c06 [ykaul@ykaul spice-gtk]$ gtk/spicy [1] 29428 [ykaul@ykaul spice-gtk]$ GSpice-Message: main channel: failed to connect GSpice-Message: main channel: opened *** buffer overflow detected ***: /home/ykaul/spice-gtk/gtk/.libs/lt-spicy terminated === Backtrace: = /lib64/libc.so.6(__fortify_fail+0x37)[0x3016308af7] /lib64/libc.so.6[0x3016306a70] /home/ykaul/spice-gtk/gtk/.libs/libspice-client-glib-2.0.so.1(+0xcc565)[0x7fab05146565] /home/ykaul/spice-gtk/gtk/.libs/libspice-client-glib-2.0.so.1(+0x194ac)[0x7fab050934ac] /home/ykaul/spice-gtk/gtk/.libs/libspice-client-glib-2.0.so.1(+0x1a3a9)[0x7fab050943a9] /home/ykaul/spice-gtk/gtk/.libs/libspice-client-glib-2.0.so.1(+0x176b4)[0x7fab050916b4] /home/ykaul/spice-gtk/gtk/.libs/libspice-client-glib-2.0.so.1(+0xc6d1f)[0x7fab05140d1f] /home/ykaul/spice-gtk/gtk/.libs/libspice-client-glib-2.0.so.1(+0xc6ab6)[0x7fab05140ab6] /lib64/libc.so.6[0x30162470d0] Running with gdb: (gdb) bt #0 0x003016236285 in raise () from /lib64/libc.so.6 #1 0x003016237b9b in abort () from /lib64/libc.so.6 #2 0x003016277a7e in __libc_message () from /lib64/libc.so.6 #3 0x003016308af7 in __fortify_fail () from /lib64/libc.so.6 #4 0x003016306a70 in __chk_fail () from /lib64/libc.so.6 #5 0x7fc24a3b4565 in memcpy (__len=9, __src=optimized out, __dest=0x1dfd6a4) at /usr/include/bits/string3.h:52 #6 parse_msg_main_name (message_start=optimized out, message_end=0x1dbbe7d , minor=optimized out, size=0x1e68500, free_message=0x1e68508) at generated_demarshallers.c:1155 #7 0x7fc24a3014ac in spice_channel_recv_msg (channel=0x1e32860, msg_handler=0x7fc24a30f850 spice_main_handle_msg, data=0x0) at spice-channel.c:1827 #8 0x7fc24a3023a9 in spice_channel_iterate_read (channel=0x1e32860) at spice-channel.c:2000 #9 spice_channel_iterate_read (channel=0x1e32860) at spice-channel.c:1984 #10 0x7fc24a2ff6b4 in spice_channel_iterate (channel=0x1e32860) at spice-channel.c:2058 #11 spice_channel_coroutine (data=0x1e32860) at spice-channel.c:2211 #12 0x7fc24a3aed1f in coroutine_trampoline (cc=0x1e32918) at coroutine_ucontext.c:56 #13 0x7fc24a3aeab6 in continuation_trampoline (i0=optimized out, i1=optimized out) at continuation.c:49 #14 0x0030162470d0 in ?? () from /lib64/libc.so.6 trace hints it's the name that is being sent - the name (from wireshark capture) seems like len = 9 (uint32) name = TinyCore\0 (ASCII?!) qemu command line:./x86_64-softmmu/qemu-system-x86_64 -spice port=6901,disable-ticketing,jpeg-wan-compression=always,zlib-glz-wan-compression=always,playback-compression=on -k en-us -name Tinycore -boot d -drive file=~/tc.qcow2,if=ide,cache=writethrough,media=disk,format=qcow2 -drive file=~/Downloads/TinyCore-current.iso,if=ide,media=cdrom -soundhw pcspk -m 1024 -cpu core2duo,+x2apic -smp 2 -balloon none -bios /usr/share/seabios/bios.bin -monitor stdio --parallel none -vga qxl Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Failing to compile spice-gtk: generated_marshallers1.c:2:25: fatal error: marshallers.h: No such file or directory
Yesterday's issue was fixed (with commit 837b98d043d10b1d6360d8e1079f88606b37ac84 , I think), but I'm still failing: CC generated_marshallers1.lo generated_marshallers1.c:2:25: fatal error: marshallers.h: No such file or directory compilation terminated. configure: Spice-Gtk 0.11.33-82a4 == prefix: /usr/local c compiler: gcc -std=gnu99 Coroutine:ucontext Audio:pulse Target: Unix SASL support: yes Smartcard support:yes USB redirection support: no Gtk: 3.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failing to compile spice-gtk: generated_marshallers1.c:2:25: fatal error: marshallers.h: No such file or directory
On 03/19/2012 12:01 PM, Marc-André Lureau wrote: Hi The generated files need to be regenerated. I guess they should have build depedency on Makefile somehow.. anyway, as in countless times with build issues: git clean -dfx should get you out of trouble. It's only project I work on with which I'm having such issues with each time. I thought 'make clean ; ./autogen.sh' would have solved it. Alas, it didn't. I was not aware of 'git clean' - that worked - thanks! Y. On Mon, Mar 19, 2012 at 9:10 AM, Yaniv Kaulyk...@redhat.com wrote: Yesterday's issue was fixed (with commit 837b98d043d10b1d6360d8e1079f88606b37ac84 , I think), but I'm still failing: CC generated_marshallers1.lo generated_marshallers1.c:2:25: fatal error: marshallers.h: No such file or directory compilation terminated. configure: Spice-Gtk 0.11.33-82a4 == prefix: /usr/local c compiler: gcc -std=gnu99 Coroutine:ucontext Audio:pulse Target: Unix SASL support: yes Smartcard support:yes USB redirection support: no Gtk: 3.0 ___ 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] Failure to compile latest spice-gtk: spice-channel-priv.h:103:33: error: field 'xmit_queue_lock' has incomplete type
CC spice-audio.lo In file included from spice-audio.c:44:0: spice-channel-priv.h:103:33: error: field 'xmit_queue_lock' has incomplete type make[2]: *** [spice-audio.lo] Error 1 F16/x64, after ./autogen.sh and 'make clean'. Output of ./configure: Spice-Gtk 0.11.26-e8c9 == prefix: /usr/local c compiler: gcc -std=gnu99 Coroutine:ucontext Audio:pulse Target: Unix SASL support: yes Smartcard support:yes USB redirection support: no Gtk: 3.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/2] Add log for invalid/expired tickets
On 03/02/2012 05:52 PM, Christophe Fergeau wrote:
Currently, when a ticket has already expired, or is invalid, there is
no qemu log to tell what went wrong. This commit adds such a log.
Fixes rhbz#787669
How 'heavy' is this red_printf? Can this cause DoS (if there's no print
limiting to it) ?
Y.
---
server/reds.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 797d9d5..3a98456 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1860,6 +1860,11 @@ static void reds_handle_ticket(void *opaque)
}
if (expired || strncmp(password, taTicket.password,
SPICE_MAX_PASSWORD_LENGTH) != 0) {
+if (expired) {
+red_printf(Ticket has expired);
+} else {
+red_printf(Invalid password);
+}
reds_send_link_result(link, SPICE_LINK_ERR_PERMISSION_DENIED);
reds_link_free(link);
return;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: remove Adler checksum and zlib header/trailer from zlib compressed images
On 02/26/2012 01:46 PM, Yonit Halperin wrote:
On 02/23/2012 08:46 PM, Yaniv Kaul wrote:
On 02/06/2012 09:43 AM, Yonit Halperin wrote:
On 02/06/2012 09:02 AM, Yaniv Kaul wrote:
On 01/29/2012 11:29 AM, Alon Levy wrote:
On Sun, Jan 29, 2012 at 09:28:34AM +0200, Yaniv Kaul wrote:
These small changes to server and (gtk) client seem to work, and
remove both the zlib header/trailer from the deflate stream as well
as the Adler checksum, which removes several bytes from the stream
as well as speedup (unnoticeable) of the compression/decompression
due to the removal of the checksum calculation.
Problem is - not sure how to test it - don't know how to get an
image once with and once without the patch - and ensure it's the
same image.
The fact that the first image is never zlib compressed complicates
things. I could not reliably get a 2nd image sent to the client
which looks the same as one in a different connection.
Nevertheless it does no harm - and images pass well - verified by
connecting with a modified Spice GTK client to a modified Spice
server, as well as looking at the network capture via wireshark.
It's of course missing the display channel specific capability
negotiation for this change.
I'm afraid I could not really find where to perform the display
channel
specific capability negotiation. :(
Anyone?
Hi,
red_dispatcher.c/red_dispatcher_set_display_peer receives the client's
caps.
They should be sent to red_worker.c/handle_dev_display_connect (need
to change RedWorkerMessageDisplayConnect payload to contain them).
caps are tested via red_channel_client_test_remote_cap.
The negotiation should be in red_worker.c/handle_new_display_channel.
The display channel server caps should be set in
red_worker.c/display_channel_create via red_channel.set_cap.
Cheers,
Yonit.
1. Client: I could not find how to do it in spice-gtk. I assume it's in
gtk/channel-display.c , under spice_display_channel_init(), and I assume
via spice_channel_set_capability(), but I could not get a hold of a
SpiceChannel object to pass to that function. ?
You should use the macro SPIC
spice_channel_set_capability(SPICE_CHANNEL(channel), cap)
You can see an example in spice_main_channel_init
Exactly what I've tried to do, but couldn't get SPICE_CHANNEL() the
right parameter. Probably overlooked something.
2. Server: looks like zlib is init'ed via red_worker.c/red_init_zlib(),
which is called from red_worker.c/red_worker_main() , so anything after
that is a bit too late. Unless I re-init zlib (which looks like a light
operation) on ever connect.
The zlib encoder can be moved from the worker to display channel
client. With multi clients, different clients may have different caps.
Btw, for now we encode each message for each client, instead of
reusing the already encoded msg. We plan to change this, and than the
encoder will be moved to groups of channel client that share the same
encoders.
The initialization and release of the encoder can be in the
connect/disconnect of the display channel client (
handle_new_display_channel/display_channel_client_on_disconnect).
When a client disconnects, I assume the cache is cleaned, no? What
happens with multiple clients?
Y.
Thanks,
Y.
TIA,
Y.
Comments are welcome.
Other then that adding a link to the docs page of
inlateInit2/deflateInit2 in the commit message would be nice for
those
seeking to find the explanation for the magic numbers, no comment,
thanks for doing this!
If you want a repeatable test you can write one or use one of the
existing artificial tests in server/tests.
Client change:
diff --git a/gtk/decode-zlib.c b/gtk/decode-zlib.c
index a692020..997f350 100644
--- a/gtk/decode-zlib.c
+++ b/gtk/decode-zlib.c
@@ -63,7 +63,7 @@ SpiceZlibDecoder *zlib_decoder_new(void)
d-_z_strm.opaque = Z_NULL;
d-_z_strm.next_in = Z_NULL;
d-_z_strm.avail_in = 0;
- z_ret = inflateInit(d-_z_strm);
+ z_ret = inflateInit2(d-_z_strm, -15);
if (z_ret != Z_OK) {
g_warning(zlib decoder init failed, error %d, z_ret);
goto fail;
server change:
diff --git a/server/zlib_encoder.c b/server/zlib_encoder.c
index c51466b..66a039a 100644
--- a/server/zlib_encoder.c
+++ b/server/zlib_encoder.c
@@ -47,7 +47,7 @@ ZlibEncoder*
zlib_encoder_create(ZlibEncoderUsrContext *usr, int level)
enc-strm.zfree = Z_NULL;
enc-strm.opaque = Z_NULL;
- z_ret = deflateInit(enc-strm, level);
+ z_ret = deflateInit2(enc-strm, level, Z_DEFLATED, -15, 8,
Z_DEFAULT_STRATEGY);
enc-last_level = level;
if (z_ret != Z_OK) {
red_printf(zlib error);
___
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
Re: [Spice-devel] RFC: remove Adler checksum and zlib header/trailer from zlib compressed images
On 02/06/2012 09:43 AM, Yonit Halperin wrote:
On 02/06/2012 09:02 AM, Yaniv Kaul wrote:
On 01/29/2012 11:29 AM, Alon Levy wrote:
On Sun, Jan 29, 2012 at 09:28:34AM +0200, Yaniv Kaul wrote:
These small changes to server and (gtk) client seem to work, and
remove both the zlib header/trailer from the deflate stream as well
as the Adler checksum, which removes several bytes from the stream
as well as speedup (unnoticeable) of the compression/decompression
due to the removal of the checksum calculation.
Problem is - not sure how to test it - don't know how to get an
image once with and once without the patch - and ensure it's the
same image.
The fact that the first image is never zlib compressed complicates
things. I could not reliably get a 2nd image sent to the client
which looks the same as one in a different connection.
Nevertheless it does no harm - and images pass well - verified by
connecting with a modified Spice GTK client to a modified Spice
server, as well as looking at the network capture via wireshark.
It's of course missing the display channel specific capability
negotiation for this change.
I'm afraid I could not really find where to perform the display channel
specific capability negotiation. :(
Anyone?
Hi,
red_dispatcher.c/red_dispatcher_set_display_peer receives the client's
caps.
They should be sent to red_worker.c/handle_dev_display_connect (need
to change RedWorkerMessageDisplayConnect payload to contain them).
caps are tested via red_channel_client_test_remote_cap.
The negotiation should be in red_worker.c/handle_new_display_channel.
The display channel server caps should be set in
red_worker.c/display_channel_create via red_channel.set_cap.
Cheers,
Yonit.
1. Client: I could not find how to do it in spice-gtk. I assume it's in
gtk/channel-display.c , under spice_display_channel_init(), and I assume
via spice_channel_set_capability(), but I could not get a hold of a
SpiceChannel object to pass to that function. ?
2. Server: looks like zlib is init'ed via red_worker.c/red_init_zlib(),
which is called from red_worker.c/red_worker_main() , so anything after
that is a bit too late. Unless I re-init zlib (which looks like a light
operation) on ever connect.
Thanks,
Y.
TIA,
Y.
Comments are welcome.
Other then that adding a link to the docs page of
inlateInit2/deflateInit2 in the commit message would be nice for those
seeking to find the explanation for the magic numbers, no comment,
thanks for doing this!
If you want a repeatable test you can write one or use one of the
existing artificial tests in server/tests.
Client change:
diff --git a/gtk/decode-zlib.c b/gtk/decode-zlib.c
index a692020..997f350 100644
--- a/gtk/decode-zlib.c
+++ b/gtk/decode-zlib.c
@@ -63,7 +63,7 @@ SpiceZlibDecoder *zlib_decoder_new(void)
d-_z_strm.opaque = Z_NULL;
d-_z_strm.next_in = Z_NULL;
d-_z_strm.avail_in = 0;
- z_ret = inflateInit(d-_z_strm);
+ z_ret = inflateInit2(d-_z_strm, -15);
if (z_ret != Z_OK) {
g_warning(zlib decoder init failed, error %d, z_ret);
goto fail;
server change:
diff --git a/server/zlib_encoder.c b/server/zlib_encoder.c
index c51466b..66a039a 100644
--- a/server/zlib_encoder.c
+++ b/server/zlib_encoder.c
@@ -47,7 +47,7 @@ ZlibEncoder*
zlib_encoder_create(ZlibEncoderUsrContext *usr, int level)
enc-strm.zfree = Z_NULL;
enc-strm.opaque = Z_NULL;
- z_ret = deflateInit(enc-strm, level);
+ z_ret = deflateInit2(enc-strm, level, Z_DEFLATED, -15, 8,
Z_DEFAULT_STRATEGY);
enc-last_level = level;
if (z_ret != Z_OK) {
red_printf(zlib error);
___
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] Use non-zero data for initial ping
On 02/14/2012 10:40 AM, Alon Levy wrote:
SNIP
Other then that looks good, and like you say probably better - although
I'm not convinced that by checking several common desktop compression
programs you are checking whatever compression scheme vpn's are using.
VPNs usually use DEFLATE (which is close to gzip).
Both SSL/TLS and IPsec do, at least.
Y.
But it's probably a good indication of the compressability.
+/* this produces ascending and descending byte runs which vary in offset
+ * every 512 bytes, preventing prevents compression from being able to
+ * influence the resulting size of the ping data too much */
+for(i = 0; i size; i++) {
+div_t result = div(i, 256);
+if(result.quot % 2 == 0) {
+ping_data[i] = (result.quot + 1) * result.rem;
+} else {
+ping_data[i] = 512 - (result.quot * result.rem);
+}
}
+
+spice_marshaller_add(m, ping_data, size);
}
void main_channel_push_mouse_mode(MainChannel *main_chan, int current_mode,
--
1.7.9
___
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
[Spice-devel] Untested idea: enlarge the TCP send buffer (server), receive buffer (client)
For both LAN (high bandwidth, high performance) and WAN (high latency) perhaps it may be worthwhile to increase (via socket options) the TCP receive (on the client) and send (on the server) buffers for the display channel? It will cause: - bigger TCP window (which is good for both cases above) - some waste of memory (negligible, I think it's enough to increase to 256K or so for each). I suspect it might make a difference especially in video streaming. It's a simple patch (I hope - via setsockopt() ) and does not require feature negotiation, but I'm not sure I have the tools to test such change. Thoughts? Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Use non-zero data for initial ping
While the best thing would have been to pass the first image already to
the client using those 256K (and calculate the bandwidth based on the
first data passed to the client and continue to do so, as the protocol
continues), the next best thing would probably be pass *some* image to
the client - some JPEG compressed logo or something.
This is:
(1) already quite compressed.
(2) useful in some way.
(3) probably 'cheaper' than creating some random data.
I think QEMU has this feature (off by default) to load a bootsplash
image as part of the BIOS. I wonder if it can be somehow re-used.
Y.
On 02/13/2012 09:48 PM, Dan McGee wrote:
This prevents compression over things such as VPN links misleading us on
available bandwidth. The page used before was 4K worth of zeroes, which
isn't a very realistic test at all.
We now use a generated sequence of bytes that vary in value and offset
between consecutive values, causing compression programs to have a much
harder time reducing our ping packets to nothing.
Here are some comparisons of before/after using a small standalone
program that generates bytes in the same fashion:
Before:
4096 zerodata
43 zerodata.bz2
38 zerodata.gz
92 zerodata.xz
After:
4096 seqdata
1213 seqdata.bz2
4119 seqdata.gz
3208 seqdata.xz
Signed-off-by: Dan McGeedpmc...@gmail.com
---
This was a TODO item on the following page:
http://spice-space.org/page/Features/Bandwidth_monitoring
The standalone test program is below if anyone wants to try it out; simply pass
'4096' or similar as the first argument and you will get 4096 random bytes on
stdout that you can play with.
#includestdio.h
#includestdlib.h
int main(int argc, char *argv[])
{
int i, total;
total = atoi(argv[1]);
for(i = 0; i total; i++) {
div_t result = div(i, 256);
if(result.quot % 2 == 0) {
fputc((result.quot + 1) * result.rem, stdout);
} else {
fputc(512 - (result.quot * result.rem), stdout);
}
}
return 0;
}
server/main_channel.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index f7e1ab0..2ce20c0 100644
--- a/server/main_channel.c
+++ b/server/main_channel.c
@@ -22,6 +22,7 @@
#includeinttypes.h
#includestdint.h
#includestdio.h
+#includestdlib.h
#includeunistd.h
#includesys/socket.h
#includenetinet/in.h
@@ -45,8 +46,6 @@
#include red_channel.h
#include generated_marshallers.h
-#define ZERO_BUF_SIZE 4096
-
#define REDS_MAX_SEND_IOVEC 100
#define NET_TEST_WARMUP_BYTES 0
@@ -54,8 +53,6 @@
#define PING_INTERVAL (1000 * 10)
-static uint8_t zero_page[ZERO_BUF_SIZE] = {0};
-
typedef struct RedsOutItem RedsOutItem;
struct RedsOutItem {
PipeItem base;
@@ -335,17 +332,28 @@ static void main_channel_marshall_ping(SpiceMarshaller
*m, int size, int ping_id
{
struct timespec time_space;
SpiceMsgPing ping;
+uint8_t *ping_data;
+int i;
ping.id = ping_id;
clock_gettime(CLOCK_MONOTONIC,time_space);
ping.timestamp = time_space.tv_sec * 100LL + time_space.tv_nsec /
1000LL;
spice_marshall_msg_ping(m,ping);
-while (size 0) {
-int now = MIN(ZERO_BUF_SIZE, size);
-size -= now;
-spice_marshaller_add_ref(m, zero_page, now);
+ping_data = spice_malloc(size);
+/* this produces ascending and descending byte runs which vary in offset
+ * every 512 bytes, preventing prevents compression from being able to
+ * influence the resulting size of the ping data too much */
+for(i = 0; i size; i++) {
+div_t result = div(i, 256);
+if(result.quot % 2 == 0) {
+ping_data[i] = (result.quot + 1) * result.rem;
+} else {
+ping_data[i] = 512 - (result.quot * result.rem);
+}
}
+
+spice_marshaller_add(m, ping_data, size);
}
void main_channel_push_mouse_mode(MainChannel *main_chan, int current_mode,
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Untested idea: enlarge the TCP send buffer (server), receive buffer (client)
On 02/13/2012 10:47 PM, Yaniv Kaul wrote:
For both LAN (high bandwidth, high performance) and WAN (high latency)
perhaps it may be worthwhile to increase (via socket options) the TCP
receive (on the client) and send (on the server) buffers for the
display channel? It will cause:
- bigger TCP window (which is good for both cases above)
- some waste of memory (negligible, I think it's enough to increase
to 256K or so for each).
I suspect it might make a difference especially in video streaming.
It's a simple patch (I hope - via setsockopt() ) and does not require
feature negotiation, but I'm not sure I have the tools to test such
change.
Thoughts?
Y.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Compile tested only, on the server:
diff --git a/server/reds.c b/server/reds.c
index 828ba65..6c52c2a 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2696,6 +2696,7 @@ static RedLinkInfo
*reds_init_client_connection(int socket)
RedsStream *stream;
int delay_val = 1;
int flags;
+int sndsize = 256 * 1204;
if ((flags = fcntl(socket, F_GETFL)) == -1) {
red_printf(accept failed, %s, strerror(errno));
@@ -2712,6 +2713,11 @@ static RedLinkInfo
*reds_init_client_connection(int socket)
red_printf(setsockopt failed, %s, strerror(errno));
}
}
+if (setsockopt(socket, SOL_SOCKET, SO_SNDBUF, (char *)sndsize,
(int)sizeof(sndsize)) == -1) {
+ if (errno != ENOTSUP) {
+ red_printf(setsockopt for SO_SNDBUF failed, %s,
strerror(errno));
+ }
+}
link = spice_new0(RedLinkInfo, 1);
stream = spice_new0(RedsStream, 1);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Use non-zero data for initial ping
On 02/14/2012 01:54 AM, Dan McGee wrote: On Mon, Feb 13, 2012 at 3:11 PM, Yaniv Kaulyk...@redhat.com wrote: While the best thing would have been to pass the first image already to the client using those 256K (and calculate the bandwidth based on the first data passed to the client and continue to do so, as the protocol continues), the next best thing would probably be pass *some* image to the client - some JPEG compressed logo or something. This is: (1) already quite compressed. (2) useful in some way. (3) probably 'cheaper' than creating some random data. I think QEMU has this feature (off by default) to load a bootsplash image as part of the BIOS. I wonder if it can be somehow re-used. This sounds cool, but also seems overkill for at least this initial improvement to the ping functionality, which is completely broken right now if compression is involved, as far as I can tell. I'd rather get this in first, then let someone else improve it if they find the need for something better. Yes, agreed. As far as (1) and (3) are concerned, would it be an awful idea to just compile this data in? Take something like http://gulf.br.tripod.com/wallpaper/tux.jpg (around 256KB), convert it to a C unsigned char array, and use that as the data packets. I think it makes sense to look at what QEMU is doing with the bootsplash first. Y. For (2), making it useful, that seems like a much bigger proposition that I was hoping not to get involved with here. -Dan ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] spice-xpi and spicec or spice-gtk as the client
Are there plans that spice-xpi would use spice-gtk instead of spicec? Otherwise, it looks like there are features developed only in spice-gtk, and spicec is going to lag behind. (just installed spice-xpi on Fedora, and it only brought spice-client RPM with it). Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] spice - fix typo: recive - receive
Fix typo: recive - receive
No functional changes, compile tested only.
diff --git a/server/main_channel.h b/server/main_channel.h
index c5d407e..1a1ad59 100644
--- a/server/main_channel.h
+++ b/server/main_channel.h
@@ -38,8 +38,8 @@ struct MainMigrateData {
uint32_t read_state;
VDIChunkHeader vdi_chunk_header;
-uint32_t recive_len;
-uint32_t message_recive_len;
+uint32_t receive_len;
+uint32_t message_receive_len;
uint32_t read_buf_len;
uint32_t write_queue_size;
@@ -51,12 +51,12 @@ struct MainMigrateData {
#define REDS_NUM_INTERNAL_AGENT_MESSAGES 1
// approximate max receive message size for main channel
-#define RECEIVE_BUF_SIZE \
+#define MAIN_RECEIVE_BUF_SIZE \
(4096 + (REDS_AGENT_WINDOW_SIZE +
REDS_NUM_INTERNAL_AGENT_MESSAGES) * SPICE_AGENT_MAX_DATA_SIZE)
typedef struct MainChannel {
RedChannel base;
-uint8_t recv_buf[RECEIVE_BUF_SIZE];
+uint8_t recv_buf[MAIN_RECEIVE_BUF_SIZE];
RedsMigSpice mig_target; // TODO: add refs and release (afrer all
clients completed migration in one way or the other?)
int num_clients_mig_wait;
} MainChannel;
diff --git a/server/red_worker.c b/server/red_worker.c
index 80fa825..d476791 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -333,7 +333,7 @@ typedef struct LocalCursor {
} LocalCursor;
#define MAX_PIPE_SIZE 50
-#define RECIVE_BUF_SIZE 1024
+#define RECEIVE_BUF_SIZE 1024
#define WIDE_CLIENT_ACK_WINDOW 40
#define NARROW_CLIENT_ACK_WINDOW 20
@@ -582,7 +582,7 @@ typedef struct CommonChannel {
RedChannel base; // Must be the first thing
event_listener_action_proc listener_action;
struct RedWorker *worker;
-uint8_t recv_buf[RECIVE_BUF_SIZE];
+uint8_t recv_buf[RECEIVE_BUF_SIZE];
uint32_t id_alloc; // bitfield. TODO - use this instead of shift
scheme.
} CommonChannel;
diff --git a/server/reds.c b/server/reds.c
index 2492a89..9142cfa 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -167,9 +167,9 @@ typedef struct VDIPortState {
Ring read_bufs;
uint32_t read_state;
-uint32_t message_recive_len;
-uint8_t *recive_pos;
-uint32_t recive_len;
+uint32_t message_receive_len;
+uint8_t *receive_pos;
+uint32_t receive_len;
VDIReadBuf *current_read_buf;
AgentMsgFilter read_filter;
@@ -581,9 +581,9 @@ static void reds_reset_vdp(void)
buf-free(buf);
}
state-read_state = VDI_PORT_READ_STATE_READ_HADER;
-state-recive_pos = (uint8_t *)state-vdi_chunk_header;
-state-recive_len = sizeof(state-vdi_chunk_header);
-state-message_recive_len = 0;
+state-receive_pos = (uint8_t *)state-vdi_chunk_header;
+state-receive_len = sizeof(state-vdi_chunk_header);
+state-message_receive_len = 0;
if (state-current_read_buf) {
ring_add(state-read_bufs, state-current_read_buf-link);
state-current_read_buf = NULL;
@@ -876,18 +876,18 @@ static int read_from_vdi_port(void)
while (!quit_loop vdagent) {
switch (state-read_state) {
case VDI_PORT_READ_STATE_READ_HADER:
-n = sif-read(vdagent, state-recive_pos, state-recive_len);
+n = sif-read(vdagent, state-receive_pos, state-receive_len);
if (!n) {
quit_loop = 1;
break;
}
total += n;
-if ((state-recive_len -= n)) {
-state-recive_pos += n;
+if ((state-receive_len -= n)) {
+state-receive_pos += n;
quit_loop = 1;
break;
}
-state-message_recive_len = state-vdi_chunk_header.size;
+state-message_receive_len = state-vdi_chunk_header.size;
state-read_state = VDI_PORT_READ_STATE_GET_BUFF;
case VDI_PORT_READ_STATE_GET_BUFF: {
RingItem *item;
@@ -899,31 +899,31 @@ static int read_from_vdi_port(void)
ring_remove(item);
state-current_read_buf = (VDIReadBuf *)item;
-state-recive_pos = state-current_read_buf-data;
-state-recive_len = MIN(state-message_recive_len,
+state-receive_pos = state-current_read_buf-data;
+state-receive_len = MIN(state-message_receive_len,
sizeof(state-current_read_buf-data));
-state-current_read_buf-len = state-recive_len;
-state-message_recive_len -= state-recive_len;
+state-current_read_buf-len = state-receive_len;
+state-message_receive_len -= state-receive_len;
state-read_state = VDI_PORT_READ_STATE_READ_DATA;
}
case VDI_PORT_READ_STATE_READ_DATA:
-n = sif-read(vdagent, state-recive_pos, state-recive_len);
+n = sif-read(vdagent, state-receive_pos, state-receive_len);
if (!n) {
quit_loop = 1;
break;
}
total += n;
-if ((state-recive_len -= n))
Re: [Spice-devel] [Users] oVirt console plans
On 01/31/2012 07:38 AM, Brown, Chris (GE Healthcare) wrote: I did some more extensive testing tonight to see how many guests would have issues with a SPICE based console. This testing was specifically during guest OS install time. On how many of them was the Spice guest agent installed? Without it, you will not have client-side mouse, which contributes to a much better mouse behaviour. Here is the list and the results - Red Hat 7.3 -- Mouse unusable - Red Hat 9 -- Mouse unusable - Fedora core 1 - 14 -- Mouse unusable - Fedora core 15 Mouse useable - Fedora core 16 Mouse useable - Red Hat Enterprise 3.x -- Mouse unusable - Red Hat Enterprise 4.x -- Mouse unusable - Red Hat Enterprise 5.x -- Mouse unusable - Red Hat Enterpise 6.x -- Mouse useable - SLES 10 -- Mouse unusable - SLES 11 -- Mouse unusable - SLES 11 SP1 -- Mouse unusable - OpenSUSE 11.1 -- Mouse unusable - OpenSUSE 11.2 -- Mouse useable - OpenSUSE 11.3 -- Mouse useable - OpenSUSE 11.4 -- Mouse useable - Windows 2000 SP4 -- Mouse unusable - Windows XP -- Mouse unusable - Windows Vista -- Mouse unusable - Windows Server 2003 -- Mouse unusable - Windows Server 2003 R2 -- Mouse unusable - Windows Server 2008 -- Mouse unusable - Windows Server 2008 R2 -- Mouse unusable - Solaris 10 Update9 -- Mouse unusable - Solaris 11 Express -- Mouse unusable - Solaris 11 -- Mouse unusable Out of curiosity, and assuming you haven't spent all night on this - how are you testing so many different operating systems? And moreover, if you are already into testing so many, any other issues encountered? Networking works OK across all of them? Impressive work, Y. Of the above guests all of them were fine with a VNC console. The windows guests could be loaded via vnc then the qxl drivers installed after install and all was well. However the older Linux guests and all solaris guests were not able to be made to work with spice during run time forcing VNC to be used if mouse interaction is required. IMHO if spice will be the only supported console type then some work needs to be done to take older linux guests and other operating systems into consideration. This particularly applies to the PuP when developers or users are loading guests from scratch. - Chris From: Brown, Chris (GE Healthcare) Sent: Mon 1/30/2012 2:09 PM To: 'Itamar Heim'; André Felício Cc: spice-devel@lists.freedesktop.org; us...@ovirt.org; David Blechter Subject: RE: [Users] oVirt console plans You can just rebuild the current RHEV spice-xpi source RPM and drop the resulting files into you ovirt install. - Found here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/rhevm-spice-client-3.0-21.el6.src.rpm - rpmbuild --rebuild rhevm-spice-client-3.0-21.el6.src.rpm (install dependent packages via yum if build fails due to deps, not that many needed) - unpack the resulting spice-xpi client isntallers and cabs from the rpms using: rpm2cpio - rpm2cpionameofrpm | cpio -ivd - place the files into their corresponding locations on your ovirt install. - you can find the paths where things go via rpm -qlppackagename replace rhevm with engine pathing wise - Pathing on ovirt should be something like: -- /usr/share/ovirt-engine/engine.ear/engineanger.ear/ -- /usr/share/ovirt-engine/enginer.ear/userportal.ear/ovirt.org... -restart jboss and you will be good to go - Chris -Original Message- From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of Itamar Heim Sent: Monday, January 30, 2012 2:01 PM To: André Felício Cc: spice-devel@lists.freedesktop.org; us...@ovirt.org; David Blechter Subject: Re: [Users] oVirt console plans On 01/30/2012 09:58 PM, André Felício wrote: There are many SO (windows) that access by SPICE is a little tricky. What's tricky with Spice? If there's anything we can do to help make Spice easier to use, let us know. I tried compiling spice-xpi for windows it several times and it still fails. Anyone have the spice-client and spice-xpi compiled for windows? cc'ing spice-devel to provide input on status/availability of spice-xpi for windows and/or spice-activex. OVirt appears VNC console in the option but does not have a way to access it over webadmin. ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] RFC: remove Adler checksum and zlib header/trailer from zlib compressed images
These small changes to server and (gtk) client seem to work, and remove
both the zlib header/trailer from the deflate stream as well as the
Adler checksum, which removes several bytes from the stream as well as
speedup (unnoticeable) of the compression/decompression due to the
removal of the checksum calculation.
Problem is - not sure how to test it - don't know how to get an image
once with and once without the patch - and ensure it's the same image.
The fact that the first image is never zlib compressed complicates
things. I could not reliably get a 2nd image sent to the client which
looks the same as one in a different connection.
Nevertheless it does no harm - and images pass well - verified by
connecting with a modified Spice GTK client to a modified Spice server,
as well as looking at the network capture via wireshark.
It's of course missing the display channel specific capability
negotiation for this change.
Comments are welcome.
Client change:
diff --git a/gtk/decode-zlib.c b/gtk/decode-zlib.c
index a692020..997f350 100644
--- a/gtk/decode-zlib.c
+++ b/gtk/decode-zlib.c
@@ -63,7 +63,7 @@ SpiceZlibDecoder *zlib_decoder_new(void)
d-_z_strm.opaque = Z_NULL;
d-_z_strm.next_in = Z_NULL;
d-_z_strm.avail_in = 0;
-z_ret = inflateInit(d-_z_strm);
+z_ret = inflateInit2(d-_z_strm, -15);
if (z_ret != Z_OK) {
g_warning(zlib decoder init failed, error %d, z_ret);
goto fail;
server change:
diff --git a/server/zlib_encoder.c b/server/zlib_encoder.c
index c51466b..66a039a 100644
--- a/server/zlib_encoder.c
+++ b/server/zlib_encoder.c
@@ -47,7 +47,7 @@ ZlibEncoder* zlib_encoder_create(ZlibEncoderUsrContext
*usr, int level)
enc-strm.zfree = Z_NULL;
enc-strm.opaque = Z_NULL;
-z_ret = deflateInit(enc-strm, level);
+z_ret = deflateInit2(enc-strm, level, Z_DEFLATED, -15, 8,
Z_DEFAULT_STRATEGY);
enc-last_level = level;
if (z_ret != Z_OK) {
red_printf(zlib error);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Where is xf86-video-qxl discussed?
Would be nice to see commits to it sent to the spice-comm...@lists.freedesktop.org , if that's possible. Is it discussed here (spice-devel) or elsewhere? I've noticed caching was finally added to it, but I'm not sure I understand how it works. Specifically, I don't see how images are actually fetched from the cache. They seem to be always added? (I expected a call to lookup_image_info() to see if it's already in the cache). Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Failure to compile spice-gtk
As usual, I'm having problems with the strict requirements of spice-gtk (why can't it just disable usbredir if it does not find it in the ./configure phase is beyond me). I suspect too old RPMs, but I'm not sure where I should be taking newer ones (same goes to usbredir, but at least I can disable it). make[2]: Entering directory `/home/ykaul/spice-gtk/gtk' CCLD libspice-client-gtk-3.0.la GISCAN SpiceClientGtk-3.0.gir ./.libs/libspice-client-gtk-3.0.so: undefined reference to `gdk_x11_drawable_get_xdisplay' ./.libs/libspice-client-gtk-3.0.so: undefined reference to `gdk_window_object_get_type' ./.libs/libspice-client-gtk-3.0.so: undefined reference to `gdk_threads_lock' ./.libs/libspice-client-gtk-3.0.so: undefined reference to `gdk_x11_window_get_drawable_impl' ./.libs/libspice-client-gtk-3.0.so: undefined reference to `gdk_drawable_get_size' ./.libs/libspice-client-gtk-3.0.so: undefined reference to `gdk_threads_unlock' collect2: ld returned 1 exit status linking of temporary binary failed: Command '['/bin/sh', '../libtool', '--mode=link', '--tag=CC', '--silent', 'gcc', '-o', '/home/ykaul/spice-gtk/gtk/tmp-introspectQbgQDo/SpiceClientGtk-3.0', '-export-dynamic', '-L.', 'libspice-client-gtk-3.0.la', 'libspice-client-glib-2.0.la', '-pthread', '-lgio-2.0', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '/home/ykaul/spice-gtk/gtk/tmp-introspectQbgQDo/SpiceClientGtk-3.0.o']' returned non-zero exit status 1 make[2]: *** [SpiceClientGtk-3.0.gir] Error 1 make[2]: Leaving directory `/home/ykaul/spice-gtk/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ykaul/spice-gtk' make: *** [all] Error 2 or with GTK 2.0: make[2]: Entering directory `/home/ykaul/spice-gtk/gtk' GISCAN SpiceClientGtk-2.0.gir ./.libs/libspice-client-gtk-2.0.so: undefined reference to `gdk_x11_display_get_type' collect2: ld returned 1 exit status linking of temporary binary failed: Command '['/bin/sh', '../libtool', '--mode=link', '--tag=CC', '--silent', 'gcc', '-o', '/home/ykaul/spice-gtk/gtk/tmp-introspectzr3KkC/SpiceClientGtk-2.0', '-export-dynamic', '-L.', 'libspice-client-gtk-2.0.la', 'libspice-client-glib-2.0.la', '-pthread', '-lgio-2.0', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '/home/ykaul/spice-gtk/gtk/tmp-introspectzr3KkC/SpiceClientGtk-2.0.o']' returned non-zero exit status 1 make[2]: *** [SpiceClientGtk-2.0.gir] Error 1 make[2]: Leaving directory `/home/ykaul/spice-gtk/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ykaul/spice-gtk' make: *** [all] Error 2 [ykaul@ykaul spice-gtk]$ rpm -qa |grep spice |grep gtk spice-gtk-devel-0.7.39-1.fc16.x86_64 spice-gtk3-devel-0.7.39-1.fc16.x86_64 spice-gtk-python-0.7.39-1.fc16.x86_64 spice-gtk3-0.7.39-1.fc16.x86_64 spice-gtk-0.7.39-1.fc16.x86_64 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Delay in Gimp when using qxl driver
On 01/23/2012 12:26 PM, Dominique Rodrigues wrote: Le 23/01/2012 11:41, Alon Levy a écrit : On Sun, Jan 22, 2012 at 11:05:59PM +0100, Dominique Rodrigues wrote: Le 22/01/2012 22:36, Alon Levy a écrit : On Sun, Jan 22, 2012 at 11:03:47PM +0200, Alon Levy wrote: On Sun, Jan 22, 2012 at 06:33:59PM +0100, Dominique Rodrigues wrote: Le 22/01/2012 18:28, Alon Levy a écrit : On Sun, Jan 22, 2012 at 05:15:42PM +0200, Alon Levy wrote: On Sun, Jan 22, 2012 at 03:53:40PM +0100, Dominique Rodrigues wrote: Le 22/01/2012 16:00, Alon Levy a écrit : On Fri, Jan 20, 2012 at 02:04:47PM -0500, Yaniv Kaul wrote: - Original Message - On Wed, Jan 18, 2012 at 11:59:45AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 11:48, Alon Levy a écrit : On Wed, Jan 18, 2012 at 11:39:13AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 11:32, Alon Levy a écrit : On Wed, Jan 18, 2012 at 11:27:14AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 11:18, Alon Levy a écrit : On Wed, Jan 18, 2012 at 09:54:49AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 09:44, Alon Levy a écrit : On Wed, Jan 18, 2012 at 08:06:40AM +0100, Dominique Rodrigues wrote: Hi, Since I use qxl driver in virtual desktop powered by qemu-kvm, I found a strange problem with Gimp. After launching Gimp, open a new windows, and then try to draw something. It appears that the drawing is very slow and does not follow the mouse at all. It is the same if I use spicy, spicec or vnc to connect to my virtual desktop. This problem does not appear with cirrus or vmware graphic drivers. I found that on any Linux distribution (CentOS, RHEL, Scientific Linux, Debian, Ubuntu). I currently use : - qemu-kvm 1.0 compiled with spice support - spice-protocol 0.10.1 - spice 0.10 - spice-gtk 0.7 - xorg-qxl driver 0.16 Is there any explanation for that ? I would assume it is qxl driver cpu bound on something, probably busy waiting on the command ring. Can you run perf top on the guest? Indeed, during the drawing in Gimp, Xorg takes between 55% and 66% of CPU. After, Xorg goes down to 0.3%. (Test done on CentOS 6.2 guest, with 1280 Mb vRAM) ok, can you drill down - you should be able to install the debug symbols for the qxl driver (xorg-x11-drv-qxl package) and see the specific functions that are taking the most time. I installed qxl driver from freedesktop.org : # wget -c http://xorg.freedesktop.org/releases/individual/driver/xf86-video-qxl-0.0.16.tar.bz2 # tar xvfj xf86-video-qxl-0.0.16.tar.bz2 # cd xf86-video-qxl-0.0.16 # ./configure --libdir=/usr/lib64 --prefix=/usr CFLAGS='-O3' # make # make install Do you mean that I should use CFLAGS with -g ? I think that's it, yes. Ok. So how do you profile debug messages afterwhile ? If I tail -f /var/log/Xorg.0.log, the only message I got is : Bad bpp: 1 (1) Other messages look standard. Right, that's not interesting. What I meant was: # yum install perf # perf top copy paste the top entries. Ok, that's it (from a screenshot of the VM): Try ssh'ing to the vm, you can then use copy-paste. samplespcntfunctionDSO 3796.0060.4%hashlittle This sucks, unfortunately I don't have any quick fix for it. It's the hash computation done on each image. Needless to say it needs to be optimized - either made more efficient or reduce the number of calls. Soren, FYI. You could move to murmur2, like Windows' QXL driver (https://bugs.freedesktop.org/show_bug.cgi?id=37465) or murmur3 or other faster ones (https://bugs.freedesktop.org/show_bug.cgi?id=35775). At least it's not hashed twice now(https://bugs.freedesktop.org/show_bug.cgi?id=37977 - worth updating bug status?!), but I'm not sure it should be hashed at all, if it's not cached. Y. Looks like this could be x6 performance gain when compared to hashlittle (lookup3 at http://code.google.com/p/smhasher/). So it would still be better not to run it at all but it might stop being the bottleneck. I'll try to do a patch. Sounds promising. Actually only 2x since we use a 32bit hash anyway (x86/x64). Still worth a patch. Since the hash is not in use right now at all, but commented out, you could get an even more remarkable performance improvement by disabling it. If you can check the branch at git://people.freedesktop.org/~alon/xf86-video-qxl murmur3 You can tell us how much it actually improves for you. I didn't disable the hashing, just replaced lookup3 with MurmurHash3 from http://code.google.com/p/smhasher/wiki/MurmurHash3. I guess I missed something, because I don't manage to launch the X-server now in my CentOS guest. This what I have done : # git clone git://people.freedesktop.org/~alon/xf86-video-qxl xf86-video-qxl-alon-git # cd xf86-video-qxl-alon-git # git checkout murmur3 # git branch * murmur3 surface-fixes # export PKG_CONFIG_PATH=/usr/local//share/pkgconfig/:/usr/local/lib/pkgconfig # ./autogen.sh --libdir=/usr/lib64 --prefix=/usr CFLAGS='-O3' # make # make
Re: [Spice-devel] Delay in Gimp when using qxl driver
- Original Message - On Wed, Jan 18, 2012 at 11:59:45AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 11:48, Alon Levy a écrit : On Wed, Jan 18, 2012 at 11:39:13AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 11:32, Alon Levy a écrit : On Wed, Jan 18, 2012 at 11:27:14AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 11:18, Alon Levy a écrit : On Wed, Jan 18, 2012 at 09:54:49AM +0100, Dominique Rodrigues wrote: Le 18/01/2012 09:44, Alon Levy a écrit : On Wed, Jan 18, 2012 at 08:06:40AM +0100, Dominique Rodrigues wrote: Hi, Since I use qxl driver in virtual desktop powered by qemu-kvm, I found a strange problem with Gimp. After launching Gimp, open a new windows, and then try to draw something. It appears that the drawing is very slow and does not follow the mouse at all. It is the same if I use spicy, spicec or vnc to connect to my virtual desktop. This problem does not appear with cirrus or vmware graphic drivers. I found that on any Linux distribution (CentOS, RHEL, Scientific Linux, Debian, Ubuntu). I currently use : - qemu-kvm 1.0 compiled with spice support - spice-protocol 0.10.1 - spice 0.10 - spice-gtk 0.7 - xorg-qxl driver 0.16 Is there any explanation for that ? I would assume it is qxl driver cpu bound on something, probably busy waiting on the command ring. Can you run perf top on the guest? Indeed, during the drawing in Gimp, Xorg takes between 55% and 66% of CPU. After, Xorg goes down to 0.3%. (Test done on CentOS 6.2 guest, with 1280 Mb vRAM) ok, can you drill down - you should be able to install the debug symbols for the qxl driver (xorg-x11-drv-qxl package) and see the specific functions that are taking the most time. I installed qxl driver from freedesktop.org : # wget -c http://xorg.freedesktop.org/releases/individual/driver/xf86-video-qxl-0.0.16.tar.bz2 # tar xvfj xf86-video-qxl-0.0.16.tar.bz2 # cd xf86-video-qxl-0.0.16 # ./configure --libdir=/usr/lib64 --prefix=/usr CFLAGS='-O3' # make # make install Do you mean that I should use CFLAGS with -g ? I think that's it, yes. Ok. So how do you profile debug messages afterwhile ? If I tail -f /var/log/Xorg.0.log, the only message I got is : Bad bpp: 1 (1) Other messages look standard. Right, that's not interesting. What I meant was: # yum install perf # perf top copy paste the top entries. Ok, that's it (from a screenshot of the VM): Try ssh'ing to the vm, you can then use copy-paste. samplespcntfunctionDSO 3796.0060.4%hashlittle This sucks, unfortunately I don't have any quick fix for it. It's the hash computation done on each image. Needless to say it needs to be optimized - either made more efficient or reduce the number of calls. Soren, FYI. You could move to murmur2, like Windows' QXL driver (https://bugs.freedesktop.org/show_bug.cgi?id=37465) or murmur3 or other faster ones (https://bugs.freedesktop.org/show_bug.cgi?id=35775). At least it's not hashed twice now(https://bugs.freedesktop.org/show_bug.cgi?id=37977 - worth updating bug status?!), but I'm not sure it should be hashed at all, if it's not cached. Y. /usr/lib64/xorg/modules/drivers/qxl_drv.so 2014.0032.1%__memcpy_ssse3 /lib64/libc-2.12.so 341.005.4%download_box /usr/lib64/xorg/modules/drivers/qxl_drv.so 61.00 1.0%__memset_sse2 /lib64/libc-2.12.so 11.00 0.2%qxl_ring_push /usr/lib64/xorg/modules/drivers/qxl_drv.so 10.00 0.2%finish_task_switch[kernel.kallsyms] 8.00 0.1%qxl_allocnf /usr/lib64/xorg/modules/drivers/qxl_drv.so 8.00 0.1%retint_careful [kernel.kallsyms] 6.00 0.1%hash_and_copy /usr/lib64/xorg/modules/drivers/qxl_drv.so Regards, -- Dominique Rodrigues nanoClouDhttp://www.nanocloud.com 8, rue Lemercier 75017 Paris France standard : +33 1 77 69 64 38 529 002 743 R.C.S. Paris begin:vcard fn:Dominique Rodrigues n:Rodrigues;Dominique org:nanoClouD adr:;;8, rue Lemercier;Paris;;75017;France email;internet:dominique.rodrig...@nanocloud.com title:Directeur Technique tel;work:+33 (0) 1 77 69 64 38 tel;cell:+33 (0) 6 28 52 37 70 url:www.nanocloud.com version:2.1 end:vcard ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel begin:vcard fn:Dominique Rodrigues n:Rodrigues;Dominique org:nanoClouD adr:;;8, rue Lemercier;Paris;;75017;France email;internet:dominique.rodrig...@nanocloud.com title:Directeur Technique tel;work:+33 (0) 1 77 69 64 38 tel;cell:+33 (0) 6 28 52 37 70 url:www.nanocloud.com version:2.1
Re: [Spice-devel] spice-protocol mess
On 01/15/2012 10:40 AM, Yaniv Kaul wrote: On 01/15/2012 10:13 AM, Yonit Halperin wrote: SNIP BTW, Yaniv, can you update the wireshark dissector to handle the new protocol? Yonit. Already on it, hopefully patch will be ready by the end of the week. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6743 Y. I'm not sure the capability exchange was done in the spirit of the protocol (I think each capability should have had its own word, so 'auth.' was the first word, 'wan features' the 2nd, and not just use the next bit, but I'll adjust the dissector to this). Y. I'm not sure. Someone needs to check. Right, which is why I called the code adventurous :) Regards, Hans ___ 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] spice-protocol mess
On 01/15/2012 10:13 AM, Yonit Halperin wrote: SNIP BTW, Yaniv, can you update the wireshark dissector to handle the new protocol? Yonit. Already on it, hopefully patch will be ready by the end of the week. I'm not sure the capability exchange was done in the spirit of the protocol (I think each capability should have had its own word, so 'auth.' was the first word, 'wan features' the 2nd, and not just use the next bit, but I'll adjust the dissector to this). Y. I'm not sure. Someone needs to check. Right, which is why I called the code adventurous :) Regards, Hans ___ 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] Failure to compile spice-gtk (git clone git://git.engineering.redhat.com/users/rvaknin/preint_scripts/.git)
Latest git, on F16/x64: CC channel-usbredir.lo channel-usbredir.c: In function 'spice_usbredir_channel_open_device': channel-usbredir.c:193:5: error: implicit declaration of function 'usbredirhost_open_full' [-Werror=implicit-function-declaration] channel-usbredir.c:193:16: error: assignment makes pointer from integer without a cast [-Werror] cc1: all warnings being treated as errors ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failure to compile spice-gtk (git clone git://git.engineering.redhat.com/users/rvaknin/preint_scripts/.git)
On 01/05/2012 02:13 PM, Yaniv Kaul wrote: Latest git, on F16/x64: CC channel-usbredir.lo channel-usbredir.c: In function 'spice_usbredir_channel_open_device': channel-usbredir.c:193:5: error: implicit declaration of function 'usbredirhost_open_full' [-Werror=implicit-function-declaration] channel-usbredir.c:193:16: error: assignment makes pointer from integer without a cast [-Werror] cc1: all warnings being treated as errors ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel And when doing: ./configure --enable-usbredir=no On 'make' I'm getting: ... CC usb-device-manager.lo In file included from usb-device-manager.c:44:0: usb-device-manager-priv.h:28:59: error: 'enum libusb_error' declared inside parameter list [-Werror] usb-device-manager-priv.h:28:59: error: its scope is only this definition or declaration, which is probably not what you want [-Werror] usb-device-manager.c: In function 'spice_usb_device_get_type': usb-device-manager.c:123:1: error: 'libusb_ref_device' undeclared (first use in this function) usb-device-manager.c:123:1: note: each undeclared identifier is reported only once for each function it appears in usb-device-manager.c:123:1: error: 'libusb_unref_device' undeclared (first use in this function) usb-device-manager.c: In function 'spice_usb_device_manager_init': usb-device-manager.c:136:53: error: 'libusb_unref_device' undeclared (first use in this function) usb-device-manager.c: In function 'spice_usb_device_manager_get_devices': usb-device-manager.c:746:51: error: 'libusb_unref_device' undeclared (first use in this function) usb-device-manager.c:748:9: error: unknown type name 'libusb_device' usb-device-manager.c:749:9: error: implicit declaration of function 'libusb_ref_device' [-Werror=implicit-function-declaration] usb-device-manager.c:749:9: error: passing argument 2 of 'g_ptr_array_add' makes pointer from integer without a cast [-Werror] /usr/include/glib-2.0/glib/garray.h:136:12: note: expected 'gpointer' but argument is of type 'int' cc1: all warnings being treated as errors ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failure to compile spice-gtk (git clone git://git.engineering.redhat.com/users/rvaknin/preint_scripts/.git)
On 01/05/2012 03:13 PM, Christophe Fergeau wrote: On Thu, Jan 05, 2012 at 02:13:57PM +0200, Yaniv Kaul wrote: Latest git, on F16/x64: CC channel-usbredir.lo channel-usbredir.c: In function 'spice_usbredir_channel_open_device': channel-usbredir.c:193:5: error: implicit declaration of function 'usbredirhost_open_full' [-Werror=implicit-function-declaration] channel-usbredir.c:193:16: error: assignment makes pointer from integer without a cast [-Werror] cc1: all warnings being treated as errors What version/git commit of libusbredir are you using? spice-gtk git should be checking for the right version of usbredir, but it seems something unexpected is going on here... Christophe [ykaul@ykaul qemu-kvm]$ rpm -qa|grep usb libusb1-devel-doc-1.0.9-0.3.rc1.fc16.noarch usbredir-0.3.1-1.fc16.x86_64 libusb1-devel-1.0.9-0.3.rc1.fc16.x86_64 libgusb-0.1.3-1.fc16.x86_64 usbmuxd-1.0.7-1.fc16.x86_64 usbutils-003-4.fc16.x86_64 usbredir-devel-0.3.1-1.fc16.x86_64 libusb1-1.0.9-0.3.rc1.fc16.x86_64 libusb-0.1.3-9.fc16.x86_64 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failure to compile spice-gtk (git clone git://git.engineering.redhat.com/users/rvaknin/preint_scripts/.git)
On 01/05/2012 03:31 PM, Christophe Fergeau wrote: On Thu, Jan 05, 2012 at 03:26:48PM +0200, Yaniv Kaul wrote: [ykaul@ykaul qemu-kvm]$ rpm -qa|grep usb libusb1-devel-doc-1.0.9-0.3.rc1.fc16.noarch usbredir-0.3.1-1.fc16.x86_64 libusb1-devel-1.0.9-0.3.rc1.fc16.x86_64 libgusb-0.1.3-1.fc16.x86_64 usbmuxd-1.0.7-1.fc16.x86_64 usbutils-003-4.fc16.x86_64 usbredir-devel-0.3.1-1.fc16.x86_64 libusb1-1.0.9-0.3.rc1.fc16.x86_64 libusb-0.1.3-9.fc16.x86_64 And autogen.sh still tried to compile usb redirection support in? Could you No, re-running autogen.sh gave me the below error. I guess it's my fault, being used to update git and run ./configure , not autogen... send the ouput of autogen.sh and config.log? configure.ac should be checking for a new enough libusbredir: PKG_CHECK_MODULES(LIBUSBREDIRHOST, libusbredirhost= 0.3.2) I just checked here what happens with libusbredirhost 0.3.1: ./autogen.sh checking for LIBUSBREDIRHOST... no configure: error: Package requirements (libusbredirhost= 0.3.2) were not met: Requested 'libusbredirhost= 0.3.2' but version of libusbredirhost is 0.3.1 I wonder where can I get a RPM of 0.3.2. donno where I got the 0.3.1 one. Y. Christophe ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failure to compile spice-gtk (git clone git://git.engineering.redhat.com/users/rvaknin/preint_scripts/.git)
On 01/05/2012 03:42 PM, Christophe Fergeau wrote: On Thu, Jan 05, 2012 at 03:38:11PM +0200, Yaniv Kaul wrote: On 01/05/2012 03:31 PM, Christophe Fergeau wrote: On Thu, Jan 05, 2012 at 03:26:48PM +0200, Yaniv Kaul wrote: [ykaul@ykaul qemu-kvm]$ rpm -qa|grep usb libusb1-devel-doc-1.0.9-0.3.rc1.fc16.noarch usbredir-0.3.1-1.fc16.x86_64 libusb1-devel-1.0.9-0.3.rc1.fc16.x86_64 libgusb-0.1.3-1.fc16.x86_64 usbmuxd-1.0.7-1.fc16.x86_64 usbutils-003-4.fc16.x86_64 usbredir-devel-0.3.1-1.fc16.x86_64 libusb1-1.0.9-0.3.rc1.fc16.x86_64 libusb-0.1.3-9.fc16.x86_64 And autogen.sh still tried to compile usb redirection support in? Could you No, re-running autogen.sh gave me the below error. I guess it's my fault, being used to update git and run ./configure , not autogen... Sounds like it, not a bug then. Good to know why it happened though, and we found a bug with --disable-usbredir in the mean time :) send the ouput of autogen.sh and config.log? configure.ac should be checking for a new enough libusbredir: PKG_CHECK_MODULES(LIBUSBREDIRHOST, libusbredirhost= 0.3.2) I just checked here what happens with libusbredirhost 0.3.1: ./autogen.sh checking for LIBUSBREDIRHOST... no configure: error: Package requirements (libusbredirhost= 0.3.2) were not met: Requested 'libusbredirhost= 0.3.2' but version of libusbredirhost is 0.3.1 I wonder where can I get a RPM of 0.3.2. donno where I got the 0.3.1 one. There are packages at http://koji.fedoraproject.org/koji/packageinfo?packageID=12236 Christophe Thanks, installed, compiled and now doc warnings: DOC Building XML ../../gtk/spice-audio.c:204: warning: spice_audio_new is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/channel-main.c:1761: warning: spice_main_clipboard_grab is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/channel-main.c:1797: warning: spice_main_clipboard_release is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/channel-main.c:1838: warning: spice_main_clipboard_notify is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/channel-main.c:1878: warning: spice_main_clipboard_request is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/spice-widget.c:1864: warning: spice_display_copy_to_guest is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/spice-widget.c:1882: warning: spice_display_paste_from_guest is deprecated in the inline comments, but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) ../../gtk/display/gnome-rr.c:429: warning: Parsing comment block file : parameter expected. ../../gtk/channel-inputs.c:347: warning: Parameter description for spice_inputs_position::channel is missing in source code comment block. ../../gtk/spice-channel.c:2136: warning: Parameter description for spice_channel_connect::channel is missing in source code comment block. ../../gtk/spice-grabsequence.c:122: warning: Parameter description for spice_grab_sequence_free::sequence is missing in source code comment block. ../../gtk/channel-main.c:1878: warning: Parameter description for spice_main_clipboard_request::channel is missing in source code comment block. ../../gtk/spice-gtk-session.c:851: warning: Parameter description for spice_gtk_session_copy_to_guest::self is missing in source code comment block. ../../gtk/channel-main.c:1778: warning: Parameter description for spice_main_clipboard_selection_grab::channel is missing in source code comment block. ../../gtk/spice-widget.c:1851: warning: Parameter description for spice_display_mouse_ungrab::display is missing in source code comment block. ../../gtk/channel-main.c:1858: warning: Parameter description for spice_main_clipboard_selection_notify::channel is missing in source code comment block. ../../gtk/spice-channel.c:2361: warning: Parameter description for spice_channel_set_capability::channel is missing in source code comment block. ../../gtk/channel-main.c:1761: warning: Parameter description for spice_main_clipboard_grab::channel is missing in source code comment block. ../../gtk/spice-channel.c:2331: warning: Parameter description for spice_channel_test_common_capability::self is missing in source code comment block. ../../gtk/spice-channel.c:2331: warning: Parameter description for spice_channel_test_common_capability::cap is missing in source code
Re: [Spice-devel] [spice-xpi PATCH 1/3] logging: add logging of variable setting (#753155)
- Original Message -
Password and TrustStore are not logged.
---
SpiceXPI/src/plugin/plugin.cpp | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/SpiceXPI/src/plugin/plugin.cpp
b/SpiceXPI/src/plugin/plugin.cpp
index 2dada12..0b2ec4e 100644
--- a/SpiceXPI/src/plugin/plugin.cpp
+++ b/SpiceXPI/src/plugin/plugin.cpp
@@ -274,6 +274,7 @@ char *nsPluginInstance::GetHostIP() const
void nsPluginInstance::SetHostIP(const char *aHostIP)
{
m_host_ip = aHostIP;
+DBG(3, New HostIP m_host_ip);
}
/* attribute string port; */
@@ -285,6 +286,7 @@ char *nsPluginInstance::GetPort() const
void nsPluginInstance::SetPort(const char *aPort)
{
m_port = aPort;
+DBG(3, New Port m_port);
}
/* attribute string SecurePort; */
@@ -296,6 +298,7 @@ char *nsPluginInstance::GetSecurePort() const
void nsPluginInstance::SetSecurePort(const char *aSecurePort)
{
m_secure_port = aSecurePort;
+DBG(3, New Secure Port m_secure_port);
}
/* attribute string Password; */
@@ -307,6 +310,7 @@ char *nsPluginInstance::GetPassword() const
void nsPluginInstance::SetPassword(const char *aPassword)
{
m_password = aPassword;
+DBG(3, New Password);
Password is rarely a good thing to log, even if it's OTP.
Y.
}
/* attribute string CipherSuite; */
@@ -318,6 +322,7 @@ char *nsPluginInstance::GetCipherSuite() const
void nsPluginInstance::SetCipherSuite(const char *aCipherSuite)
{
m_cipher_suite = aCipherSuite;
+DBG(3, New CipherSuite m_cipher_suite);
}
/* attribute string SSLChannels; */
@@ -329,6 +334,7 @@ char *nsPluginInstance::GetSSLChannels() const
void nsPluginInstance::SetSSLChannels(const char *aSSLChannels)
{
m_ssl_channels = aSSLChannels;
+DBG(3, New SSL channels m_ssl_channels);
}
//* attribute string TrustStore; */
@@ -340,6 +346,7 @@ char *nsPluginInstance::GetTrustStore() const
void nsPluginInstance::SetTrustStore(const char *aTrustStore)
{
m_trust_store = aTrustStore;
+DBG(3, New TrustStore );
}
/* attribute string HostSubject; */
@@ -351,6 +358,7 @@ char *nsPluginInstance::GetHostSubject() const
void nsPluginInstance::SetHostSubject(const char *aHostSubject)
{
m_host_subject = aHostSubject;
+DBG(3, New HostSubject m_host_subject);
}
/* attribute boolean fullScreen; */
@@ -362,6 +370,7 @@ PRBool nsPluginInstance::GetFullScreen() const
void nsPluginInstance::SetFullScreen(PRBool aFullScreen)
{
m_fullscreen = aFullScreen;
+DBG(3, New FullScreen request m_fullscreen);
}
/* attribute string Title; */
@@ -373,6 +382,7 @@ char *nsPluginInstance::GetTitle() const
void nsPluginInstance::SetTitle(const char *aTitle)
{
m_title = aTitle;
+DBG(3, New Title m_title);
}
/* attribute string dynamicMenu; */
@@ -384,6 +394,7 @@ char *nsPluginInstance::GetDynamicMenu() const
void nsPluginInstance::SetDynamicMenu(const char *aDynamicMenu)
{
m_dynamic_menu = aDynamicMenu;
+DBG(3, New DynamicMenu m_dynamic_menu);
}
/* attribute string NumberOfMonitors; */
@@ -395,6 +406,7 @@ char *nsPluginInstance::GetNumberOfMonitors()
const
void nsPluginInstance::SetNumberOfMonitors(const char
*aNumberOfMonitors)
{
m_number_of_monitors = aNumberOfMonitors;
+DBG(3, New NumberOfMonitors m_number_of_monitors);
}
/* attribute boolean AdminConsole; */
@@ -406,6 +418,7 @@ PRBool nsPluginInstance::GetAdminConsole() const
void nsPluginInstance::SetAdminConsole(PRBool aAdminConsole)
{
m_admin_console = aAdminConsole;
+DBG(3, New AdminConsole m_admin_console);
}
/* attribute string GuestHostName; */
@@ -417,6 +430,7 @@ char *nsPluginInstance::GetGuestHostName() const
void nsPluginInstance::SetGuestHostName(const char *aGuestHostName)
{
m_guest_host_name = aGuestHostName;
+DBG(3, New GuestHostName m_guest_host_name);
}
/* attribute string HotKey; */
@@ -428,6 +442,7 @@ char *nsPluginInstance::GetHotKeys() const
void nsPluginInstance::SetHotKeys(const char *aHotKeys)
{
m_hot_keys = aHotKeys;
+DBG(3, New HotKeys m_hot_keys);
}
/* attribute boolean NoTaskMgrExecution; */
@@ -439,8 +454,10 @@ PRBool nsPluginInstance::GetNoTaskMgrExecution()
const
void nsPluginInstance::SetNoTaskMgrExecution(PRBool
aNoTaskMgrExecution)
{
m_no_taskmgr_execution = aNoTaskMgrExecution;
+DBG(3, New NoTaskMgrExecution m_no_taskmgr_execution);
}
+
/* attribute boolean SendCtrlAltdelete; */
PRBool nsPluginInstance::GetSendCtrlAltdelete() const
{
@@ -450,6 +467,7 @@ PRBool nsPluginInstance::GetSendCtrlAltdelete()
const
void nsPluginInstance::SetSendCtrlAltdelete(PRBool
aSendCtrlAltdelete)
{
m_send_ctrlaltdel = aSendCtrlAltdelete;
+DBG(3, New SendCtrlAltDelete m_send_ctrlaltdel);
}
/* attribute unsigned short UsbListenPort; */
@@ -674,7
Re: [Spice-devel] [spice-xpi PATCH 1/3] logging: add logging of variable setting (#753155)
- Original Message -
- Original Message -
Password and TrustStore are not logged.
---
SpiceXPI/src/plugin/plugin.cpp | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/SpiceXPI/src/plugin/plugin.cpp
b/SpiceXPI/src/plugin/plugin.cpp
index 2dada12..0b2ec4e 100644
--- a/SpiceXPI/src/plugin/plugin.cpp
+++ b/SpiceXPI/src/plugin/plugin.cpp
@@ -274,6 +274,7 @@ char *nsPluginInstance::GetHostIP() const
void nsPluginInstance::SetHostIP(const char *aHostIP)
{
m_host_ip = aHostIP;
+DBG(3, New HostIP m_host_ip);
}
/* attribute string port; */
@@ -285,6 +286,7 @@ char *nsPluginInstance::GetPort() const
void nsPluginInstance::SetPort(const char *aPort)
{
m_port = aPort;
+DBG(3, New Port m_port);
}
/* attribute string SecurePort; */
@@ -296,6 +298,7 @@ char *nsPluginInstance::GetSecurePort() const
void nsPluginInstance::SetSecurePort(const char *aSecurePort)
{
m_secure_port = aSecurePort;
+DBG(3, New Secure Port m_secure_port);
}
/* attribute string Password; */
@@ -307,6 +310,7 @@ char *nsPluginInstance::GetPassword() const
void nsPluginInstance::SetPassword(const char *aPassword)
{
m_password = aPassword;
+DBG(3, New Password);
Password is rarely a good thing to log, even if it's OTP.
Y.
Ignore,
just noticed you are not logging it, just its existence.
Y.
}
/* attribute string CipherSuite; */
@@ -318,6 +322,7 @@ char *nsPluginInstance::GetCipherSuite() const
void nsPluginInstance::SetCipherSuite(const char *aCipherSuite)
{
m_cipher_suite = aCipherSuite;
+DBG(3, New CipherSuite m_cipher_suite);
}
/* attribute string SSLChannels; */
@@ -329,6 +334,7 @@ char *nsPluginInstance::GetSSLChannels() const
void nsPluginInstance::SetSSLChannels(const char *aSSLChannels)
{
m_ssl_channels = aSSLChannels;
+DBG(3, New SSL channels m_ssl_channels);
}
//* attribute string TrustStore; */
@@ -340,6 +346,7 @@ char *nsPluginInstance::GetTrustStore() const
void nsPluginInstance::SetTrustStore(const char *aTrustStore)
{
m_trust_store = aTrustStore;
+DBG(3, New TrustStore );
}
/* attribute string HostSubject; */
@@ -351,6 +358,7 @@ char *nsPluginInstance::GetHostSubject() const
void nsPluginInstance::SetHostSubject(const char *aHostSubject)
{
m_host_subject = aHostSubject;
+DBG(3, New HostSubject m_host_subject);
}
/* attribute boolean fullScreen; */
@@ -362,6 +370,7 @@ PRBool nsPluginInstance::GetFullScreen() const
void nsPluginInstance::SetFullScreen(PRBool aFullScreen)
{
m_fullscreen = aFullScreen;
+DBG(3, New FullScreen request m_fullscreen);
}
/* attribute string Title; */
@@ -373,6 +382,7 @@ char *nsPluginInstance::GetTitle() const
void nsPluginInstance::SetTitle(const char *aTitle)
{
m_title = aTitle;
+DBG(3, New Title m_title);
}
/* attribute string dynamicMenu; */
@@ -384,6 +394,7 @@ char *nsPluginInstance::GetDynamicMenu() const
void nsPluginInstance::SetDynamicMenu(const char *aDynamicMenu)
{
m_dynamic_menu = aDynamicMenu;
+DBG(3, New DynamicMenu m_dynamic_menu);
}
/* attribute string NumberOfMonitors; */
@@ -395,6 +406,7 @@ char *nsPluginInstance::GetNumberOfMonitors()
const
void nsPluginInstance::SetNumberOfMonitors(const char
*aNumberOfMonitors)
{
m_number_of_monitors = aNumberOfMonitors;
+DBG(3, New NumberOfMonitors m_number_of_monitors);
}
/* attribute boolean AdminConsole; */
@@ -406,6 +418,7 @@ PRBool nsPluginInstance::GetAdminConsole()
const
void nsPluginInstance::SetAdminConsole(PRBool aAdminConsole)
{
m_admin_console = aAdminConsole;
+DBG(3, New AdminConsole m_admin_console);
}
/* attribute string GuestHostName; */
@@ -417,6 +430,7 @@ char *nsPluginInstance::GetGuestHostName()
const
void nsPluginInstance::SetGuestHostName(const char
*aGuestHostName)
{
m_guest_host_name = aGuestHostName;
+DBG(3, New GuestHostName m_guest_host_name);
}
/* attribute string HotKey; */
@@ -428,6 +442,7 @@ char *nsPluginInstance::GetHotKeys() const
void nsPluginInstance::SetHotKeys(const char *aHotKeys)
{
m_hot_keys = aHotKeys;
+DBG(3, New HotKeys m_hot_keys);
}
/* attribute boolean NoTaskMgrExecution; */
@@ -439,8 +454,10 @@ PRBool
nsPluginInstance::GetNoTaskMgrExecution()
const
void nsPluginInstance::SetNoTaskMgrExecution(PRBool
aNoTaskMgrExecution)
{
m_no_taskmgr_execution = aNoTaskMgrExecution;
+DBG(3, New NoTaskMgrExecution m_no_taskmgr_execution);
}
+
/* attribute boolean SendCtrlAltdelete; */
PRBool nsPluginInstance::GetSendCtrlAltdelete() const
{
@@ -450,6 +467,7 @@ PRBool
Re: [Spice-devel] [PATCH spice-protocol 1/2] Add support for a header without sub list.
On 12/29/2011 10:30 AM, Alon Levy wrote:
On Thu, Dec 29, 2011 at 08:11:27AM +0200, Yonit Halperin wrote:
On 12/28/2011 10:04 PM, Yaniv Kaul wrote:
On 12/28/2011 07:14 PM, Yonit Halperin wrote:
Add SpiceDataHeaderNoSub.
Introduce capability SPICE_COMMON_CAP_HEADER_NO_SUB.
Introduce SPICE_MSG_LIST: the msg body is SpiceSubMessageList.
The advantage of using a header without sub list is to spare the 4
bytes that were sent
for a lot of messages without sublist.
Instead, messages that previously contained sub lists, will be split
to two msgs.
The first one will be SPICE_MSG_LIST, holding the sub list, and the
second will be the
main msg.
When most of the messages do not contain sub lists, the overhead of
the additional 10 bytes
for the header of SPICE_MSG_LIST is negligible.
---
spice/enums.h | 1 +
spice/protocol.h | 9 -
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/spice/enums.h b/spice/enums.h
index a587b00..0314f0b 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -344,6 +344,7 @@ enum {
SPICE_MSG_WAIT_FOR_CHANNELS,
SPICE_MSG_DISCONNECTING,
SPICE_MSG_NOTIFY,
+ SPICE_MSG_LIST,
};
enum {
diff --git a/spice/protocol.h b/spice/protocol.h
index ddfe84b..cbd8295 100644
--- a/spice/protocol.h
+++ b/spice/protocol.h
@@ -37,7 +37,7 @@
#define SPICE_MAGIC (*(uint32_t*)REDQ)
#define SPICE_VERSION_MAJOR 2
-#define SPICE_VERSION_MINOR 1
+#define SPICE_VERSION_MINOR 2
if you are bumping the protocol version, why negotiate the capability?
Isn't it implicit (if I can do 2.2 or above, I will omit the sublist) ?
Conversely, if you do have the capability exchange, why bump the version?
// Encryption Ticketing Parameters
#define SPICE_MAX_PASSWORD_LENGTH 60
@@ -55,6 +55,7 @@ enum {
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION,
SPICE_COMMON_CAP_AUTH_SPICE,
SPICE_COMMON_CAP_AUTH_SASL,
+ SPICE_COMMON_CAP_HEADER_NO_SUB,
};
typedef struct SPICE_ATTR_PACKED SpiceLinkMess {
@@ -89,6 +90,12 @@ typedef struct SPICE_ATTR_PACKED SpiceDataHeader {
uint32_t sub_list; //offset to SpiceSubMessageList[]
} SpiceDataHeader;
+typedef struct SPICE_ATTR_PACKED SpiceDataHeaderNoSub {
+ uint64_t serial;
Ah, if you could also get rid of the serial in the same sweep... More
useless bytes.
At least for some channels, it's completely useless. I suspect some do
use it, for no real reason, though.
They are used for real reason. For example, keeping the bitmaps
cache consistent, when the guest have several monitors. It was also
used in other channels for seamless migration, and we hope to have
seamless migration back in the future. It is not used for messages
from the client to the server. Even if we want to remove it, it will
require different patches then those in this series.
We did discuss reducing the field from 64 bit to 32 bit. Also, since we
are using TCP transport they are redundant, no? each side can deduce the
serial based on 1) it starts from 0 (or the starting one can be sent in
the link message if it isn't zero, i.e. migration) 2) it increments by 1
per message.
Yes, TCP made them redundant, which means it doesn't matter if they are
32 or 64bit, they should not be sent.
Totally agree about it belonging to a seperate patchset. Kaul, hold your
horses :)
OK.
Y.
+ uint16_t type;
+ uint32_t size;
+} SpiceDataHeaderNoSub;
+
typedef struct SPICE_ATTR_PACKED SpiceSubMessage {
uint16_t type;
uint32_t size;
___
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 spice-protocol 1/2] Add support for a header without sub list.
On 12/28/2011 07:14 PM, Yonit Halperin wrote:
Add SpiceDataHeaderNoSub.
Introduce capability SPICE_COMMON_CAP_HEADER_NO_SUB.
Introduce SPICE_MSG_LIST: the msg body is SpiceSubMessageList.
The advantage of using a header without sub list is to spare the 4 bytes that
were sent
for a lot of messages without sublist.
Instead, messages that previously contained sub lists, will be split to two
msgs.
The first one will be SPICE_MSG_LIST, holding the sub list, and the second will
be the
main msg.
When most of the messages do not contain sub lists, the overhead of the
additional 10 bytes
for the header of SPICE_MSG_LIST is negligible.
---
spice/enums.h|1 +
spice/protocol.h |9 -
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/spice/enums.h b/spice/enums.h
index a587b00..0314f0b 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -344,6 +344,7 @@ enum {
SPICE_MSG_WAIT_FOR_CHANNELS,
SPICE_MSG_DISCONNECTING,
SPICE_MSG_NOTIFY,
+SPICE_MSG_LIST,
};
enum {
diff --git a/spice/protocol.h b/spice/protocol.h
index ddfe84b..cbd8295 100644
--- a/spice/protocol.h
+++ b/spice/protocol.h
@@ -37,7 +37,7 @@
#define SPICE_MAGIC (*(uint32_t*)REDQ)
#define SPICE_VERSION_MAJOR 2
-#define SPICE_VERSION_MINOR 1
+#define SPICE_VERSION_MINOR 2
if you are bumping the protocol version, why negotiate the capability?
Isn't it implicit (if I can do 2.2 or above, I will omit the sublist) ?
Conversely, if you do have the capability exchange, why bump the version?
// Encryption Ticketing Parameters
#define SPICE_MAX_PASSWORD_LENGTH 60
@@ -55,6 +55,7 @@ enum {
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION,
SPICE_COMMON_CAP_AUTH_SPICE,
SPICE_COMMON_CAP_AUTH_SASL,
+SPICE_COMMON_CAP_HEADER_NO_SUB,
};
typedef struct SPICE_ATTR_PACKED SpiceLinkMess {
@@ -89,6 +90,12 @@ typedef struct SPICE_ATTR_PACKED SpiceDataHeader {
uint32_t sub_list; //offset to SpiceSubMessageList[]
} SpiceDataHeader;
+typedef struct SPICE_ATTR_PACKED SpiceDataHeaderNoSub {
+uint64_t serial;
Ah, if you could also get rid of the serial in the same sweep... More
useless bytes.
At least for some channels, it's completely useless. I suspect some do
use it, for no real reason, though.
Y.
+uint16_t type;
+uint32_t size;
+} SpiceDataHeaderNoSub;
+
typedef struct SPICE_ATTR_PACKED SpiceSubMessage {
uint16_t type;
uint32_t size;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol 1/2] Add support for a header without sub list.
On 12/29/2011 08:11 AM, Yonit Halperin wrote:
On 12/28/2011 10:04 PM, Yaniv Kaul wrote:
On 12/28/2011 07:14 PM, Yonit Halperin wrote:
Add SpiceDataHeaderNoSub.
Introduce capability SPICE_COMMON_CAP_HEADER_NO_SUB.
Introduce SPICE_MSG_LIST: the msg body is SpiceSubMessageList.
The advantage of using a header without sub list is to spare the 4
bytes that were sent
for a lot of messages without sublist.
Instead, messages that previously contained sub lists, will be split
to two msgs.
The first one will be SPICE_MSG_LIST, holding the sub list, and the
second will be the
main msg.
When most of the messages do not contain sub lists, the overhead of
the additional 10 bytes
for the header of SPICE_MSG_LIST is negligible.
---
spice/enums.h | 1 +
spice/protocol.h | 9 -
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/spice/enums.h b/spice/enums.h
index a587b00..0314f0b 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -344,6 +344,7 @@ enum {
SPICE_MSG_WAIT_FOR_CHANNELS,
SPICE_MSG_DISCONNECTING,
SPICE_MSG_NOTIFY,
+ SPICE_MSG_LIST,
};
enum {
diff --git a/spice/protocol.h b/spice/protocol.h
index ddfe84b..cbd8295 100644
--- a/spice/protocol.h
+++ b/spice/protocol.h
@@ -37,7 +37,7 @@
#define SPICE_MAGIC (*(uint32_t*)REDQ)
#define SPICE_VERSION_MAJOR 2
-#define SPICE_VERSION_MINOR 1
+#define SPICE_VERSION_MINOR 2
if you are bumping the protocol version, why negotiate the capability?
Isn't it implicit (if I can do 2.2 or above, I will omit the sublist) ?
Conversely, if you do have the capability exchange, why bump the
version?
// Encryption Ticketing Parameters
#define SPICE_MAX_PASSWORD_LENGTH 60
@@ -55,6 +55,7 @@ enum {
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION,
SPICE_COMMON_CAP_AUTH_SPICE,
SPICE_COMMON_CAP_AUTH_SASL,
+ SPICE_COMMON_CAP_HEADER_NO_SUB,
};
typedef struct SPICE_ATTR_PACKED SpiceLinkMess {
@@ -89,6 +90,12 @@ typedef struct SPICE_ATTR_PACKED SpiceDataHeader {
uint32_t sub_list; //offset to SpiceSubMessageList[]
} SpiceDataHeader;
+typedef struct SPICE_ATTR_PACKED SpiceDataHeaderNoSub {
+ uint64_t serial;
Ah, if you could also get rid of the serial in the same sweep... More
useless bytes.
At least for some channels, it's completely useless. I suspect some do
use it, for no real reason, though.
They are used for real reason. For example, keeping the bitmaps cache
consistent, when the guest have several monitors. It was also used in
other channels for seamless migration, and we hope to have seamless
migration back in the future. It is not used for messages from the
client to the server. Even if we want to remove it, it will require
different patches then those in this series.
I'm not suggesting eliminating the IDs, but I see little value in
sending them for every message. If there are specific features which
require them (I was not aware that they are needed for seamless
migration), send them as part of the migration protocol.
Y.
Y.
+ uint16_t type;
+ uint32_t size;
+} SpiceDataHeaderNoSub;
+
typedef struct SPICE_ATTR_PACKED SpiceSubMessage {
uint16_t type;
uint32_t size;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Failure to compile xf86-video-qxl (SPICE_BITMAP_FMT_8BIT_A' undeclared)
On 12/18/2011 05:37 PM, Alon Levy wrote: On Sat, Dec 17, 2011 at 08:54:48PM +0200, Yaniv Kaul wrote: make[3]: Entering directory `/home/ykaul/xf86-video-qxl/src' CC qxl_driver.lo CC qxl_image.lo qxl_image.c: In function 'qxl_image_create': qxl_image.c:215:29: error: 'SPICE_BITMAP_FMT_8BIT_A' undeclared (first use in this function) Looks like spice-protocol needs updating. Soren, can you send the missing patch to the list? Especially with the multiple git repos you have (at least 5 that I'm aware of), you should really set up a build-bot. Not to mention the branches. Y. F16/x64, fully updated. Probably related to: commit 8ea466a2f408524a9fcc08ed0a17f3c935857afa Author: Søren Sandmanns...@redhat.com Date: Tue Dec 13 03:51:35 2011 -0500 Use new 8BIT_A format for 8 bit pixmaps. ___ 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] Failure to compile xf86-video-qxl (SPICE_BITMAP_FMT_8BIT_A' undeclared)
make[3]: Entering directory `/home/ykaul/xf86-video-qxl/src' CC qxl_driver.lo CC qxl_image.lo qxl_image.c: In function 'qxl_image_create': qxl_image.c:215:29: error: 'SPICE_BITMAP_FMT_8BIT_A' undeclared (first use in this function) F16/x64, fully updated. Probably related to: commit 8ea466a2f408524a9fcc08ed0a17f3c935857afa Author: Søren Sandmann s...@redhat.com Date: Tue Dec 13 03:51:35 2011 -0500 Use new 8BIT_A format for 8 bit pixmaps. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] vala is now needed?
On 12/10/2011 05:05 PM, Hans de Goede wrote: Hi, On 12/09/2011 09:56 PM, Yaniv Kaul wrote: 1. Too bad there is no proper check for vala when running ./configure (or ./autogen.sh). 2. I've have vala installed and installed vala-devel, ./configure passes, yet with 'make' I'm getting: make[4]: Entering directory `/home/ykaul/spice-gtk/gtk/controller' *** Error: missing valac! *** You must run autogen.sh or configure --enable-vala I must be missing something. We are using vala for the controller code, so yes to build *from git* vala is needed, since vala uses a pre-compiler compiling vala code to plain c, and we're shippin the generated c code in our tarbals, vala won't be needed for building release tarbals. What has happened in your case is that you've like been building from git for a while, but did a ./configure or ./autogen.sh since your first checkout, and since the vala code has changed in git recently, and you did not run /configure with --enable-vala, the build is now failing. Re-run ./configure with --enable-vala to make it figure out where to find all the vala bits it needs to regenerate the C files generated from the vala files, after that it should build fine. --enable-vala was not enough - I had to install vala-tools (which is not mentioned anywhere, as far as I could tell). Running ./configure without vala-tools installed should have failed, if it's required. Y. I hope this helps. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] vala is now needed?
1. Too bad there is no proper check for vala when running ./configure (or ./autogen.sh). 2. I've have vala installed and installed vala-devel, ./configure passes, yet with 'make' I'm getting: make[4]: Entering directory `/home/ykaul/spice-gtk/gtk/controller' *** Error: missing valac! *** You must run autogen.sh or configure --enable-vala I must be missing something. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice required ports
On 12/01/2011 07:39 PM, Alon Levy wrote: On Thu, Dec 01, 2011 at 11:01:39AM -0500, Richard Mann wrote: Just joined. Not sure where to ask this question. It relates to security and opening ports on a firewall through which the Spice clients and server would communicate. I would like to know how many ports will need to be opened on a firewall to support the 6 communications channels between the Spice clients and server. Excerpt from Spice for Newbies PDF. 2.3.2.1 Channels The client and server communicate via channels. Each channel type is dedicated to a specific type of data. Each channel uses a dedicated TCP socket.. The available channels are: o Main - implemented by RedClient (see above). o DisplayChannel - handles graphic commands, images and video streams. o InputsChannel - keyboard and mouse inputs. o CursorChannel - pointer device position, visibility and cursor shape. o PlaybackChannel - audio received from the server to be played by the client . o RecordChannel - audio captured on the client side. After looking at the Spice PDFs it appears to me that 6 ports would need to be opened although the default Spice server port appears to be 5930 (just one port and not six). I would like to know how many ports are required (listening) on the Spice server to handle all 6 channels (TCP sockets)? I am assuming each channel (TCP socket) requires its own port on the Spice server. Thanks, Rich The docs are correct - it is a single port, opened six times. The same way that firefox/$BROWSER opens multiple connections to a single server Broswers do this to speed up downloading of multiple images / css etc., but the same idea - single port 80 but multiple connections aka sockets. The word missing is 'destination'. There is a single destination port, with 6 different connections performed against it. And re. HTTP's multiple connections, I'd look at http://www.chromium.org/spdy (do we need/want multiple display channel connections?) Y. To be exact it can be two ports if you use both a ssl and a non ssl port, i.e. qemu -spice port=port,tls-port=tls-port ___ 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 vdagent-win 3/3] vdlog: change log times to human readable date time rhbz#672828
On 11/16/2011 02:46 PM, David Jaša wrote: Arnon Gilboa píše v St 16. 11. 2011 v 14:20 +0200: Alon Levy wrote: On Wed, Nov 16, 2011 at 12:16:37PM +0200, Arnon Gilboa wrote: ifndef USE_DATE_TIME, use system time instead of secs from system startup Why do we want to keep the old behavior? For users qa, human readable date time (hh:mm:ss) is nicer. For debugging, having finer resolution (millisec) sometime helps. Sounds reasonable? FTR, RHEV logs use format like this: thread id::log level::2011-11-16 13:43:40,205::actual log message IMO, such time format is suitable for both needs (and given the verbosity of logs with DEBUG levels, they would be unreadable without ms precision). David And being consistent somehow with oVirt/VDSM logs would allow parsing them in the same engine(s), for example. Very useful for troubleshooting and debugging. Y. ___ 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] [master PATCH 2/2] server: netstat: send random data not zeros
On 10/19/2011 01:42 PM, Frédéric Grelot wrote: That seems like a good idea. Note that if the first image is not compressed, we may have a similar problem with WAN accelerators. Also maybe it is better to always compress it. This random buffer was intended as a quick fix. In the long run, we would like to measure network statistics dynamically, e.g. when sending large images (as you suggested for the first one). That may be overkill, but you could also scramble it by xoring it with a randomly generated sequence (and send the seed to the client to allow him to reproduce the sequence). The only overhead would thus be the seed. By the way, that could be applied to any message, not necessarily the first image. Frederic. Why should we do that? If we don't compress images well enough, and a WAN accelerator (or even if the channel is within SSL with compression enabled), let them reduce the bandwidth for us. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [master PATCH 1/2] server: netstat: modify network bandwidth calculation
On 18/10/2011 19:20, Uri Lublin wrote: Currently spice-server network bandwidth estimation is: send an empty ping packet to the client (and ignore it) (warmup) Useless. 'warmup' of what exactly? The TCP MSS and everything else is already set by the TCP handshake and the RED initial connection packets. send an empty ping packet and calculate time till pong is received (latency) And now this can be dropped as well, if it's now used, right? Y. send a ping packet with data (256KB) and calculate time till pong (roundtrip) bandwidth = datasize / (roundtip - latency) Many times (e.g. fast LAN), (roundtrip - latency) is very small. This results with a falsely very high bandwidth. This patch makes the bandwidth calculation be bandwidth = datasize / roundtrip Suggested by Marc-André Lureaumarcandre.lur...@redhat.com --- server/main_channel.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/server/main_channel.c b/server/main_channel.c index 43c0f3f..a4db724 100644 --- a/server/main_channel.c +++ b/server/main_channel.c @@ -812,7 +812,7 @@ static int main_channel_handle_parsed(RedChannelClient *rcc, uint32_t size, uint break; } mcc-bitrate_per_sec = (uint64_t)(NET_TEST_BYTES * 8) * 100 -/ (roundtrip - mcc-latency); +/ roundtrip; red_printf(net test: latency %f ms, bitrate %lu bps (%f Mbps)%s, (double)mcc-latency / 1000, mcc-bitrate_per_sec, ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Question on fill_mask() (server/red_worker.c)
Unless I'm misreading the code (which may very well be), the function
looks like:
if (mask_bitmap m) {
if (this or that) {
do X
fill_bits(...)
} else {
fill_bits(...)
}
}
So essentially, if the condition (mask_bitmap m) is NOT met, we do
not fill the bits. Which means we are sending garbage over the wire?
Y.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Question on fill_mask() (server/red_worker.c)
On 10/04/2011 01:00 PM, Alon Levy wrote:
On Tue, Oct 04, 2011 at 12:40:21PM +0200, Yaniv Kaul wrote:
Unless I'm misreading the code (which may very well be), the
function looks like:
if (mask_bitmap m) {
if (this or that) {
do X
fill_bits(...)
} else {
fill_bits(...)
}
}
So essentially, if the condition (mask_bitmap m) is NOT met, we
do not fill the bits. Which means we are sending garbage over the
wire?
I read it the same. Can you add the else and see if it gets there? (or
figure that out by just reading the code)
diff --git a/server/red_worker.c b/server/red_worker.c
index 7af715d..5bd3a92 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -6415,6 +6415,8 @@ static void fill_mask(RedChannelClient *rcc,
SpiceMarshaller *m,
} else {
fill_bits(dcc, m, mask_bitmap, drawable, FALSE);
}
+} else {
+ red_printf(fill_mask not doing much);
}
}
...
reds_handle_read_link_done: Peer doesn't support AUTH selection
reds_show_new_channel: channel 3:0, connected successfully, over Non
Secure link
inputs_connect: inputs channel client create
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
display_channel_release_item: not pushed (101)
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
fill_mask: fill_mask not doing much
...
Y.
Y.
___
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] Question on fill_mask() (server/red_worker.c)
On 10/04/2011 01:25 PM, Yonit Halperin wrote:
On 10/04/2011 01:20 PM, Alon Levy wrote:
On Tue, Oct 04, 2011 at 01:00:47PM +0200, Alon Levy wrote:
On Tue, Oct 04, 2011 at 12:40:21PM +0200, Yaniv Kaul wrote:
Unless I'm misreading the code (which may very well be), the
function looks like:
if (mask_bitmap m) {
if (this or that) {
do X
fill_bits(...)
} else {
fill_bits(...)
}
}
So essentially, if the condition (mask_bitmap m) is NOT met, we
do not fill the bits. Which means we are sending garbage over the
wire?
I read it the same. Can you add the else and see if it gets there? (or
figure that out by just reading the code)
Actually, m should be always non NULL (since it is set unconditionally
by spice_marshall_Fill for instance - didn't check the others though)
and I
think a marshaller that doesn't get filled will just produce 0 bytes
of output.
There is no problem with the mask being null. As I recall, we just
don't send a mask.
That would have been nice - but how do you tell the client that you did
not send a mask? From network captures looks like a mask is being sent,
with garbage in the flag and the point fields and the bitmap being all
zero'ed (this is what got us to this in the first place). Essentially a
waste of 12 bytes, if you could signal the client that no need for a
mask to be sent.
Y.
Y.
___
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
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Spice protocol dissector in Wireshark trunk
My Spice protocol dissector has just been accepted into Wireshark and is available in trunk. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice protocol dissector in Wireshark trunk
On 30/09/2011 21:02, Christophe Fergeau wrote: On Fri, Sep 30, 2011 at 06:53:45PM +0300, Yaniv Kaul wrote: My Spice protocol dissector has just been accepted into Wireshark and is available in trunk. Great news! Congratulations! Do you have an idea when the next release of wireshark will be out? Is it a matter of weeks, months, no ETA? If the release is too far away, we could add the fedora maintainer of the wireshark package if he wants to add the dissector as a patch for now. Good job :) Christophe I'm not sure what the schedule is, but I reckon weeks - months. There seems to be a release every other month or so (or when enough people ask for the next release). There's no schedule. SVN automated builds are already 1.7.0 (and there are compelling features to get it released, such as capture from multiple interfaces, GTK3 support, etc.) Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] About QoS and/or Timing profiling
On 09/28/2011 01:05 AM, Antonio Perez-Aranda wrote: HI all, I recently started a project to give service about 400 concurrent desktops but customer ask me for timing profiling tests. I have set TLS (it's a requeriment), and I could have intranet and extranet sniffers. So, Can I measure the delay of events in user desktop with spicy? Can I mark packages like mouse or keyboard events with any QoS special ID ? Since you are encapsulating it in TLS, probably not (the marking would not pass to the external encapsulation). Without it, it should be easy to see them in a sniffer. Y. Thanks for your work, it's amazing. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE protocol - UDP or TCP?
On 09/15/2011 04:36 AM, Jose Ruelas (josruela) wrote: hello My name is Jose Ruelas, from Cisco (LATAM) we have a customer that is considering to use RHEV for Desktops, and the SPICE protocol came to discussion table one question is still on air, about how SPICE protocol travels over the Network; does it encapsulates with UDP? or TCP? (for example we know RDP goes through UDP) Spice is using multiple TCP connections. Some may be SSL encrypted (which is also over TCP). RDP is also TCP based, btw. Y. hope you could help us with this question my best regards Jose Ruelas Cisco Systems +5255 5267 1873 ___ 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] WinQXL: PREfast analysis errors and warnings
Has anyone looked at the warning and errors PREfast (from MS DDK) produces? - driver.c(111): usage of _snprintf banned API - driver.c(112): usage of _vsnprintf banned API - driver.c(387): 'video_buff' could be '0' and is a copy of the value found in 'selected_mode'. See line 358 for an earlier location where this can occur. This does not adhere to the specification for the function 'EngFreeMem'. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] WinQXL: PREfast analysis errors and warnings
On 09/01/2011 03:07 PM, nicolas prochazka wrote: Hello, I just compile winqxl from git tree without error or warning I use 7600.16385.1 winDDK Regards, Nicolas It's from the Auto Code Review, which is part of the DDK. I'm not getting errors as part of the compilation. It's in a balloon in the tray bar. Y. 2011/9/1 Yaniv Kaul yk...@redhat.com mailto:yk...@redhat.com Has anyone looked at the warning and errors PREfast (from MS DDK) produces? - driver.c(111): usage of _snprintf banned API - driver.c(112): usage of _vsnprintf banned API - driver.c(387): 'video_buff' could be '0' and is a copy of the value found in 'selected_mode'. See line 358 for an earlier location where this can occur. This does not adhere to the specification for the function 'EngFreeMem'. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto: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] [typo] NASKE - MASK (WinQXL)
For WinQXL:
diff --git a/display/qxldd.h b/display/qxldd.h
index 9b613c1..7ee8896 100644
--- a/display/qxldd.h
+++ b/display/qxldd.h
@@ -89,11 +89,11 @@ typedef struct Ring {
#define CURSOR_CACHE_SIZE (1 6)
#define CURSOR_HASH_SIZE (CURSOR_CACHE_SIZE 1)
-#define CURSOR_HASH_NASKE (CURSOR_HASH_SIZE - 1)
+#define CURSOR_HASH_MASK (CURSOR_HASH_SIZE - 1)
#define PALETTE_CACHE_SIZE (1 6)
#define PALETTE_HASH_SIZE (PALETTE_CACHE_SIZE 1)
-#define PALETTE_HASH_NASKE (PALETTE_HASH_SIZE - 1)
+#define PALETTE_HASH_MASK (PALETTE_HASH_SIZE - 1)
//#define CALL_TEST
diff --git a/display/res.c b/display/res.c
index 5d28184..2dd7d3f 100644
--- a/display/res.c
+++ b/display/res.c
@@ -1581,7 +1581,7 @@ typedef struct InternalPalette {
QXLPalette palette;
} InternalPalette;
-#define PALETTE_HASH_VAL(unique) ((int)(unique) PALETTE_HASH_NASKE)
+#define PALETTE_HASH_VAL(unique) ((int)(unique) PALETTE_HASH_MASK)
static _inline void ReleasePalette(PDev *pdev, InternalPalette *palette)
{
@@ -2935,7 +2935,7 @@ typedef struct InternalCursor {
} InternalCursor;
-#define CURSOR_HASH_VAL(hsurf) (HSURF_HASH_VAL(hsurf) CURSOR_HASH_NASKE)
+#define CURSOR_HASH_VAL(hsurf) (HSURF_HASH_VAL(hsurf) CURSOR_HASH_MASK)
/* Called with cursor_cache_sem held */
static void CursorCacheRemove(PDev *pdev, InternalCursor *cursor)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Question about Spice and Display Channel
On 03/08/2011 21:33, Andrea Celestino wrote: Hi, I want to try to implements a new channel dedicated to streaming video. It's only an experiment, I don't know if this can bring an improvement. I would like to know some guidelines for implementing this channel. In spice every channel is a different socket and on the client side is a different thread. What I need to do is to create this new socket, and every time a video stream is detected I will send the data in this new channel instead of display channel. Is there something I need to take into account with this work? Any suggestions are accepted. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel Use some keep alive so the TCP connection won't die when you need it. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/2] server: init all fields on SpiceMsgDisplayStreamCreate
On 08/02/2011 01:54 PM, Alon Levy wrote: On Tue, Aug 02, 2011 at 12:31:57PM +0200, Christophe Fergeau wrote: This patch is an RFC red_display_marshall_stream_start initializes a SpiceMsgDisplayStreamCreate structure before marshalling it and sending it on the wire. However, it never fills SpiceMsgDisplayStreamCreate::stamp which then causes a complaint from valgrind. Initializing it is easy enough, however I have no idea if 0 is an acceptable value. I put a semi-random value for now in the hope that someone can enlighten me as to what I can use for ::stamp. --- server/red_worker.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/server/red_worker.c b/server/red_worker.c index efedc19..dc80259 100644 --- a/server/red_worker.c +++ b/server/red_worker.c @@ -7718,6 +7718,8 @@ static void red_display_marshall_stream_start(DisplayChannel *display_channel, stream_create.clip.rects =clip_rects; } +stream_create.stamp = 0xdeadbeef; + Good question. I see mm_time is 32 bit, and this is 64. You could pass the mm_time here. Is it even used on the other side? I think we only use the timestamps on the frames for synchronization. 0 is still a better value in the meantime :) On the wire it looked like zero'ed 8 bytes in STREAM_CREATE, while the very next STREAM_DATA message had 4 bytes with reasonable data (0x0017940e, which indeed incremented nicely in the next STREAM_DATA messages). Coincidence? (Using git 3582adb989cdb6e1e75bf9341ffcebf35e58b737). BTW: another 8 bytes we could shave off the protocol one day, I presume. Y. spice_marshall_msg_display_stream_create(base_marshaller,stream_create); } -- 1.7.6 ___ 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] Spice Windows 7 display driver?
On 02/08/2011 16:25, Nathan Lager wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not sure what went wrong last time, but this time I was able to get the driver signed with a Test Cert. Followed the instructions for enabling test signing, and attempted to install the driver. It presents me with the same error. It displays the driver name, Red Hat QXL GPU, and the following error: The driver selected for this device does not support this version of Windows. I built the driver ON the same vm i'm attempting to install it on. This doesn't make much sense... This is irrelevant. You can build on one environment for another. Are you sure the build environment you launch is the correct one? The first example in http://spice-space.org/page/WinQXL is for XP/32: C:\WINDOWS\system32\cmd.exe /k C:\WinDDK\7600.16385.0\bin\setenv.bat C:\WinDDK\7600.16385.0\ chk x86 WXP Look at the resulting INF file and verify it's good for your OS. Y. Windows tells me it's build 7601. On 08/02/2011 03:55 AM, Mario wrote: Nathan, did you take a look on this: http://spice-space.org/page/WinQXL Windows will install the default driver if there is no better available. You can verify you are having the qxl device by checking the PCI IDs in your Device Manager. Cheers, Mario On Mon, 01 Aug 2011 15:56:20 -0400, Nathan Lager wrote: I've been running in circles attempting to install a Display driver in Windows 7 x64 for use with Spice. My host is CentOS6 x64, My guest is Windows 7 x64. Spice is enabled, as is -vga qxl, Windows see's the display adapter as standard vga graphics adapter. Where can i get the drivers for RedHad Spice? Thanks. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nathan Lager System Administrator 11 Pardee Hall Lafayette College, Easton, PA 18042 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk43+swACgkQsZqG4IN3sulkqwCfbnNCTupTfxxNfKEzMnZfdNGC uAoAnjoH9UGMWvqDKf2bo0rPVdOBCpSw =W3yw -END PGP SIGNATURE- ___ 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] Spice Windows 7 display driver?
On 02/08/2011 16:49, Nathan Lager wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I used the x64 free build environment link that wdk added to my start menu. The inf seems to have provisions for xp 32 and 64, and vista 32 and 64. Should there be one specifically for 7? No, you should have in the INF file something like: NTamd64.6.0 under the [Manufacturer] subection of the INF file, as well as a subsection called '[NTamd64.6.0]' You could also look at the qxl.cat file, perhaps it's not signed correctly? Should be according to this table: * 2.5.0 = Windows 2000 * 2:5.1 = Windows XP * 2:5.2 = Windows Server 2003 * 2:6.0 = Windows Vista and Windows Server 2008 * 2:6.1 = Windows 7 and Windows 2008 R2 x64 HTH, Y. On 08/02/2011 09:41 AM, Yaniv Kaul wrote: On 02/08/2011 16:25, Nathan Lager wrote: I'm not sure what went wrong last time, but this time I was able to get the driver signed with a Test Cert. Followed the instructions for enabling test signing, and attempted to install the driver. It presents me with the same error. It displays the driver name, Red Hat QXL GPU, and the following error: The driver selected for this device does not support this version of Windows. I built the driver ON the same vm i'm attempting to install it on. This doesn't make much sense... This is irrelevant. You can build on one environment for another. Are you sure the build environment you launch is the correct one? The first example in http://spice-space.org/page/WinQXL is for XP/32: C:\WINDOWS\system32\cmd.exe /k C:\WinDDK\7600.16385.0\bin\setenv.bat C:\WinDDK\7600.16385.0\ chk x86 WXP Look at the resulting INF file and verify it's good for your OS. Y. Windows tells me it's build 7601. On 08/02/2011 03:55 AM, Mario wrote: Nathan, did you take a look on this: http://spice-space.org/page/WinQXL Windows will install the default driver if there is no better available. You can verify you are having the qxl device by checking the PCI IDs in your Device Manager. Cheers, Mario On Mon, 01 Aug 2011 15:56:20 -0400, Nathan Lager wrote: I've been running in circles attempting to install a Display driver in Windows 7 x64 for use with Spice. My host is CentOS6 x64, My guest is Windows 7 x64. Spice is enabled, as is -vga qxl, Windows see's the display adapter as standard vga graphics adapter. Where can i get the drivers for RedHad Spice? Thanks. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nathan Lager System Administrator 11 Pardee Hall Lafayette College, Easton, PA 18042 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk44AHkACgkQsZqG4IN3sumEOACeMPE3JkuSA11H8TGj4cProjRG qtgAn3ZJ5SLM9bjY+kHe11mNsFUmcq0R =yjf+ -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Failure to ./configure QXL (under F15/x64 VM, already running QXL driver)
I'm trying to move QXL driver to compile under the VM it will run on. ./configure fails with: /./configure: line 11867: syntax error near unexpected token `RANDR,' //./configure: line 11867: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)' / Sounds like http://nouveau.freedesktop.org/wiki/TroubleShooting#SyntaxerrornearunexpectedtokenRANDR (and indeed, 'sudo yum install xorg-x11-server-sdk' solves it). Perhaps worth checking better in the script. TIA, Y. / / ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] patch (RFC) - remove redundant calls to EngAcquireSemaphore/EngReleaseSemaphore in Windows' QXL display/res.c
As correctly documented before the function, it is only called when the
semaphore is held, therefore no need to acquire nor release it:
diff --git a/display/res.c b/display/res.c
index 5d28184..df0ddba 100644
--- a/display/res.c
+++ b/display/res.c
@@ -1510,12 +1510,10 @@ static void ImageCacheAdd(PDev *pdev, CacheImage
*cache_image)
{
int key;
-EngAcquireSemaphore(pdev-Res-image_cache_sem);
key = IMAGE_HASH_VAL(cache_image-key);
cache_image-next = pdev-Res-image_cache[key];
cache_image-hits = 1;
pdev-Res-image_cache[key] = cache_image;
-EngReleaseSemaphore(pdev-Res-image_cache_sem);
}
(note: not even compile tested - haven't managed to compile on Windows yet).
[ykaul@ykaul qxl]$ grep ImageCacheAdd\(pdev -A 2 -B 8 display/res.c
EngAcquireSemaphore(pdev-Res-image_cache_sem);
cache_image = AllocCacheImage(pdev);
ImageCacheRemove(pdev, cache_image);
cache_image-key = key;
cache_image-image = NULL;
cache_image-format = format;
cache_image-width = surf-sizlBitmap.cx;
cache_image-height = surf-sizlBitmap.cy;
ImageCacheAdd(pdev, cache_image);
RingAdd(pdev, pdev-Res-cache_image_lru, cache_image-lru_link);
EngReleaseSemaphore(pdev-Res-image_cache_sem);
--
EngAcquireSemaphore(pdev-Res-image_cache_sem);
cache_image = AllocCacheImage(pdev);
ImageCacheRemove(pdev, cache_image);
cache_image-key = key;
cache_image-image = NULL;
cache_image-format = SPICE_BITMAP_FMT_RGBA;
cache_image-width = surf-sizlBitmap.cx;
cache_image-height = surf-sizlBitmap.cy;
ImageCacheAdd(pdev, cache_image);
RingAdd(pdev, pdev-Res-cache_image_lru, cache_image-lru_link);
EngReleaseSemaphore(pdev-Res-image_cache_sem);
Y.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Rings semaphore? (in XF86 QXL driver)
Unlike Windows' QXL driver, where there are semaphores for ring and caches: display/qxldd.h: HSEMAPHORE cursor_sem; /* Protects cursor_ring */ HSEMAPHORE surface_sem; /* Protects surfaces allocation */ HSEMAPHORE image_cache_sem; /* Protects image cache */ HSEMAPHORE cursor_cache_sem; /* Protects cursor cache */ HSEMAPHORE palette_cache_sem; /* Protects palette cache */ I don't see anything in xf86 QXL driver. Is it not needed, or am I looking in the wrong places? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Possible division by zero in miStepDash() on common/lines.c?
Running clang static analyzer on latest spice (I hope it comes out
normal on email - the bug is on line 416, totallen may be 0 because of
the assignment on line 412):
static void
392 miStepDash (int dist, /* distance to step */
393 int *pDashIndex, /* current dash */
394 unsigned char *pDash, /* dash list */
395 int numInDashList, /* total length of dash list */
396 int *pDashOffset /* offset into current dash */
397 )
398 {
399 int dashIndex, dashOffset;
400 int totallen;
401 int i;
402
403 dashIndex = *pDashIndex;
404 dashOffset = *pDashOffset;
405 if (dist pDash[dashIndex] - dashOffset) {
1
Taking false branch
406 *pDashOffset = dashOffset + dist;
407 return;
408 }
409 dist -= pDash[dashIndex] - dashOffset;
410 if (++dashIndex == numInDashList)
2
Taking false branch
411 dashIndex = 0;
412 totallen = 0;
3
The value 0 is assigned to 'totallen'
413 for (i = 0; i numInDashList; i++)
4
Loop condition is false. Execution continues on line 415
414 totallen += pDash[i];
415 if (totallen = dist)
5
Taking true branch
416 dist = dist % totallen;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Win7 Guest system hangs while doing shutdown...
On 26/07/2011 20:06, Naga Mohan Pothula wrote: Hi, I downloaded and built driver. Still I'm facing this issue :( I tested even with Spice v0.8.2 and Spice-protocol v0.8.1 with dual head environment. Launched win7 Guest system in fullscreen mode with auto-config. Thanks/Mohan. They may not have the fix yet. I know they are sync'ing the below repo with some fixes, hopefully they'll be there soon. Y. *From:* Yaniv Kaul yk...@redhat.com *To:* Naga Mohan Pothula nagamohan.poth...@yahoo.com *Cc:* Lubos Kocman lkoc...@redhat.com; spice-devel@lists.freedesktop.org spice-devel@lists.freedesktop.org *Sent:* Sunday, July 24, 2011 11:54 PM *Subject:* Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... The latest source for upstream virtio-* drivers is at http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary I do not know if it's the very latest for virtio-serial or not. I can ask. Y. On 07/25/2011 06:04 AM, Naga Mohan Pothula wrote: Can you please give your response on below mail? ~Mohan. *From:* Naga Mohan Pothula nagamohan.poth...@yahoo.com mailto:nagamohan.poth...@yahoo.com *To:* Lubos Kocman lkoc...@redhat.com mailto:lkoc...@redhat.com; Yaniv Kaul yk...@redhat.com mailto:yk...@redhat.com *Cc:* spice-devel@lists.freedesktop.org mailto:spice-devel@lists.freedesktop.org spice-devel@lists.freedesktop.org mailto:spice-devel@lists.freedesktop.org *Sent:* Friday, July 22, 2011 10:42 AM *Subject:* Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... Thanks for your prompt response. I downloaded virtio-serial driver from http://spice-space.org/download.html and looked for source code in repositories link http://spice-space.org/page/Repositories but haven't find it. I installed vioserial-win-1.1.16. If this is not the latest one, could you direct me source code link for this? Thanks, Mohan. *From:* Lubos Kocman lkoc...@redhat.com mailto:lkoc...@redhat.com *To:* Naga Mohan Pothula nagamohan.poth...@yahoo.com mailto:nagamohan.poth...@yahoo.com *Sent:* Friday, July 22, 2011 1:49 AM *Subject:* Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... Also check: https://bugzilla.redhat.com/show_bug.cgi?id=721355 - Original Message - From: Yaniv Kaul yk...@redhat.com mailto:yk...@redhat.com To: Naga Mohan Pothula nagamohan.poth...@yahoo.com mailto:nagamohan.poth...@yahoo.com Cc: spice-devel@lists.freedesktop.org mailto:spice-devel@lists.freedesktop.org Sent: Friday, July 22, 2011 8:44:00 AM Subject: Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... On 22/07/2011 03:41, Naga Mohan Pothula wrote: Hi, Launched windows7 Guest image with Spice v0.8 in fullscreen mode with auto-config from windows client. Spice window hangs frequently while doing shutdown or restart. if it doesn't hang then shutdown process is slow. This issue doesn't happen if we don't launch in full-screen mode. I thought system hangs happen due to VDAgent and stopped Agent service but this issue still happens. When we do mouse click operations while system hang, spice client is crashed. I verified spice client logs but haven't get any clue. Regards, Mohan. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto:Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel I suspect actually the virtio-serial driver. There were some fixes around it. Remove it and see if that happens still. I'm not sure where can you obtain the latest binary ones, though. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto:Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto: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] Missing key and mouse release events
On 07/23/2011 02:34 PM, Frédéric Grelot wrote:
I didn't fill a bug at that time, but you'll find every details here :
(The last message has an attachment with the corresponding wireswhark dump)
http://comments.gmane.org/gmane.comp.emulators.spice.devel/2948
The capture cannot be parsed by the dissector, as it lacks the initial
connection.
The dissector cannot know which channel is which ('thanks' to identical
message IDs in different channels), without seeing the initial connection.
If you can reproduce and capture before you open the spice client to the
guest, that'd be great.
Y.
- Mail original -
On Sat, Jul 23, 2011 at 03:47:30AM -0400, John A. Sullivan III wrote:
Hello, all. This is happening enough now that I don't think it is
my
imagination. It seems that SPICE sometimes either does not detect
that
I have released a key or is slow in doing so.
On quite a number of occasions, my input started behaving
strangely.
Menu options would not work, it appeared my CAPS lock was on but
not
quite. Then I realized that the SHIFT key was stuck. I pressed
and
released it again and normal functionality returned. Again, this
was
not a one-off event but happened several times.
Just now, I was testing a strange but potentially common scenario
in our
environment where my SPICE client was running an X2Go session on
the
SPICE guest to a third system. Sometimes the scroll bars did not
seem
to realize I had released the mouse button. On occasion, I would
press
delete and an entire block of text would disappear or I'd press
space
and a row of spaces would appear.
Has anyone else seen this behavior? I thought I would ask before
opening
it as a bug. Thanks - John
Please open a bug. I remember seeing missed keys but not recently and
I
don't know how to reproduce, would be good if you provided the
details.
___
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
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Win7 Guest system hangs while doing shutdown...
The latest source for upstream virtio-* drivers is at http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary I do not know if it's the very latest for virtio-serial or not. I can ask. Y. On 07/25/2011 06:04 AM, Naga Mohan Pothula wrote: Can you please give your response on below mail? ~Mohan. *From:* Naga Mohan Pothula nagamohan.poth...@yahoo.com *To:* Lubos Kocman lkoc...@redhat.com; Yaniv Kaul yk...@redhat.com *Cc:* spice-devel@lists.freedesktop.org spice-devel@lists.freedesktop.org *Sent:* Friday, July 22, 2011 10:42 AM *Subject:* Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... Thanks for your prompt response. I downloaded virtio-serial driver from http://spice-space.org/download.html and looked for source code in repositories link http://spice-space.org/page/Repositories but haven't find it. I installed vioserial-win-1.1.16. If this is not the latest one, could you direct me source code link for this? Thanks, Mohan. *From:* Lubos Kocman lkoc...@redhat.com *To:* Naga Mohan Pothula nagamohan.poth...@yahoo.com *Sent:* Friday, July 22, 2011 1:49 AM *Subject:* Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... Also check: https://bugzilla.redhat.com/show_bug.cgi?id=721355 - Original Message - From: Yaniv Kaul yk...@redhat.com mailto:yk...@redhat.com To: Naga Mohan Pothula nagamohan.poth...@yahoo.com mailto:nagamohan.poth...@yahoo.com Cc: spice-devel@lists.freedesktop.org mailto:spice-devel@lists.freedesktop.org Sent: Friday, July 22, 2011 8:44:00 AM Subject: Re: [Spice-devel] Win7 Guest system hangs while doing shutdown... On 22/07/2011 03:41, Naga Mohan Pothula wrote: Hi, Launched windows7 Guest image with Spice v0.8 in fullscreen mode with auto-config from windows client. Spice window hangs frequently while doing shutdown or restart. if it doesn't hang then shutdown process is slow. This issue doesn't happen if we don't launch in full-screen mode. I thought system hangs happen due to VDAgent and stopped Agent service but this issue still happens. When we do mouse click operations while system hang, spice client is crashed. I verified spice client logs but haven't get any clue. Regards, Mohan. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto:Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel I suspect actually the virtio-serial driver. There were some fixes around it. Remove it and see if that happens still. I'm not sure where can you obtain the latest binary ones, though. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto:Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org mailto: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] Win7 Guest system hangs while doing shutdown...
On 22/07/2011 03:41, Naga Mohan Pothula wrote: Hi, Launched windows7 Guest image with Spice v0.8 in fullscreen mode with auto-config from windows client. Spice window hangs frequently while doing shutdown or restart. if it doesn't hang then shutdown process is slow. This issue doesn't happen if we don't launch in full-screen mode. I thought system hangs happen due to VDAgent and stopped Agent service but this issue still happens. When we do mouse click operations while system hang, spice client is crashed. I verified spice client logs but haven't get any clue. Regards, Mohan. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel I suspect actually the virtio-serial driver. There were some fixes around it. Remove it and see if that happens still. I'm not sure where can you obtain the latest binary ones, though. Y. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Problems compiling SPICE Windows client SDK 7.1
On 07/06/2011 02:01 AM, John A. Sullivan III wrote: On Tue, 2011-07-05 at 09:35 +0300, Arnon Gilboa wrote: Hi John, See my comments below. Arnon John A. Sullivan III wrote: Hello, all. Being a Windows ignoramus, I am having a nightmare of a time compiling the Windows client on our Windows 7 build system. I'll recount them for other ignorami and to ask for help for the things I could not figure out. I installed the Windows SDK 7.1 and it installed without compilers because we had .net 3.5 installed. I installed 4.0 and reinstalled the SDK and I know had compilers. Currently, the only supported environment for Spice windows client compilation is Visual Studio 2008. To use our precompiled libraries (wspice) use version 9.0.30729.1 SP. There might be problems with the libs if you use other VS versions. The build instructions under Windows say, The prerequisites are available as binaries in one package on the download page. However, I did not see such a binary on the download page. I downloaded spice-0.8.1, spice-protocol-0.8.0, and wspice-x64_20110308. You have downloaded everything needed for building the client. In addition you need to have Python (2.7+) pyparsing installed. The prerequisites available as binaries... is wspice. I then did: setenv /Release /x64 /win7 set REDC_BUILD_DIR=D:\Binaries\x64\Win7 set SPICE_PROTOCOL_DIR=C:\Users\Administrator\Downloads\spice \spice-protocol-0.8.0 set SPICE_LIBS=C:\Users\Administrator\Downloads\wspice-x64_08032011 I would prefer other locations for the files... but if C:\Users\Administrator\Downloads is fine for you, it's ok for me. C: cd \Users\Administrator\Downloads\spice\spice-0.8.1\client\windows redc.sln It had no idea of what to do with the file - no association. VS will open it Some Internet research, reading the SDK Release Notes, and a little while later and I did: msbuild -p:platform=X64 redc.sln It complained that it could not find vcbuild.exe. We have never built it with msbuild or vcbuild.exe. If you want to build using VS from cmd line, use something like: devenv.exe redc.sln /build Release|x64 Some more research and I found that the 7.1 SDK uses msbuild and that it takes a different syntax than vcbuild. It provides vcupgrade to convert the .vcproj files into .vcxproj files but does not convert /sln files. devenv does but that is not in the SDK and must be included with the full Visual Basic I am guessing. So, the instructions said to manually edit the .sln files to use 2010 instead of 2008 and reference .vcxproj files instead of .vcproj files. So, I ran vcupgrade on redc.vcproj, edited redc.sln and tried again. Same failure message about vcbuild.exe. I guess it won't work this way, or it will take too much time to make it work. I then looked more closely at the .sln file and it looked like it was merely specifying the build environment options which are no longer necessary with msbuild using the -p:platform= parameter (or so I read) so I tried to simply do msbuild -p:platform=X64 redc.vcxproj. That complained about not finding python. So it looks like python is called in generate.bat. I installed python and it failed again - python was not in the path. So I added it to the path, opened an new SDK shell and tried again. Now I get: C:\Users\Administrator\Downloads\spice\spice-0.8.1\client\windowsmsbuild -p:platform=X64 redc.vcxproj Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 7/4/2011 8:07:48 PM. Project C:\Users\Administrator\Downloads\spice\spice-0.8.1\client\windows\redc.vcxproj on node 1 (default targets). InitializeBuildStatus: Touching D:\Binaries\x64\Win7\X64\Release\redc.unsuccessfulbuild. CustomBuild: Generating demarshaller File ..\..\spice_codegen.py, line 200 print No changes to %s % dest_file ^ SyntaxError: invalid syntax File ..\..\spice_codegen.py, line 200 print No changes to %s % dest_file ^ SyntaxError: invalid syntax C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(1 51,5): error MSB6006: cmd.exe exited with code 1. [C:\Users\Administrator\Dow nloads\spice\spice-0.8.1\client\windows\redc.vcxproj] Done Building Project C:\Users\Administrator\Downloads\spice\spice-0.8.1\clien t\windows\redc.vcxproj (default targets) -- FAILED. Build FAILED. C:\Users\Administrator\Downloads\spice\spice-0.8.1\client\windows\redc.vcxproj (default target) (1) - (CustomBuild target) - C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets (151,5): error MSB6006: cmd.exe exited with code 1. [C:\Users\Administrator\D ownloads\spice\spice-0.8.1\client\windows\redc.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.65 I'm assuming the code is correct and I have done something wrong. How do I compile the Windows client
Re: [Spice-devel] Unfair comparisons with RDP
On 07/04/2011 07:33 PM, John A. Sullivan III wrote: On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote: On 07/04/2011 05:21 PM, John A. Sullivan III wrote: Very helpful and interesting. I'll respond in-line - John On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote: On 06/30/2011 10:10 AM, Yaniv Kaul wrote: On 06/30/2011 05:33 AM, John A. Sullivan III wrote: On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: - Original Message - snip Hello, all. I've been using both RDP via TSPlus and SPICE for over a week now and the practical world results at least in my mode of operation are becoming clear. SPICE does handle major screen refreshes better, e.g., monstrous graphics or continuously pasting a full line of text in a full screen notepad. Of course, SPICE is a clear winner when it comes to video though still not practically usable on low bandwidth links. However, RDP is trouncing SPICE in the more common day to day tasks involving small screen updates. For example, every time I open or switch my screen to LibreOffice, the tool bar icons seems to pain one at a time in SPICE where as they appear all at once in TSPlus. Document scrolling is more immediate and smoother. Surprisingly, when I open the PuTTY dialog in SPICE, it paints in sections whereas TSPlus appears all at once. You'll really need to post some real details here - from versions of qemu+spice server that you're using along with the qemu command line syntax, host OS, hardware details through to what's running in the guest, driver versions, etc. I've never seen RDP trounce spice, but if it does, then we need some scientific information on the environment so we can diagnose and assist. snip Very happy to do so as we really do want SPICE to become our protocol of choice. I believe I've posted up our details before but will do so again. Would you be so kind as to capture the Spice traffic (using tcpdump/wireshark) and send it over? Specifically: 1. Please capture from start - before the Spice client connects to the server. 2. Ensure you catch full sized packets (-s - could be 1500 most likely, when using tcpdump) 3. Save into file (-w /tmp/file.pcap when using tcpdump) 4. Please compress and send / let me know where I can pick it up from. I suggest you have only the scenario of connecting to the VM and opening putty, which you complain is slow. Hopefully it'll give us some clue. TIA, Y. disclaimer my Wireshark dissector may be buggy, and I'm basing my analysis on it/disclaimer Initial thoughts, from looking at the packet capture: 1. Initial image (packet 689) is not compressed using ZLIB (but LZ_RGB). Known issue, filed a bug about it somewhere (upstream or Fedora). 2. The same image is actually quite big - 1440x900 - made up of 172 packets, which took 0.42seconds from the first to the last packets. Perhaps splitting it to multiple smaller images would have improved the user experience. That makes sense. I was in full screen mode and my screen is 1440x900. 3. Next image (packet 967) was also using LZ_RGB, and was quite big 1440x793 - made up of 157 packets, and took 0.41 seconds from the first to last packet. Also makes sense - that was probably the toggle into full screen 4. Next image (packet 1023) is nicely compressed using ZLIB_GLZ_RGB. For some reason it does not have the CACHE_ME flag set. The next image (packet 1056) does have it. 5. Looks like you were not using the guest agent and that effects were not turned off? (example, packets 1085, 1580, 1960 which has multiple DRAW_FILL commands) - RDP, at least in previous versions, used to disable them by default. Can you verify the same settings are used with Spice? That's very interesting. We are but we frequently notice it stops and fixing it is one of our higher priorities. I'll recompile and see if I get any better performance and stability. I'll check the effects settings. 6. From packet 1580 and on we see nice use of images from the cache, so caching does appear to be working. It is a bit annoying that a 'use image from cache' for a 16x16 image takes 75 bytes, but it's the protocol. This is a little distressing. I'm guessing those 16x16 images are the LibreOffice tool bar icons. That part is one of the most dramatically slower comparisons for SPICE versus RDP. In RDP, they appear all at once. In SPICE, they paint slowly, one at a time, and perhaps do so a couple of times over - not sure about that last part but the overall experience is that it takes not just a little but many, many, many times longer to paint my LibreOffice screen in SPICE than it does with RDP. 7. Nowhere in the stream do I see JPEG compressed images. Not sure why. Was it enabled (can be seen in server side logs) ? I'll have to have a look. I assume one does not have to actively do something to enable this but rather that it is the default. Is that true? Thanks - John JPEG and ZLIB are only recommended when the connection to the client is limited
Re: [Spice-devel] Unfair comparisons with RDP
On 06/30/2011 10:10 AM, Yaniv Kaul wrote: On 06/30/2011 05:33 AM, John A. Sullivan III wrote: On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: - Original Message - snip Hello, all. I've been using both RDP via TSPlus and SPICE for over a week now and the practical world results at least in my mode of operation are becoming clear. SPICE does handle major screen refreshes better, e.g., monstrous graphics or continuously pasting a full line of text in a full screen notepad. Of course, SPICE is a clear winner when it comes to video though still not practically usable on low bandwidth links. However, RDP is trouncing SPICE in the more common day to day tasks involving small screen updates. For example, every time I open or switch my screen to LibreOffice, the tool bar icons seems to pain one at a time in SPICE where as they appear all at once in TSPlus. Document scrolling is more immediate and smoother. Surprisingly, when I open the PuTTY dialog in SPICE, it paints in sections whereas TSPlus appears all at once. You'll really need to post some real details here - from versions of qemu+spice server that you're using along with the qemu command line syntax, host OS, hardware details through to what's running in the guest, driver versions, etc. I've never seen RDP trounce spice, but if it does, then we need some scientific information on the environment so we can diagnose and assist. snip Very happy to do so as we really do want SPICE to become our protocol of choice. I believe I've posted up our details before but will do so again. Would you be so kind as to capture the Spice traffic (using tcpdump/wireshark) and send it over? Specifically: 1. Please capture from start - before the Spice client connects to the server. 2. Ensure you catch full sized packets (-s - could be 1500 most likely, when using tcpdump) 3. Save into file (-w /tmp/file.pcap when using tcpdump) 4. Please compress and send / let me know where I can pick it up from. I suggest you have only the scenario of connecting to the VM and opening putty, which you complain is slow. Hopefully it'll give us some clue. TIA, Y. disclaimer my Wireshark dissector may be buggy, and I'm basing my analysis on it /disclaimer Initial thoughts, from looking at the packet capture: 1. Initial image (packet 689) is not compressed using ZLIB (but LZ_RGB). Known issue, filed a bug about it somewhere (upstream or Fedora). 2. The same image is actually quite big - 1440x900 - made up of 172 packets, which took 0.42seconds from the first to the last packets. Perhaps splitting it to multiple smaller images would have improved the user experience. 3. Next image (packet 967) was also using LZ_RGB, and was quite big 1440x793 - made up of 157 packets, and took 0.41 seconds from the first to last packet. 4. Next image (packet 1023) is nicely compressed using ZLIB_GLZ_RGB. For some reason it does not have the CACHE_ME flag set. The next image (packet 1056) does have it. 5. Looks like you were not using the guest agent and that effects were not turned off? (example, packets 1085, 1580, 1960 which has multiple DRAW_FILL commands) - RDP, at least in previous versions, used to disable them by default. Can you verify the same settings are used with Spice? 6. From packet 1580 and on we see nice use of images from the cache, so caching does appear to be working. It is a bit annoying that a 'use image from cache' for a 16x16 image takes 75 bytes, but it's the protocol. 7. Nowhere in the stream do I see JPEG compressed images. Not sure why. Was it enabled (can be seen in server side logs) ? Still looking at the capture (and fixing the dissector along the way). Y. The qemu side is installed entirely from Fedora 15 RPM and unpatched except for Alon's patch to fix the Windows pixel depth problem. libvirt: 0.8.8-4.fc15 qemu-kvm-0.14.0-8.fc15.x86_64.rpm qemu-common-0.14.0-8.fc15.x86_64.rpm qemu-kvm-tools-0.14.0-8.fc15.x86_64.rpm qemu-img-0.14.0-8.fc15.x86_64.rpm qemu-system-x86-0.14.0-8.fc15.x86_64.rpm The hardware is a SuperMicro AMD server with two eight core processors and 16 GB of RAM. Two bonded Gb Ethernet ports provide access to the world while two separate Gb Ethernet ports provide access to the iSCSI SAN using dm-multipath multibus. Most of the testing has been from a Debian Squeeze i386 client running on an Asus netbook to a Windows Server 2008 64 bit server. The server uses raw partitions presented via iSCSI with the following configuration: domain type='kvm' namewindesk02.pacad.pacifera.com/name uuid70cdeb09-f6b1-6b4d-dc2f-f72c19b9560b/uuid memory4194304/memory currentMemory4194304/currentMemory vcpu2/vcpu os type arch='x86_64' machine='pc-0.14'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='localtime'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/bin/qemu-kvm/emulator disk type='file' device='cdrom' driver name
Re: [Spice-devel] [PATCH 2/2] data: add test.html page
On 06/29/2011 03:25 PM, Marc-André Lureau wrote:
Originally provided by Alon Leny and Peter Hatina.
---
Makefile.am |2 +-
configure.ac |1 +
data/Makefile.am |3 ++
data/test.html | 84 ++
4 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 data/Makefile.am
create mode 100644 data/test.html
diff --git a/Makefile.am b/Makefile.am
index 06330b2..b811df8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,6 +1,6 @@
ACLOCAL_AMFLAGS = -I m4
-SUBDIRS = SpiceXPI
+SUBDIRS = SpiceXPI data
EXTRA_DIST = \
m4
diff --git a/configure.ac b/configure.ac
index 79ea17d..6978182 100644
--- a/configure.ac
+++ b/configure.ac
@@ -77,6 +77,7 @@ m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
AC_OUTPUT([
Makefile
+data/Makefile
SpiceXPI/Makefile
SpiceXPI/src/Makefile
SpiceXPI/src/plugin/Makefile
diff --git a/data/Makefile.am b/data/Makefile.am
new file mode 100644
index 000..b47e0c0
--- /dev/null
+++ b/data/Makefile.am
@@ -0,0 +1,3 @@
+NULL =
+
+EXTRA_DIST = test.html
diff --git a/data/test.html b/data/test.html
new file mode 100644
index 000..c1a35e0
--- /dev/null
+++ b/data/test.html
@@ -0,0 +1,84 @@
+HTML
+HEAD
+TITLE4x Scriptable Plug-in Test/TITLE
I suggest 'Spice XPI test page'
Y.
+/HEAD
+BODY onload='BodyLoad()' onunload='BodyUnload()'
+
+center
+h1SPICE xpi test page/h1
+/center
+
+SPICE xpi test page.
+brbr
+
+center
+
+embed type=application/x-spice width=0 height=0br
+
+script
+
+var embed = document.embeds[0];
+
+function BodyLoad() {
+document.getElementById(log).innerHTML += BodyLoadbr;
+}
+
+function BodyUnload() {
+document.getElementById(log).innerHTML += BodyUnloadbr;
+}
+
+function Execute()
+{
+document.getElementById(log).innerHTML += Executebr;
+embed.hostIP = document.all[Host].value;
+embed.port = document.all[Port].value;
+embed.SecurePort = document.all[SecurePort].value;
+embed.Password = document.all[Password].value;
+embed.HostSubject = document.all[HostSubject].value;
+embed.TrustStore = document.all[TrustStore].value;
+embed.fullScreen = false;
+embed.AdminConsole = (document.all[AdminConsole].value == 1);
+embed.HotKeys = document.all[HotKeys].value;
+embed.fAudio = true;
+embed.connect();
+}
+
+function Status()
+{
+var status = embed.ConnectedStatus();
+document.getElementById(log).innerHTML += ConnectedStatus = + status +
br;
+}
+
+function Show()
+{
+embed.show();
+document.getElementById(log).innerHTML += Show was calledbr;
+}
+
+/script
+
+
+br
+Host:input id=Host type=text size=13 /input
+Port:input id=Port type=text size=13 /input BR
+SecurePort:input id=SecurePort type=text size=13 /input BR
+Password:input id=Password type=text size=13 /input
+HotKeys:input id=HotKeys type=text size=13 value=release-cursor=ctrl+alt
/input
+AdminConsole:input id=AdminConsole type=text size=5 value=1 /input
+BR
+HostSubject:input id=HostSubject type=text size=60 /input/br
+TrustStore:textarea id=TrustStore type=text cols=65 rows=15 /textarea
BR
+
+input type=button value=Exec onclick='Execute()'/
+input type=button value=Check Status onclick='Status()' /input
+input type=button value=Show onclick='Show()' /input
+
+/center
+
+
+---br
+div id=log
+/div
+---br
+/BODY
+/HTML
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Thoughts about improving streaming video
On 06/27/2011 11:50 AM, Christophe Fergeau wrote: Hey, Fwiw, http://blogs.adobe.com/penguinswf/2010/01/solving_different_problems.html This is a bit outdated - as they have realized some of the video could be fully accelerated. Above: The Flash Player has to do a little bit more. In addition to decoding the data, it has to convert YUV data to the RGB colorspace http://en.wikipedia.org/wiki/RGB_color_space and combine the image with other Flash elements. And then in http://www.adobe.com/devnet/flashplayer/articles/stage_video.html : The H.264 codec is stage video's best friend; using this will ensure you get full GPU acceleration from video decoding to rendering. With this approach, no read-back (sending the data from the GPU to the CPU) is required to composite the video frames in the display list anymore. The YUV 4:2:0 http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 formatted video frames are converted to RGB through a GPU shader (DirectX9 or OpenGL) and blitted onscreen. As a result, you will see higher pixel fidelity and some reduction in CPU and memory usage. then they go on to have a list of limitations finalized by 'In practice, none of the above restrictions will affect the most common use case, which is a video player application.' Y. and http://www.splitted-desktop.com/static/en/pdf/actu/Linux_with_Gnash.pdf might be interesting readings. Christophe On Mon, Jun 27, 2011 at 08:32:52AM +0300, Yaniv Kaul wrote: Licensing and patent concerns of x264 aside (see http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html), the more I think about it, the more it makes sense to me to have H.264 offload feature in QXL: 1. Many (Flash, HTML5, others) are moving to H.264 - and take advantage of hardware acceleration if such is available, for complete decoding of the stream. If QXL advertises itself as being able to HW accel. the stream, we need to just pick the stream and move it to the client. On the client, we can either download it to the local GPU which will HW accelerate its decoding, or use software-based decoding (x264, for example). 2. Then we can revisit x264 and see if it really provides a noticeable advantage over mjpeg - clearly having one video solution is cleaner and less hassle, and x264 seems to have some nice properties we can use (see http://x264dev.multimedia.cx/archives/249 regarding low latency). Both are not trivial tasks, I'm afraid. Y. On 06/25/2011 06:33 PM, John A. Sullivan III wrote: Hello, all. Andrea Celestino was kind enough to email me off list about streaming video performance as reducing SPICE bandwidth consumption for streaming video is his project as a Computer Engineering student. He agreed that I could repost our conversation to invite input from others on the list. The (top posted - sorry) thread is below - John Hi, Andrea. No problem with your English. It is certainly better than my very rusty Italian! I know little about video other than as a network engineer and I am not a programmer but I do know what we need. From that ignorant perspective, I see several possibilities. Video is inherently brutal when it comes to network bandwidth and processing. There are also different usage scenarios. For example, it makes sense to stream when the video needs to be played only once and started immediately. However, if it is going to be viewed multiple times, the Citrix approach of downloading and playing locally makes more sense. I've mentioned on the list how we can do this with technology already in the X2Go project. It is probably the least desirable option and the least interesting for your project. Of course, we have to handle all this complexity in a way which does not confuse the end user who just wants to click on their file or web site and have it work! For streaming the video between the SPICE server and client, I think we also have a couple of options. I don't think there is any magic that can be done. It is a matter of using the most appropriate codec for the transmission. The challenge, as already mentioned on the list, is encoding on the fly. The clients need to decode no matter what but, in non-SPICE usage, the file is pre-encoded. So, in our selection of codecs, speed of encoding versus decoding becomes critical. We must also not only choose one which uses an open source license but one which is not patent encumbered. I believe that rules out X264. The most likely candidate is probably VP8 with Theora as an alternative. Once a codec (or a selection of codecs) has been chosen, the next challenge is how to switch. One option is to simply make it a setting in the SPICE parameters for qemu. The two advantages are that it is the simplest and it allows the system administrator (who hopefully knows his system well) to make the balance between CPU utilization and bandwidth. The disadvantage is that it does not adapt to the users environment and may require a reboot to change. The second option
