Hi,
Someone know bout this backend render supporting ?
Thanks,
- Jojo
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
On 04/24/2013 07:24 PM, Frank Fraijo wrote:
I have RH Desktop Virt 6.4 running on a physical server. I'm able to get spice
running on it with no issue. At my local windowsXP work station, I've
installed the latest Virtviewer ( spice windows download ).
I'm not able to connect. I've tried
---
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)
---
server/red_channel.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 9d71543..7fde50d 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1680,6 +1680,7 @@ static void
spice_channel_client_error prints warning and shutdowns the
channel_client that hit the error.
This macro is useful for errors that are specific for one session
and that are unrecoverable only with respect to this session.
Prefer disconnecting a client over aborting when possible.
---
---
server/red_channel.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 7fde50d..b738a80 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1275,14 +1275,17 @@ static void
ack
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
---
server/red_worker.c | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 247f153..f12d8f8 100644
---
you could fix the spelling while you are modifying that line :) unexcpected
- unexpected
ack
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
---
server/red_channel.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/server/red_channel.c
ack
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
spice_channel_client_error prints warning and shutdowns the
channel_client that hit the error.
This macro is useful for errors that are specific for one session
and that are unrecoverable only with respect to this
ack
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
---
server/red_channel.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 9d71543..7fde50d 100644
--- a/server/red_channel.c
+++
What is the motivation for doing that? The client could want to save
bandwidth by closing a display channel, or he might want to disable all
inputs temporarily.
And also, similarly, do you think the server should enforce that the client
connect to all the mandatory channels? And how?
On Wed,
ack (I am really scared by this conditional free there!! it's a recipe for
disasters)
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
---
server/reds.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index
ack (would be nice to describe the motivation, although I guess it is to
avoid code duplication)
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
---
server/main_dispatcher.c | 5 +
server/reds.c| 19 ++-
server/reds.h|
ack (somehow I missed that we already had a is_low_bandwidth flag in
migration data!)
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
rhbz#956345
After a spice session has been migrated, we don't retest the network
(user experience considerations). Instead, we
ack
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
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 |
ack
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com wrote:
---
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
rhbz #951618
---
vdagent/vdagent.cpp | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/vdagent/vdagent.cpp b/vdagent/vdagent.cpp
index 1fad0e6..3c0f829 100644
--- a/vdagent/vdagent.cpp
+++ b/vdagent/vdagent.cpp
@@ -979,9 +979,12 @@ void
On 05/08/2013 10:46 AM, Marc-André Lureau wrote:
What is the motivation for doing that? The client could want to save
bandwidth by closing a display channel, or he might want to disable all
inputs temporarily.
If these channels were already connected, I believe it is better to
close the
On Wed, May 8, 2013 at 4:55 PM, Yonit Halperin yhalp...@redhat.com wrote:
If these channels were already connected, I believe it is better to close
the client, than having the user don't understand why suddenly the display
is frozen, or why his keyboard and mouse don't work.
I guess you are
On 05/08/2013 10:46 AM, Marc-André Lureau wrote:
ack (would be nice to describe the motivation, although I guess it is to
avoid code duplication)
Sure, I'll add a comment. I did it because I believe main_dispatcher
role is only to pass events to the main thread, and not handle the
events by
vdagent is stopped, so a new instance is to be launched by vdservice.
imho, this seems simpler than cleaning agent in/out msg state and
reseting the vio-serial device to cleanup pending msgs.
rhbz #956133
---
vdagent/vdagent.cpp |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff
Looks good, ack series.
On 05/08/2013 05:01 PM, Arnon Gilboa wrote:
vdagent is stopped, so a new instance is to be launched by vdservice.
imho, this seems simpler than cleaning agent in/out msg state and
reseting the vio-serial device to cleanup pending msgs.
rhbz #956133
---
On 05/08/2013 10:55 AM, Marc-André Lureau wrote:
On Wed, May 8, 2013 at 4:55 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
If these channels were already connected, I believe it is better to
close the client, than having the user don't understand why suddenly
On Wed, May 8, 2013 at 5:03 PM, Yonit Halperin yhalp...@redhat.com wrote:
I can live with that. Maybe we should add to spice-gtk a user notification
when a channel gets suddenly disconnected.
Since UI don't share same designs, the best place for such dialog is
virt-viewer (or Boxes etc).
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 ++
1 file changed, 30 insertions(+), 12
Spice-gtk does a bit of client-side work by optionnally delaying sending
the monitor configuration to the guest automatically. However, the
client may be slow to set all the monitors, so teach the timer to not
fire the event unless at least the number of monitors set explicitely
enabled or
This avoid some configuration races when connecting to a multi-channel
display server which is slow to set up.
Would you mind describing the symptoms of that race?
I'm puzzled by a nasty glitch, and it has monitor config issues
as a symptom. So of course, you have a hammer - and I'm wondering
32 matches
Mail list logo
