On 07/07/11 18:33, Alon Levy wrote:
This is RfC quality. Specifically where to call surface_updated. Currently I
only call it from stop. This should be good enough for migration, which is
the only use case I think. This means after stop qemu is guranteed to know
the dirty regions of all
On Fri, Jul 08, 2011 at 08:41:22AM +0200, Gerd Hoffmann wrote:
On 07/07/11 18:33, Alon Levy wrote:
This is RfC quality. Specifically where to call surface_updated. Currently I
only call it from stop. This should be good enough for migration, which is
the only use case I think. This means after
On 07/08/11 09:47, Alon Levy wrote:
On Fri, Jul 08, 2011 at 08:41:22AM +0200, Gerd Hoffmann wrote:
On 07/07/11 18:33, Alon Levy wrote:
This is RfC quality. Specifically where to call surface_updated. Currently I
only call it from stop. This should be good enough for migration, which is
the
On Fri, Jul 08, 2011 at 10:05:19AM +0200, Gerd Hoffmann wrote:
On 07/08/11 09:47, Alon Levy wrote:
On Fri, Jul 08, 2011 at 08:41:22AM +0200, Gerd Hoffmann wrote:
On 07/07/11 18:33, Alon Levy wrote:
This is RfC quality. Specifically where to call surface_updated. Currently
I
only call it
BTW: wasn't the plan to remove the rect args from update_area_async?
I thought the idea was just to remove the dirty rects, not the actual
rect the guest wants updated. This patch removes the former.
Ah, ok. Yes, plan was to zap just the dirty rects.
cheers,
Gerd
---
client/red_channel.cpp | 32
client/red_channel.h |6 +++---
client/red_peer.cpp|8
client/red_peer.h |4 ++--
4 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/client/red_channel.cpp b/client/red_channel.cpp
vinfo in x11/platform.cpp is allocated using new[] so it needs to
be freed with delete[]
---
client/x11/platform.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/x11/platform.cpp b/client/x11/platform.cpp
index 7c31058..910d61e 100644
---
There is a double free in client/x11/platform.cpp.
In get_selection(), in the exit: case with ret_val == -1 and data != NULL,
*data_ret (which is returned to the caller) has already been
assigned data, so it will be pointing to freed memory when data is
XFree'd'. Then in handle_selection_notify,
If you try to connect to a linux guest with WAN options, SPICE window opens up
and is blank - it then fails with vdagent timeout message. It should give a
warning that this is only applicable for windows guest and still connect to
guest.
It all starts in RedClient::handle_init
This function
Hi,
Wouldn't an idea be to get the OpenGL version (+ glut?) in a usable
shape? I would guess transitioning it to OpenGL ES shouldn't be too
difficult either for android/ios..
Best Regards,
Attila Sukosd
-
DTU Computing Center - www.cc.dtu.dk
When qemu creates a channel, reds.c contains code to check the
minor/major channel versions known to QEMU (ie the ones that were
current in spice-server when QEMU was compiled) and to compare these
versions against the current ones the currently installed spice-server
version.
According to kraxel
Ok - thanks for the information - I will check into it.
Hi Marc.
What do you think Marc?
On Jul 8, 2011, at 2:35 AM, Christophe Fergeau wrote:
Hi Cliff,
On Thu, Jul 07, 2011 at 06:12:07PM -0500, Cliff Sharp wrote:
I would like to ask a question to extract a fairly detailed response from
Great suggestion.
My plan has been to convert to OpenGL - then spice-ios would have the potential
to run on most every platform with decent performance.
OS/X runs OpenGL and iOS runs OpenGL ES. I know how to implement OpenGL is such
a way that it would be the same code base on both of these
These are very good points and I really appreciate your input.
I will research this over the next couple of days and see if I can make some
sense of it.
I will again try and decipher the spice-glib part of the spice-gtk project.
It would help me quite a bit if you would point me to specific
I am trying to run the Win32 spice client on Windows XP SP3. In some cases it
works, but normally the program terminates immediately without any indication
what might go wrong. The only hint about what is happening are these entries in
spicec.log:
1310140678 INFO [1676:1648]
On Fri, Jul 08, 2011 at 11:32:02AM -0500, Cliff Sharp wrote:
According to the spice-gtk here is a list of the main level build dependent
libraries listed on the web site:
spice-protocol
pygtk2-devel
inittool
celt051-devel
gtk2-devel
openssl-devel
pulseaudio-devel
pixman-devel
python
This is very helpful.
Thanks.
On Jul 8, 2011, at 11:37 AM, Christophe Fergeau wrote:
On Fri, Jul 08, 2011 at 11:32:02AM -0500, Cliff Sharp wrote:
According to the spice-gtk here is a list of the main level build dependent
libraries listed on the web site:
spice-protocol
pygtk2-devel
17 matches
Mail list logo
