On 10/28/2013 11:34 AM, Marc-André Lureau wrote:
On Thu, Oct 24, 2013 at 5:29 PM, Yonit Halperin yhalp...@redhat.com wrote:
http://cgit.freedesktop.org/~yhalperi/spice-common/
branch bitmap-crop.mem-control
Regarding quic: add x-offset option to bitmap encoding, wouldn't you
be able
Hi,
You can find some optimizations I made to spice-server under:
http://cgit.freedesktop.org/~yhalperi/spice/
branch bitmap-crop.mem-control
together with:
http://cgit.freedesktop.org/~yhalperi/spice-common/
branch bitmap-crop.mem-control
The first set of patches (till commit a5100670f,
Hi,
Thanks for the presentation.
I agree with Marc-André that I wouldn't be so decisive with Host-side
rendering is the only feasible solution. I am not convinced yet that
video encoding can be better than using smart compression and caching of
3D objects and client side rendering, at least
Hi,
I think the hardcoded limit was intended for limiting the occupancy of
the dev ram with drawables that are referenced by the display channel.
If the limit is reasonable it should help with keeping allocations in
the driver fluent, and avoiding IO_OOM.
An alternative approach is to monitor
(1) merge 'force' and 'wait_for_outgoing_item' to one parameter.
'wait_for_outgoing_item' is a derivative of 'force'.
(2) move the call to red_wait_outgoing_item to
red_clear_surface_drawables_from_pipe
---
server/red_worker.c | 30 ++
1 file changed, 18
rhbz#1004443
The methods that trigger waitings on the client pipe require that
the waiting will succeed in order to continue, or otherwise, that
all the living pipe items will be released (e.g., when
we must destroy a surface, we need that all its related pipe items will
be released). Shutdown of
(1) receive timeout as a parameter.
(2) add a return value and pass the handling
of failures to the calling routine.
---
server/red_channel.c | 73 ++--
server/red_channel.h | 22 ++--
server/red_worker.c | 55
rhbz#1004443
The methods that trigger waitings on the client pipe require that
the waiting will succeed in order to continue, or otherwise, that
all the living pipe items will be released (e.g., when
we must destroy a surface, we need that all its related pipe items will
be released). Shutdown of
(1) receive timeout as a parameter.
(2) add a return value and pass the handling
of failures to the calling routine.
---
server/red_channel.c | 73 ++--
server/red_channel.h | 22 ++--
server/red_worker.c | 55
(1) merge 'force' and 'wait_for_outgoing_item' to one parameter.
'wait_for_outgoing_item' is a derivative of 'force'.
(2) move the call to red_wait_outgoing_item to
red_clear_surface_drawables_from_pipe
---
server/red_worker.c | 30 ++
1 file changed, 18
PM, Yonit Halperin yhalp...@redhat.com wrote:
rhbz#1004443
The methods that trigger waitings on the client pipe require that
the waiting will succeed in order to continue, or otherwise, that
all the living pipe items will be released (e.g., when
we must destroy a surface, we need that all its
On 09/18/2013 09:37 AM, Marc-André Lureau wrote:
On Wed, Sep 18, 2013 at 3:34 PM, Yonit Halperin yhalp...@redhat.com wrote:
On 09/18/2013 09:19 AM, Marc-André Lureau wrote:
Hi
On Wed, Sep 18, 2013 at 2:58 PM, Yonit Halperin yhalp...@redhat.com
wrote:
Hi,
On 09/17/2013 12:11 PM, Marc
Hi,
On 09/17/2013 12:11 PM, Marc-André Lureau wrote:
On Mon, Sep 16, 2013 at 5:34 PM, Yonit Halperin yhalp...@redhat.com wrote:
Hi,
'force' means: wait till there is no pipe item that references the surface.
If force = FALSE, try to release any such pipe item, but as long as it
doesn't
On 09/18/2013 09:19 AM, Marc-André Lureau wrote:
Hi
On Wed, Sep 18, 2013 at 2:58 PM, Yonit Halperin yhalp...@redhat.com wrote:
Hi,
On 09/17/2013 12:11 PM, Marc-André Lureau wrote:
On Mon, Sep 16, 2013 at 5:34 PM, Yonit Halperin yhalp...@redhat.com
wrote:
Hi,
'force' means: wait till
this comments to the code if it helps.
If you could clarified the above, and comment it in the code that
would be helpful! :)
On Thu, Sep 12, 2013 at 10:04 PM, Yonit Halperin yhalp...@redhat.com wrote:
(1) merge 'force' and 'wait_for_outgoing_item' to one parameter.
'wait_for_outgoing_item
(1) merge 'force' and 'wait_for_outgoing_item' to one parameter.
'wait_for_outgoing_item' is a derivative of 'force'.
(2) move the call to red_wait_outgoing_item to
red_clear_surface_drawables_from_pipe
---
server/red_worker.c | 20 +++-
1 file changed, 11 insertions(+), 9
rhbz#1004443
The methods that trigger waitings on the client pipe require that
the waiting will succeed in order to continue, or otherwise, that
all the living pipe items will be released (e.g., when
we must destroy a surface, we need that all its related pipe items will
be released). Shutdown of
(1) receive timeout as a parameter.
(2) add a return value and pass the handling
of failures to the calling routine.
---
server/red_channel.c | 73 ++--
server/red_channel.h | 22 ++--
server/red_worker.c | 53
ACK
The rest of the patches that haven't been acked in this series, are the
same as in the previous series, right? If so, ack series.
Cheers,
Yonit.
On 09/12/2013 08:09 AM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
The current coroutine channel_iterate()
Ack
On 09/10/2013 05:27 PM, Marc-André Lureau wrote:
This is actually for spice-common (although spice-gtk will need later then)
and also spice-protocol
On Tue, Sep 10, 2013 at 11:13 PM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
Make it explicit that 100 is the last value of the
On 09/10/2013 10:44 AM, Marc-André Lureau wrote:
Allow to disable selectively channels, mainly used for testing,
ex: SPICE_DISABLE_CHANNELS=display spicy-stats -p 12345
---
gtk/spice-channel-priv.h | 2 ++
gtk/spice-channel.c | 7 +++
2 files changed, 9 insertions(+)
diff --git
This reverts commit 49feefa95d3595f04355c4aed53ec5bf26551046.
The patch causes the display to get stuck. Till we understand exactly
why, I'm reverting it.
---
xddm/miniport/qxl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xddm/miniport/qxl.c b/xddm/miniport/qxl.c
index ce37f07..f5d6b48
Hi,
In general it looks good, but I have several comments:
(1) the palette cache shouldn't be shared among the display channels.
I.e., there should be one instance per channel, and not one instance in
spice-session.
(2) I think you changed the ref_count logic of cache item. Now each
cache
ack, but what happens when g_slice_new fails? the spice_new and other
spice malloc functions handle mallocs that fail and abort in such cases.
On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
---
gtk/channel-display.c | 4 ++--
On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
Checking by value make the flag fields useless.Uunfortunately, when
adding more flags, the server will have to ensure it can safely send it,
by checking some of new client caps.
Good catch. Can you also add a comment about this to spice-protcol
ack.
Notice that basically handle_msg of all the channels does the same,
expect it uses different msg handlers. It would have been cleaner to use
one handle_msg routine, and different msg handlers. Then, instead of
checking disable_channel_msg for each msg, we could just set the
msg_handlers
ack
On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
Improve a bit the code by using hashtable ownership.
---
gtk/channel-display.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index 7a66558..979ce7b 100644
ack
On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
That doesn't seem to really improve performance so much,
but that' s what we should do probably.
---
gtk/spice-util.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
Hi,
I think that iterate_write iterate_read should be symmetrical: in the
same way iterate_write handles all outgoing messages, iterate_read
should flush all incoming messages (i.e., the loop in
spice_channel_iterate can be moved to iterate_read).
But I'll ack it even if you don't change
ack
On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
Avoid hard-coding surface 0 as being primary, although in practice it
always is so far. Also a lot of lookups are primary, so add a shortcut
for this special case (~30% apparently), it shows some small lookup
speedup.
before:
real
Looks good. see comment bellow.
On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
Use of coroutines allow to simplify spice_channel_recv_msg(), it doesn't
need to keep current reading state, it can rely on the coroutine stack
for that.
---
Hi,
On 08/26/2013 02:43 AM, 天知道 wrote:
Hi,
When a video is playing, the client is turned on and off every two seconds.
Then assert error appears in certain time given information on the stack。
What do you mean by the client is turned on and off every two
seconds?. What are the server and
---
server/spice_bitmap_utils.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/server/spice_bitmap_utils.c b/server/spice_bitmap_utils.c
index ce0a5ed..7b370a0 100644
--- a/server/spice_bitmap_utils.c
+++ b/server/spice_bitmap_utils.c
@@ -63,7 +63,7 @@ void
---
server/red_worker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 7f1aeda..0c611d0 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -6629,7 +6629,7 @@ static FillBitsType fill_bits(DisplayChannelClient *dcc,
Hi,
I don't know much about the inf file, but the patch looks ok, as long as
the FeatureScore is ignored on WindowsXp. However, how does this patch
fix 728259? IIUC 728259 should be fixed by generating different inf
file for different operating systems.
Also, why does FeatureScore = FC ?
For channels that don't run as part of the main loop, we use
spice_timer_queue, while for the other channels we use
qemu timers support. The callbacks for setting timers are supplied to
red_channel via SpiceCoreInterface, and their behavior should be
consistent. qemu timers are called only once
The callback will be used in the next patch.
---
server/red_channel.c | 7 +++
server/red_channel.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/server/red_channel.c b/server/red_channel.c
index 37b0c1c..bcf5a60 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -251,6
rhbz#994175
When a client connection is closed surprisingly (i.e., without a FIN
segment), we cannot identify it by a socket error (which is the only
way by which we identified disconnections so far).
This patch allows a channel client to periodically check the state of
the connection and
Looks good. Ack.
On 08/13/2013 03:47 AM, Alon Levy wrote:
Moving ~500 lines out of red_worker.
v2-v3:
* ref/unref of red_channel_client_wait_pipe_item_sent inside it, red_worker
just calls it.
* renames requested.
Alon Levy (10):
red_worker: mark DRAW_ALL as broken
Hi,
You forgot to add spice_server_utils.h :)
Yonit.
On 08/12/2013 08:49 AM, Alon Levy wrote:
---
server/Makefile.am | 1 +
server/red_dispatcher.c | 4 +++-
server/red_worker.c | 1 +
server/red_worker.h | 18 --
4 files changed, 5 insertions(+), 19
Hi,
Just a nitpick (below)
On 08/12/2013 08:49 AM, Alon Levy wrote:
---
server/Makefile.am | 2 +
server/red_worker.c | 157 ++--
server/spice_bitmap_utils.c | 152 ++
Hi,
red_time.h is missing.
On 08/12/2013 11:32 AM, Alon Levy wrote:
Three blocking functions, one was split to leave the display channel
specific referencing of the DrawablePipeItem being sent inside
red_worker, but the rest (most) of the timeout logic was moved to
red_channel, including the
Hi,
I think red_channel_client_wait_pipe_item_sent should ref and unref the
pipe item by itself (using the hold/release-item callbacks). Then, you
don't need dcc_wait_pipe_item_sent.
Also, I'm not sure why PUSH_TIMEOUT is bigger than DETACH timeout. It
would have been logical if the bigger
On 08/12/2013 12:32 PM, Alon Levy wrote:
Hi,
I think red_channel_client_wait_pipe_item_sent should ref and unref the
pipe item by itself (using the hold/release-item callbacks). Then, you
don't need dcc_wait_pipe_item_sent.
This is a bit scarier then my mechanical change. Since there are two
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other existing related bugs emphasize why it is important to decrease
the
should be PATCH 1/1 :)
On 08/06/2013 02:51 PM, Yonit Halperin wrote:
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other
---
gtk/usb-device-manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/usb-device-manager.c b/gtk/usb-device-manager.c
index 0535609..71d3462 100644
--- a/gtk/usb-device-manager.c
+++ b/gtk/usb-device-manager.c
@@ -329,10 +329,10 @@ static gboolean
Ack
On 07/29/2013 09:14 AM, Alon Levy wrote:
Alternative is to leak, and this happens regularely. Perhaps we should
be keeping track and destroying these surfaces later (in case no reset
happens in the middle, which destroys all off screen surfaces anyway).
---
display/driver.c | 5 +
1
Ack
On 07/26/2013 02:43 PM, Alon Levy wrote:
---
display/brush.c | 4 +++-
display/driver.c | 2 ++
display/pointer.c | 8
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/display/brush.c b/display/brush.c
index 0b9400d..fe94f1c 100644
--- a/display/brush.c
+++
Fixes: leaks of pipe items red_client_destroy: assertion
`rcc-send_data.size == 0'
red_channel_disconnect clears the pipe. It is called only once. After,
it was called, not items should be added to the pipe.
An example of when this assert can occur:
on_new_cursor_channel (red_worker.c), pushes
---
server/red_channel.c | 23 ---
server/red_channel.h | 17 +++--
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index a35da9b..9b5e314 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@
When the sequence of calls bellow occurs, the PlaybackChannel
is not released (snd_channel_put is not called for the
samples that refer to the channel).
spice_server_playback_get_buffer
snd_channel_disconnect
spice_server_playback_put_samples
---
server/snd_worker.c | 9 -
1
---
server/red_channel.c | 9 ++---
server/snd_worker.c | 7 ---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 9b5e314..89b4092 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1109,6 +1109,7 @@ static
The snd channels has one reference as long as their socket is active.
The playback channel has an additional reference for each frame that is
currently filled by the sound device.
Once the channel is disconnected (the socket has been freed and the
first reference is released)
Fixes rhbz#918169
Some channels make direct calls to reds/main_channel routines. If
these routines try to read/write to the socket, and they get socket
error, main_channel_client_on_disconnect is called, and triggers
red_client_destroy. In order to prevent accessing expired references
to
When we want to disconnect the main channel from a callback, it is
safer to use red_channel_client_shutdown, instead of directly
destroying the client. It is also more consistent with how other
channels treat errors.
red_channel_client_shutdown will trigger socket error in the main channel.
Then,
Hi,
On 07/22/2013 08:04 AM, Alexandre DERUMIER wrote:
Hi,
I'm trying to do migration, and I have a question about password on target vm.
If I understand, client try to connect to target vm with same password
(temporary ticket) used to connect to source vm.
But, we need to configure this
Ack.
The ping is sent over the display channel to check an upper limit for
the roundtrip time. If the tcp stack is busy, we postpone the ping.
So, without the ioctl, when the tcp stack is busy, the roundtrip
estimation will probably be much bigger than the real one. However, we
currently
On 07/22/2013 12:50 PM, Marc-André Lureau wrote:
Hi
- Mensaje original -
Hi,
On 07/22/2013 08:04 AM, Alexandre DERUMIER wrote:
Hi,
I'm trying to do migration, and I have a question about password on target
vm.
If I understand, client try to connect to target vm with same password
Ack
On 07/18/2013 11:04 AM, Nahum Shalman wrote:
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index edda8e9..a549ed9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@ m4_define([SPICE_AGE], [8])
# Note on
ACK.
Maybe Arnon knows more about the version scheme.
On 07/17/2013 10:15 AM, Alon Levy wrote:
We haven't done this for most any change. Perhaps we should do this? No
idea what the x.y.z.w convention is, so I made the most minor change
right now. But the date is the important bit.
---
Hi,
On 07/02/2013 10:47 AM, Matilde Yanez wrote:
2013/7/2 Yonit Halperin yhalp...@redhat.com mailto:yhalp...@redhat.com
On 07/02/2013 10:22 AM, Matilde Yanez wrote:
Hi,
thanks for answers.
2013/7/2 Yonit Halperin yhalp...@redhat.com
mailto:yhalp
Hi,
On 07/08/2013 06:32 AM, Uri Lublin wrote:
RCC_FOREACH may be dangerous
The following patches replace FOREACH loops with a SAFE version.
Using unsafe loops may cause spice-server to abort (assert fails).
Specifically a read/write fail in those loops, may cause the client
to disconnect,
Ack Series,
with the comment that the actual risky places that cause the crash, may
better use safe red_channel.c routines instead. But it can be done later.
On 07/08/2013 06:32 AM, Uri Lublin wrote:
If in RING_FOREACH (in == somewhere in the callee-tree) there is
a call to read or write, it
Ack. Thanks! We have recently associated this problem with some opened
bugs we have. I believe Uri is working on a patch for a similar fix to
the red_pipes.* routines in red_worker.
On 07/05/2013 03:11 AM, David Gibson wrote:
Currently, both red_channel_pipes_add_type() and
rhbz#968050
In contrast to Microsoft Msdn documentation, the iUniq of a SURFOBJ doesn't
always change when the surface changes. However, it seems that the
iUniq of the associated color_trans (XLATEOBJ) changes, while its
flXlate=XO_TRIVIAL. Since we tried to retrieve the alpha bitmap key
only by
Hi,
On 07/01/2013 04:27 AM, Matilde Yanez wrote:
Hello,
I need some information about video detection, on VM.
When I am on web pages, or documents, with images the VM seems to detect
video and start the mjpeg_encoder process.
Thus, the display is slows down.
What vm are you using? We
On 07/02/2013 10:22 AM, Matilde Yanez wrote:
Hi,
thanks for answers.
2013/7/2 Yonit Halperin yhalp...@redhat.com mailto:yhalp...@redhat.com
Hi,
On 07/01/2013 04:27 AM, Matilde Yanez wrote:
Hello,
I need some information about video detection, on VM.
When I
Hi All,
I'm happy to announce a new spice-protocol release in the stable
spice-0.12.x series
Changes in spice-protocol-0.12.6
* Add adaptive video streaming support:
control playback latency and receive playback
reports from the client.
* Add agent
option for remote-viewer. You can change the
size of the cache and see if it improves the performance. Then we can
consider implementing caching on disk, and not only memory.
Cheers,
Yonit.
thanks.
At 2013-06-19 01:44:29,Yonit Halperin yhalp...@redhat.com wrote:
Hi,
On 06/18/2013 10:33 AM
---
NEWS | 7 +++
configure.ac | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index a602292..23b83d2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,10 @@
+Major changes in 0.12.6
+===
+* add adaptive video streaming support:
+ control
The image descriptor flags shouldn't be copied as is from the flags that
were set by the driver. Specifically, the CACHE_ME flag shouldn't be copied,
since it is possible that (a) the image won't be cached (b) the image
is already cached, but in its lossy version, and we may want to set the bit
Hi,
For the purpose of disabling guest desktop effects, we already have a
spice-gtk option which we use for Windows guests, and can be used for
Linux guests as well. The Linux agent should support
VD_AGENT_DISPLAY_CONFIG for this.
However, for local usage, we would also like to disable
On 06/23/2013 06:30 AM, Uri Lublin wrote:
On 06/21/2013 04:50 PM, Yonit Halperin wrote:
DebugPrintV first locks print_sem, and then locks io_sem.
async_io, locks io_sem.
In ordr to avoid a deadlock, DebugPrintV MUSTN'T be called when
io_sem is locked.
Also notice, that locking io_sem during
Those messages are too frequent and don't contribute much
---
server/red_channel.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 5662041..c0b1781 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@
also added start/end-bit-rate and avg-quality to the final stream stats.
---
server/mjpeg_encoder.c | 1 -
server/red_worker.c| 22 +++---
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 92aef27..04b244e
---
gtk/channel-display.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index bc6fc08..07f6c1e 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -1511,6 +1511,7 @@ static void
---
server/mjpeg_encoder.c | 11 +++
server/mjpeg_encoder.h | 7 +++
2 files changed, 18 insertions(+)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 4460322..92aef27 100644
--- a/server/mjpeg_encoder.c
+++ b/server/mjpeg_encoder.c
@@ -169,6 +169,7 @@ struct
spice-server supports adaptive video streaming only if the client
publishes SPICE_DISPLAY_CAP_STREAM_REPORT.
Disabling this feature is useful for debugging and performance comparison.
---
gtk/channel-display.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff
rhbz#966835
We do not support copying such bitmaps. But instead of failing
operations that involve such bitmaps we either BSODed (in checked
builds), or proceeded with the bitmap copying (in free builds) - this lead to
an infinite
loop allocating QXLDataChunks without any data, just header.
---
DebugPrintV first locks print_sem, and then locks io_sem.
async_io, locks io_sem.
In ordr to avoid a deadlock, DebugPrintV MUSTN'T be called when
io_sem is locked.
Also notice, that locking io_sem during DebugPrintV limits our ability
to use the log_port for debugging concurrency problems related
Hi,
On 06/18/2013 10:33 AM, bigclouds wrote:
hi,all
i have used spice for a long time,it is good, but in pratice it needs
improvement, like resource usage, network bandwidth,performance.
1.it eats up much cpu on client side, up to 90% when play video. i am
sure whether decompression or
Hi,
Video streaming support involves: (1) lossy compression of video frames
(using jpeg) (2) lip sync (3) frame rate control
Video is detected by identification of high rate updates of the same
region over the primary surface.
off=turn off video streaming support
filter=don't stream as
The assert:
spice_assert(pthread_equal(pthread_self(), client-thread_id))
and the assert:
spice_assert(pthread_equal(pthread_self(), rcc-channel-thread_id))
were coded in order to protect data that is accessed from the main
context (red_client and most of the channels), from
access by threads of
If client_migrate_info was called once with cert-host-subject and
then again without cert-host-subject, on a third call to
client_migrate info, the cert-host-subject from the first call would
have been freed for the second time.
---
server/main_channel.c | 2 ++
1 file changed, 2 insertions(+)
(snd_send_data,
snd_receive).
thanks
在 2013-05-08 23:57:54，Marc-André Lureau marcandre.lur...@gmail.com
写道：
On Wed, May 8, 2013 at 5:03 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
I can live with that. Maybe we should add to spice-gtk a user
.
Yonit Halperin (3):
emit_main_context macro: handle calls from both coroutine context and
main context
spice-session: new signal for notifying on a significant change in
mm-time
channel-display: protect video streaming from temporarily unsynced
mm_time (migration related)
gtk
---
gtk/coroutine.h | 1 +
gtk/spice-channel-priv.h | 12
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gtk/coroutine.h b/gtk/coroutine.h
index 031a97b..a9b3a87 100644
--- a/gtk/coroutine.h
+++ b/gtk/coroutine.h
@@ -55,6 +55,7 @@ struct coroutine
#endif
mm-time can change after migration. This can cause video synchronization
problems after migration if not handled appropriately (see rhbz#951664).
---
gtk/spice-session.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/gtk/spice-session.c
rhbz#951664
When the src and dst servers have different mm-times, we can
hit a case when for a short period of time the session mm-time and
the video mm-time are not synced. If the video mm-time is much
bigger than the session mm-time, the next stream rendering will be
scheduled to (video-mm-time
On 05/09/2013 02:33 AM, bigclouds wrote:
many functions start with 'red', what does it mean?
thanks
That is historical. It stands for Remote Desktop.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
On 05/08/2013 07:27 PM, Yonit Halperin wrote:
When setting an initial video stream bit rate, if the bit rate
wasn't calculated by main_channel_client, and we don't have
estimation from previos streams, use some default values.
---
server/red_worker.c | 42
On 05/09/2013 10:46 AM, Marc-André Lureau wrote:
On Wed, May 1, 2013 at 4:19 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
mm-time can change after migration. This can cause video synchronization
problems after migration if not handled appropriately (see
On 05/09/2013 11:16 AM, Marc-André Lureau wrote:
On Thu, May 9, 2013 at 5:06 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
On 05/09/2013 10:46 AM, Marc-André Lureau wrote:
On Wed, May 1, 2013 at 4:19 PM, Yonit Halperin
yhalp...@redhat.com
---
server/main_channel.c | 10 +-
server/main_channel.h | 6 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index dd927ab..4cf7e19 100644
--- a/server/main_channel.c
+++ b/server/main_channel.c
@@ -164,6 +164,7 @@ enum
Replace the mixed calls to display_channel_client_is_low_bandwidth
and to main_channel_client_is_low_bandwidth, with one flag in
CommonChannelClient that is set upon channel creation.
---
server/red_worker.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
rhbz#956345
After a spice session has been migrated, we don't retest the network
(user experience considerations). Instead, we obtain the is_low_bandwidth flag
from the src-server, via the migration data.
Before this patch, if we migrated from server s1 to s2 and then to s3,
and if the connection
---
server/main_dispatcher.c | 5 +
server/reds.c| 19 ++-
server/reds.h| 4
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/server/main_dispatcher.c b/server/main_dispatcher.c
index 8402402..92b0791 100644
---
---
server/reds.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index a378f80..f6a1ce9 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -196,10 +196,9 @@ static void reds_stream_push_channel_event(RedsStream *s,
int event)
void
---
server/reds.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/server/reds.c b/server/reds.c
index f6a1ce9..38923b0 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -194,12 +194,37 @@ static void reds_stream_push_channel_event(RedsStream *s,
int event)
1 - 100 of 763 matches
Mail list logo
