On 06/28/2011 02:18 PM, Christophe Fergeau wrote:
Hi,
Currently, the mjpeg encoder has to preprocess the images it gets from
spice-server to make sure the pixel order is the one libjpeg expects (RGB).
This means iterating over the whole images swapping pixels since the input
images are BGR or BG
On 06/20/2011 02:18 PM, Alon Levy wrote:
From: Yonit Halperin
When surfaces are being reloaded to the worker (e.g., after UPDATE_MEM), we
will send them to the client only if and when it needs them.
---
server/red_worker.c | 33 +++--
1 files changed, 19
On 06/30/2011 12:58 PM, Alon Levy wrote:
On Thu, Jun 30, 2011 at 12:36:27PM +0300, Yonit Halperin wrote:
On 06/20/2011 02:18 PM, Alon Levy wrote:
From: Yonit Halperin
When surfaces are being reloaded to the worker (e.g., after UPDATE_MEM), we
will send them to the client only if and when it
When the worker was stoped, the cursor was copied from guest ram to the host
ram,
and its corresponding qxl command was released.
This is unecessary, since the qxl ram still exists (we keep references
to the surfaces in the same manner).
It also led to BSOD on guest upon migration: the device trac
In addition (1) make handle_dev_destroy_surfaces call red_release_cursor
(2) call red_wait_outgoing_item(cursor_channel) only after adding msgs to pipe
---
server/red_worker.c | 71 +-
1 files changed, 24 insertions(+), 47 deletions(-)
diff --git
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to process a command we receive
id 0, group 0, virt star
On 07/04/2011 11:54 AM, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to
On 07/04/2011 12:23 PM, Gerd Hoffmann wrote:
On 07/04/11 10:51, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..9fdeffb 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_c
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..cff95a4 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_c
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..b3a3507 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_c
On migration, destroy_surfaces is called from qxl (qxl_hard_reset), before the
device was loaded (on destination).
handle_dev_destroy_surfaces led to red_process_commands, which read the qxl
command ring
(which appeared to be not empty), and then when processing the command
it accessed unmapped m
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,
fixes "display_channel_release_item: panic: invalid item type"
Before changing the red_worker to use the red_channel interface, there
was a devoted red_pipe_clear routine for the display channel and cursor channel.
However, clearing the pipe in red_channel, uses the release_item callback
the worke
same as commit 74a9d10af96f4d7c8c1b1d7fca124a8df9180787 for cursor channel
---
server/red_worker.c | 43 ++-
1 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index fc4326c..8e8ec13 100644
--- a/serve
On 07/05/2011 03:22 PM, Alon Levy wrote:
On Mon, Jun 20, 2011 at 10:57:58AM +0200, Alon Levy wrote:
ping?
qemu calls spice_server_migrate_switch even if it didn't do a
spice_server_migrate_info first. Fix the resulting error by not pushing
a switch host tag to the pipe in this case, and add a
On 07/06/2011 08:37 PM, Alon Levy wrote:
The new _ASYNC io's in qxl_dev listed at the end get six new api
functions, and an additional callback function "async_complete". When
the async version of a specific io is used, completion is notified by
calling async_complete, and no READY message is wri
On 07/06/2011 08:37 PM, Alon Levy wrote:
The new _ASYNC io's in qxl_dev listed at the end get six new api
functions, and an additional callback function "async_complete". When
the async version of a specific io is used, completion is notified by
calling async_complete, and no READY message is wri
On 07/06/2011 08:37 PM, Alon Levy wrote:
This does three things:
flush both command rings
stop (rendering everything)
start
Pulled out start and stop to their own functions to do this easily.
The added api is specifically async, i.e. it calls async_complete
when done.
Hi,
after flushing
On 07/06/2011 08:37 PM, Alon Levy wrote:
---
server/spice.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/server/spice.h b/server/spice.h
index fec2476..20ceeef 100644
--- a/server/spice.h
+++ b/server/spice.h
@@ -206,6 +206,8 @@ struct QXLInterface {
void (*n
QXL_SURFACE_HOOKS,
and
finally sends a QXL_SURFACE_CMD_CREATE with the valid data flag to make the
server
send a surface image message after the surface create message.
Cc: Yonit Halperin
---
display/driver.c |3 +-
display/qxldd.h |8 ++
display/surface.c | 212
surfaces when the device is disabled, we just punt the allocation to the
gdi, but the code is still left in GetSurfaceMemory.
Isn't it better if we keep it symmetric: use
QXLGetSurface/QXLDelSurface, or do the alloc/free independently?
Cc: Yonit Halperin
---
display/driver.c |
On 07/07/2011 04:47 PM, Yonit Halperin wrote:
Hi,
Generally, when parameters of a function are divided into several lines,
they should be aligned to the same column.
On 07/07/2011 12:43 PM, Alon Levy wrote:
Adds fields to SurfaceInfo to cache data previously only available
via SurfaceArea
er.
For resolution change this work is excessive but correct. Since
miniport:SetPowerState is called after DrvAssertMode during suspend (actually
there is no defined order in the documentation), there is no way to distinguish
between the two anyway.
Cc: Yonit Halperin
---
On 07/07/2011 12:43 PM, Alon Levy wrote:
GDI will continue using any callback we registered even after a
DrvAssertMode(FALSE). We are expected to move any surface we own to GDI handled
and ignore any new requests to create a surface. This is called punting and we
use PDev->enabled to indicate if
Hi,
I forgot some more things about this patch:
On 07/07/2011 05:00 PM, Yonit Halperin wrote:
+static BOOL AssertModeDisable(PDev *pdev)
+{
+ DEBUG_PRINT((pdev, 3, "%s entry\n", __FUNCTION__));
+ /* flush command ring and update all surfaces */
+ WRITE_PORT_UCHAR(pdev->notif
On 07/07/2011 12:43 PM, Alon Levy wrote:
---
display/driver.c | 44 ++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/display/driver.c b/display/driver.c
index fff462d..e77e32f 100644
--- a/display/driver.c
+++ b/display/driver.c
@@
On 07/07/2011 07:33 PM, Alon Levy wrote:
This does three things:
flush both command rings
stop (rendering everything)
start
Hi,
just need to update the message :)
Pulled out start and stop to their own functions to do this easily.
The added api is specifically async, i.e. it calls asyn
On 07/07/2011 07:33 PM, Alon Levy wrote:
used to move dirty rectangle notification from update_area to surface_updated.
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 thin
On 07/04/2011 12:23 PM, Gerd Hoffmann wrote:
On 07/04/11 10:51, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset
On 07/06/2011 04:38 PM, Soeren Sandmann wrote:
RENDER is a very commonly used X extension that currently is not
supported very well in SPICE. This leads to the QXL X driver having to
read back pixels from the device, render in software, then transmit an
image. This is currently the biggest perfor
Hi,
This version is more efficient since it removes the other_drawable
from the tree before red_handle_drawable_surfaces_client_synced is called.
In this manner, other_drawable won't be unnecessarily rendered if
update_area is called.
Yonit Halperin (2):
server: fix access to a rel
red_pipe_add_drawable can lead to removal of drawables from current tree
(since it calls red_handle_drawable_surfaces_client_synced), which can
also lead to releasing these drawables.
Before the fix, red_current_add_equal, called red_pipe_add_drawable,
without assuring afterwards that the drawables
red_handle_drawable_surfaces_client_synced was called only from
red_pipe_add_drawable, while it
should also be called from red_pipe_add_drawable_after. Otherwise, the client
might receive a command with a reference to a surface it doesn't hold and crash.
---
server/red_worker.c |2 ++
1 files
On 07/12/2011 05:03 PM, Alon Levy wrote:
Hi,
The new _ASYNC io's in qxl_dev listed at the end get six new api
functions, and an additional callback function "async_complete". When
the async version of a specific io is used, completion is notified by
calling async_complete, and no READY message i
On 07/13/2011 11:15 AM, Yonit Halperin wrote:
On 07/12/2011 05:03 PM, Alon Levy wrote:
Hi,
The new _ASYNC io's in qxl_dev listed at the end get six new api
functions, and an additional callback function "async_complete". When
the async version of a specific io is used, complet
On 07/08/2011 06:09 PM, Cliff Sharp wrote:
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 b
On 07/17/2011 01:55 PM, Alon Levy wrote:
These patches add:
* six _ASYNC io commands that don't block and raise a new interrupt
QXL_INTERRUPT_IO_CMD when done.
* two new io commands to be used for suspend and hibernate support for windows
drivers.
* a new QXL_INTERRUPT_ERROR to be r
On 07/19/2011 11:52 AM, Alon Levy wrote:
The new _ASYNC io's in qxl_dev listed at the end get six new api
functions, and an additional callback function "async_complete". When
the async version of a specific io is used, completion is notified by
calling async_complete, and no READY message is wri
I changed RedScreen::resize not to call rearrange_monitors. Instead,
the monitor should be configured correctly from Application, before
calling resize.
In addition, I made some cleanups to allow reusing rearrange_monitors code.
---
client/application.cpp | 94 +--
Hi,
forgot to mention that the endless recursion happened due to
Application::prepare_monitors calling RedScreen::resize calling
Application::rearrange_monitors calling Application::prepare_monitors
I will change the commit message.
On 07/21/2011 10:07 AM, Yonit Halperin wrote:
I changed
On 07/22/2011 02:33 PM, John A. Sullivan III wrote:
As mentioned in my last email, I have taken several traces revealing
performance issues, BSOD, and lost mouse scroll events.
Performance still seems to be a function of bandwidth. We are being
detected as low bandwidth:
main_channel_handle_par
On 07/25/2011 07:32 AM, John A. Sullivan III wrote:
On Sun, 2011-07-24 at 08:33 +0300, Yonit Halperin wrote:
On 07/22/2011 02:33 PM, John A. Sullivan III wrote:
As mentioned in my last email, I have taken several traces revealing
performance issues, BSOD, and lost mouse scroll events
calls EngModifySurface with QXL_SURFACE_HOOKS,
and
finally sends a QXL_SURFACE_CMD_CREATE with the valid data flag to make the
server
send a surface image message after the surface create message.
Cc: Yonit Halperin
---
display/driver.c |4 +-
display/qxldd.h |6 +-
display/
On 08/03/2011 06:20 PM, Alon Levy wrote:
RHBZ: 727886
The io port range test was too large, requiring support for the
new io ports introduced in revision 3. The purpose was just the opposite,
to only require the revision 2 range, and use the revision 3 range only
if the device claims revision 3.
On 08/03/2011 09:33 PM, 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 diffe
same as 8927cfbba232e28304734f7afd463c1b84134031, but for qxl_check_state, that
was
triggered by qxl_pre_load (which calls qxl_hard_reset, which calls
qxl_soft_reset),
and caused the migration target to crash.
---
hw/qxl.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff -
Hi,
Today, we handle migration in the client side by disconnecting from the
source and connecting to the target. The disconnection
and reconnection occur in response to
SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST, which is sent from the source when
migration ends.
In order to solve RHBZ #725009, i.e., t
On 08/16/2011 12:53 PM, Yonit Halperin wrote:
Hi,
Today, we handle migration in the client side by disconnecting from the
source and connecting to the target. The disconnection
and reconnection occur in response to
SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST, which is sent from the source when
migration
be too
hard. I had one question though, see below
On Tue, Aug 16, 2011 at 12:53:53PM +0300, Yonit Halperin wrote:
spice-server
=
(A) Migration source side
* reds::spice_server_migrate_start:
send SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST.
We can't use SPICE_MSG_MAIN
On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
Hi
I am also unfamiliar with the migration code, in particular the qemu -> qemu
part. It seems to me that no spice transmission occurs, but only guest memory. Is
that correct? How is state of the channel restored? Perhaps it doesn't need any
s
On 08/17/2011 09:48 PM, Alon Levy wrote:
On Wed, Aug 17, 2011 at 10:19:27AM +0200, David Jaša wrote:
On 17.8.2011 09:47, Yonit Halperin wrote:
On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
Hi
I am also unfamiliar with the migration code, in particular the qemu
-> qemu part. It seems
the other globals we use, mostly
semaphores which according to
http://msdn.microsoft.com/en-us/library/ff568281%28v=vs.85%29.aspx, we
definitely don't implement correctly, and we also need to reconsider if
all of them are really needed.
Cheers,
Yonit.
>From 6f5cf2dbcc876c82db5cd870ef21104b7b83
resending the 8th patch Christophe sent for review (and omitted debug prints)
Yonit Halperin (1):
client: setting monitors resolution before resizing screens, RHBZ
#728252
client/application.cpp | 40 ++--
client/application.h |5 +++--
2 files
fix for 419222f0f3de82b14960938263d06cc36b9e1a84
---
client/application.cpp | 40 ++--
client/application.h |5 +++--
2 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/client/application.cpp b/client/application.cpp
index 97014f8..115f28b
Hi,
I'm working right now on a fix to a BSOD that is related. It looks like
this fix solve the BSOD you encounter.
You can search for the related email on the list with the subject
"qxl-win important issues".
I will send the patches and an updated driver soon. It would be great if
you could let
On 08/22/2011 04:23 AM, Christophe Fergeau wrote:
Hey,
On Sun, Aug 21, 2011 at 09:28:58AM +0300, Yonit Halperin wrote:
resending the 8th patch Christophe sent for review (and omitted debug prints)
This patch works for me, but I have no idea whether this is the right way
of fixing it or not
after using spice.
There are still some fixes required. Mainly for how we use mutexes.
More details in the commit messages.
Cheers,
Yonit.
Yonit Halperin (4):
miniport: map vram to virtual address only once, #722954
display: not reset devices on DrvDisableDriver, RHBZ #731644
display
DrvSurface calls IOCTL_VIDEO_MAP/UNMAP_VIDEO_MEMORY
respectively.
These calls make the miniport map/unmap the vram to/from system space.
The BSOD occurred since with qxl revision 2, the driver assumes that
as long as it is loaded the vram stays (and all the other mem slots) valid
and in the same p
When several sessions of the display driver are alive,
DrvDisableDriver can be called for the older session while the newer session
has already started.
It happens when you switch users on a dual monitor XP guest. Reseting the
devices in DrvDisableDriver
while they are used by another session lea
see also commit 3218f6cdb95a73.
In revision < 3, objects (surfaces and other devram objects) stayed alive in
the pci ram
after DrvAssertMode(Disable) was called. Then, when another display driver
session started (upon switch user),
the driver had newly initiated mspace, but an old release ring (
(smartcard, usb(?), agent transmissions, etc.). So,
implementation in this level is required as well.
Cheers,
Yonit.
On 08/16/2011 12:53 PM, Yonit Halperin wrote:
Hi,
Today, we handle migration in the client side by disconnecting from the
source and connecting to the target. The d
On 08/25/2011 01:53 PM, Gerd Hoffmann wrote:
I've played with a approach simliar to (2) long ago. Actually did it by
registering a "live" migration handler. Didn't work that well too.
spice client will stay connected to both source and target for a long
time, and the spice code base simply coul
On 08/25/2011 02:15 PM, Daniel P. Berrange wrote:
On Thu, Aug 25, 2011 at 02:13:01PM +0300, Yonit Halperin wrote:
On 08/25/2011 01:53 PM, Gerd Hoffmann wrote:
I've played with a approach simliar to (2) long ago. Actually did it by
registering a "live" migration handler. Didn&#
Same as v1 + small cleanups (from Alon's review) + fixes to
MoveAllSurfacesToRam/VideoRam
Yonit Halperin (6):
miniport: map vram to virtual address only once, #722954
display: not reset devices on DrvDisableDriver, RHBZ #731644
display: support clearing the pci-bar when the pd
DrvSurface calls IOCTL_VIDEO_MAP/UNMAP_VIDEO_MEMORY
respectively.
These calls make the miniport map/unmap the vram to/from system space.
The BSOD occurred since with qxl revision 2, the driver assumes that
as long as it is loaded the vram stays (and all the other mem slots) valid
and in the same p
When several sessions of the display driver are alive,
DrvDisableDriver can be called for the older session while the newer session
has already started.
It happens when you switch users on a dual monitor XP guest. Reseting the
devices in DrvDisableDriver
while they are used by another session lea
see also commit "display/driver: reimplement DrvAssertMode for
Suspend+Hibernate (S3+S4) support".
In revision < 3, objects (surfaces and other devram objects) stayed alive in
the pci ram
after DrvAssertMode(Disable) was called. Then, when another display driver
session started (upon switch use
1) send create surface commands for all the surfaces that have not been
moved to vram
2) fix the parameters sent to SendSurfaceCreateCommand
3) send create primary surface IO
---
display/driver.c |1 +
display/qxldd.h |1 +
display/surface.c | 54 +++
---
display/surface.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/display/surface.c b/display/surface.c
index 16723d3..2cc5895 100644
--- a/display/surface.c
+++ b/display/surface.c
@@ -307,6 +307,7 @@ int MoveAllSurfacesToVideoRam(PDev *pdev)
if (surface_info
if qxl_send_events was called from spice server context, and then
migration had completed before a call to pipe_read, the target
guest qxl driver didn't get the interrupt. In addition,
qxl_send_events ignored further interrupts of the same kind, since
ram->int_pending was set. As a result, the gues
On 08/31/2011 01:23 PM, Gerd Hoffmann wrote:
On 08/31/11 10:20, Yonit Halperin wrote:
if qxl_send_events was called from spice server context, and then
migration had completed before a call to pipe_read, the target
guest qxl driver didn't get the interrupt. In addition,
qxl_send_events ig
if qxl_send_events was called from spice server context, and then
migration had completed before a call to pipe_read, the target
guest qxl driver didn't get the interrupt. In addition,
qxl_send_events ignored further interrupts of the same kind, since
ram->int_pending was set. As a result, the gues
---
hw/qxl.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index c7edc60..3ddca88 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -808,7 +808,7 @@ static void qxl_exit_vga_mode(PCIQXLDevice *d)
qxl_destroy_primary(d, QXL_SYNC);
}
-static vo
On 09/01/2011 10:36 PM, Michael S. Tsirkin wrote:
On Wed, Aug 31, 2011 at 03:37:33PM +0300, Yonit Halperin wrote:
if qxl_send_events was called from spice server context, and then
migration had completed before a call to pipe_read, the target
guest qxl driver didn't get the interrupt.
Th
o.
Thanks a lot! :-)
On 22 August 2011 11:59, Yonit Halperin wrote:
Hi,
I'm working right now on a fix to a BSOD that is related. It looks like this
fix solve the BSOD you encounter.
You can search for the related email on the list with the subject "qxl-win
important issues".
I wil
On 09/02/2011 06:19 PM, Gerd Hoffmann wrote:
reds_stream_free() may call the channel_event callback which is not
supposed to be callsed from worker thread context. This patch moves
the reds_stream_free call for the display channel from the worker to
the dispatcher to fix this issue.
[ Note: not
On 08/25/2011 01:24 PM, Yonit Halperin wrote:
Hi all,
here is the original email I sent for #725009.
===> For this plan no change is required in libvirt. <===
This plan does not bring back seamless migration to live. But it does
make the current host switching less noticeable by the use
On 08/26/2011 10:56 AM, Alon Levy wrote:
On Thu, Aug 25, 2011 at 02:20:13PM +0300, Yonit Halperin wrote:
On 08/25/2011 02:15 PM, Daniel P. Berrange wrote:
On Thu, Aug 25, 2011 at 02:13:01PM +0300, Yonit Halperin wrote:
On 08/25/2011 01:53 PM, Gerd Hoffmann wrote:
I've played with a app
On 08/26/2011 10:56 AM, Alon Levy wrote:
On Thu, Aug 25, 2011 at 02:20:13PM +0300, Yonit Halperin wrote:
On 08/25/2011 02:15 PM, Daniel P. Berrange wrote:
On Thu, Aug 25, 2011 at 02:13:01PM +0300, Yonit Halperin wrote:
On 08/25/2011 01:53 PM, Gerd Hoffmann wrote:
I've played with a app
Hi,
I'm working on the changes discussed in the thread "changing the timing
of spice client linking in migration (RHBZ #725009)".
In order to be backward compatible with respect to spice-server and qemu
we need
(1) new qemu calling the old switch_host if the server is old (instead
of spice_serv
On 09/06/2011 01:03 PM, Gerd Hoffmann wrote:
On 09/06/11 11:54, Yonit Halperin wrote:
Hi,
I'm working on the changes discussed in the thread "changing the timing
of spice client linking in migration (RHBZ #725009)".
In order to be backward compatible with respect to spice-ser
On 09/06/2011 02:03 PM, Gerd Hoffmann wrote:
On 09/06/11 12:14, Yonit Halperin wrote:
On 09/06/2011 01:03 PM, Gerd Hoffmann wrote:
On 09/06/11 11:54, Yonit Halperin wrote:
Hi,
I'm working on the changes discussed in the thread "changing the timing
of spice client linking in migra
On 09/16/2011 11:21 PM, Naga Mohan Pothula wrote:
Hi,
Could anyone please respond to my questions on Image Compression?
Comparision of auto_glz with Quic?
why auto_glz is taken as default?
Hi,
Both GLZ and QUIC are lossless compression algorithms.
Quic uses predictive encoding, while GLZ is di
spice client
connections. Thus, we trigger the connection to the target upon
client_migrate_info
command.
Since I haven't completed testing these patches, they are marked as RFC.
Relevant branches are in cgit.freedesktop.org/~yhalperi/:
qemu/mig.spice.v42
spice-protocol/0.8.mig
spice/
l it receives
SPICE_MSGC_MAIN_MIGRATE_END
from the client.
* After migration starts, the target qemu is blocked and cannot accept new
spice client
connections. Thus, we trigger the connection to the target upon
client_migrate_info
command.
Signed-off-by: Yonit Halperin
---
Signed-off-by: Yonit Halperin
---
server/reds.c | 15 +++
server/reds.h |4
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index f082c53..05ebf6e 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -73,6 +73,7 @@ static
Signed-off-by: Yonit Halperin
---
server/reds.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 05ebf6e..31f34e2 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -4874,11 +4874,20 @@ SPICE_GNUC_VISIBLE int
Signed-off-by: Yonit Halperin
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3a86515..e169f36 100644
--- a/configure.ac
+++ b/configure.ac
@@ -126,7 +126,7 @@ fi
dnl
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_info
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR), or a timeout,
in order
to complete client_migrate_info monitor command
Signed-off-by: Yonit Halperin
---
common/messages.h |2 +
server/reds.c | 104
Signed-off-by: Yonit Halperin
---
spice.proto |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/spice.proto b/spice.proto
index d5b954e..235ec95 100644
--- a/spice.proto
+++ b/spice.proto
@@ -219,6 +219,8 @@ channel MainChannel : BaseChannel {
uint8
Signed-off-by: Yonit Halperin
---
server/reds.c | 79
1 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 4aa2afb..a0a4924 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -275,6 +275,7
Signed-off-by: Yonit Halperin
---
server/reds.c | 56 +---
1 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index a0a4924..e8544df 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2078,6
Signed-off-by: Yonit Halperin
---
server/reds.c | 68 +++-
1 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index e8544df..bd9a874 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2612,12
(1) not sending anything to the client till we recieve SPICE_MSGC_MIGRATE_END
(2) start a new migration (handle client_migrate_info) only after
SPICE_MSGC_MIGRATE_END
from the previous migration has been received
Signed-off-by: Yonit Halperin
---
server/reds.c | 125
We will add a qemu call to spice_server_migrate_start when migration starts.
For now, it does nothing, but we may need this notification in the future.
Signed-off-by: Yonit Halperin
---
server/reds.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/server/reds.c b
use std::map instead of a specific template (CHash).
There is no need for special template. Moreover, using
std::map will allow easy iteration over the surfaces.
Signed-off-by: Yonit Halperin
---
client/canvas.cpp | 25 +++-
client/canvas.h| 152
Signed-off-by: Yonit Halperin
---
client/application.cpp | 57 ++--
client/red_peer.cpp| 51 ++
client/red_peer.h |2 +-
3 files changed, 59 insertions(+), 51 deletions(-)
diff --git a/client
RHBZ 725009, 738270
Signed-off-by: Yonit Halperin
---
client/red_client.cpp | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/client/red_client.cpp b/client/red_client.cpp
index 3de359d..a7f9cba 100644
--- a/client/red_client.cpp
+++ b/client
(1) disconnect all channels from the migration src
(2) after all channels are disconnected, clean global resources
(3) send SPICE_MSGC_MAIN_MIGRATE_END to migration target
(4) wait for SPICE_MSG_MAIN_INIT
(4) switch all channels to migration target
Signed-off-by: Yonit Halperin
---
client
1 - 100 of 941 matches
Mail list logo
