On 05/04/2011 12:05 PM, Daniel P. Berrange wrote:
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might be responsible of a crash in
On 05/04/2011 12:05 PM, Daniel P. Berrange wrote:
On Wed, May 04, 2011 at 07:52:37PM +0400, Emre Erenoglu wrote:
Hi,
Please see the below discussion with the spice community.
libvirt is adding a parameter about video ram to qemu process and this
parameter might be responsible of a crash in
Hello, using F14+virt-preview:
spice-server-0.8.0-2.fc14.x86_64
libvirt-0.8.8-4.fc14.x86_64
virt-manager-0.8.7-3.fc14.noarch
qemu-kvm-0.14.0-7.fc14.x86_64
Windows 7 32 bit guest
and trying to use skype, I'm able to open the application and hear the
typical sound right after startup but after a
On Sun, May 8, 2011 at 12:12 PM, Gianluca Cecchi
gianluca.cec...@gmail.comwrote:
Hello, using F14+virt-preview:
spice-server-0.8.0-2.fc14.x86_64
libvirt-0.8.8-4.fc14.x86_64
virt-manager-0.8.7-3.fc14.noarch
qemu-kvm-0.14.0-7.fc14.x86_64
Windows 7 32 bit guest
and trying to use skype, I'm
On Sun, May 8, 2011 at 10:18 AM, Emre Erenoglu wrote:
Hi Gianluca,
I can run skype in 32 bit Win2k3 with the AC97 sound card. The sound comes
out OK, but the recording has a lot of distortions and is not
understandable/usable.
I don't know how to debug it. Since yours is Windows 7, I guess
On 05/08/2011 11:12 AM, Gianluca Cecchi wrote:
Hello, using F14+virt-preview:
spice-server-0.8.0-2.fc14.x86_64
libvirt-0.8.8-4.fc14.x86_64
virt-manager-0.8.7-3.fc14.noarch
qemu-kvm-0.14.0-7.fc14.x86_64
Windows 7 32 bit guest
and trying to use skype, I'm able to open the application and hear the
On 05/08/2011 12:20 PM, Gianluca Cecchi wrote:
On Sun, May 8, 2011 at 10:57 AM, Yaniv Kaulyk...@redhat.com wrote:
Windows 7 32 bit guest
and trying to use skype, I'm able to open the application and hear the
typical sound right after startup but after a few seconds I get an
error and need to
On Sun, May 8, 2011 at 12:29 PM, Gianluca Cecchi
gianluca.cec...@gmail.comwrote:
On Sun, May 8, 2011 at 10:18 AM, Emre Erenoglu wrote:
Hi Gianluca,
I can run skype in 32 bit Win2k3 with the AC97 sound card. The sound
comes
out OK, but the recording has a lot of distortions and is not
I think having a xcode project would be quite nice. Furthermore a cocoa
client completely based on spice-client-glib would be the better option
compared to (native) gtk imho. I guess having a look at the Cord project
(http://cord.sourceforge.net/) might be a good start (they ported freeRDP
into a
two small fixes for red_worker extracted from the pending RFC for multiple
clients, plus a small fix for a tester.
Alon Levy (3):
server/tests: show port to connect to
server/red_worker: make stat_now static
server/red_worker: fix typo (lats_send_time)
server/red_worker.c |
---
server/tests/test_display_base.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/server/tests/test_display_base.c b/server/tests/test_display_base.c
index 104ab37..76817d9 100644
--- a/server/tests/test_display_base.c
+++ b/server/tests/test_display_base.c
@@
---
server/red_worker.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 08096f8..264b66f 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -382,7 +382,7 @@ typedef struct StreamAgent {
PipeItem
On Sun, May 08, 2011 at 03:43:21PM +0400, Emre Erenoglu wrote:
Dear Developers,
I'm the package maintainer for some virtualization related packages in
Pardus distribution. I would like to take spice into our package
repositories, however, I'm facing an issue with the celt package.
I'm
On Sun, May 8, 2011 at 4:38 PM, Alon Levy al...@redhat.com wrote:
On Sun, May 08, 2011 at 03:43:21PM +0400, Emre Erenoglu wrote:
Dear Developers,
I'm the package maintainer for some virtualization related packages in
Pardus distribution. I would like to take spice into our package
changes from previous (v4) after Marc-Andre's review:
Surfaces struct renamed to RedRender
patch count reduction.
reduction of argument count (makes search replace patches more readable too)
some other cleanups. I'm sure I missed a few.
to turn on multiple client support you need to set
rename types - we use _proc suffix mostly to indicate function pointer types,
use it for some function pointers that were missing it.
s/channel_handle_migrate_flush_mark/channel_handle_migrate_flush_mark_proc/
s/channel_handle_migrate_data_get_serial/channel_handle_migrate_data_get_serial_proc/
The only difference between them being that the later also does a push.
I don't believe that to be a problem, but if it does I can always introduce
a push'less version.
---
server/red_client_cache.h |2 +-
server/red_worker.c |9 +
2 files changed, 2 insertions(+), 9
---
server/red_channel.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 593e418..6f8d73e 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -581,6 +581,11 @@ void red_channel_client_push(RedChannelClient
They were globals before. This introduces api for other channels
to query the low bandwidth status. The queries themselves are still done
from the wrong context (channel and not channel client) but that's because
the decoupling of channel and channel client will be done in the following
patches.
cleanup only. Note that the ping function is half used since the opt parameter
stopped being called with anything but NULL, should be returned at some point,
specifically when we drop the 250kbyte ping on start and do a continuous check
for latency and bandwidth.
See:
81945d897 - server: add new
Expose additional api to find a client given a connection_id. The connection_id
is first set when the first channel connects, which is the main channel.
It could also be kept in the RedClient instead, not sure.
TODO:
multiple todo's added for multiclient handling. I don't remember why
I wrote
---
server/red_worker.c | 93 ++-
1 files changed, 55 insertions(+), 38 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index f3de49f..9ccd80e 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -952,7 +952,8 @@
---
server/red_worker.c | 99 +-
1 files changed, 57 insertions(+), 42 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 3fbc7d1..c2e1623 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -1194,7 +1194,7 @@
Currently set by environment variable SPICE_DEBUG_ALLOW_MC (any value means
to allow multiple connections). Later will be set by spice api from qemu.
---
server/reds.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index
with multiple clients any surface creation or deletion cleanup needs to
wait until all the clients have been sent the command, so add reference
counting to the create and destroy release calls.
Also introduces the SURFACES_FOREACH macro, a bit ugly due to the need
to update multiple variables and
handle_dev_destroy_surface_wait: all clients render state
handle_dev_destroy_surfaces: clear all surfaces
handle_dev_destroy_primary_surface: clear all primary copies
handle_dev_input RED_WORKER_MESSAGE_STOP: all clients
red_worker_main: call red_handle_streams_timeout for all clients
---
---
server/red_worker.c | 77 +-
1 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 77b731a..78d2db2 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -8438,86 +8438,69 @@
Required to support multiple clients.
Also changes somewhat the way we produce PIPE_ITEM_TYPE_LOCAL_CURSOR. Btw,
I haven't managed to see when we actually produce such an item during my
tests.
Previously we had a single pipe item per CursorItem, this is impossible
with two pipes, which happens
makes RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT disconnect only a
single client.
---
server/red_worker.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 3fe5832..d911613 100644
--- a/server/red_worker.c
+++
check for dcc!=NULL before adding to pipe in several places.
---
server/red_worker.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index d911613..9a7fca9 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
We need to have a different id for each client, otherwise we get a reference to
other client's cache, and of course we don't sync with the new client.
NOTE: This is quite strange - why are we using a client provided id? only makes
sense
for migration (it already has cache, we get cache by
Add cursor allocation debugging code that is turned off as long as
DEBUG_CURSORS is not defined.
---
server/red_worker.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 1e6f495..43373af 100644
---
handle_dev_update does area_update, i.e. rendering to a surface (usually
the primary, surface 0) on request of the driver. Since we only use a single
canvas for each surface on the device memory (the rest are in host memory),
this patch may not really be required.
Testing with and without this
---
client/red_channel.cpp | 40 +---
1 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/client/red_channel.cpp b/client/red_channel.cpp
index d8dcc42..013a5a4 100644
--- a/client/red_channel.cpp
+++ b/client/red_channel.cpp
@@ -173,23 +173,33
On 05/08/2011 04:11 PM, Alon Levy wrote:
---
client/red_channel.cpp | 40 +---
1 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/client/red_channel.cpp b/client/red_channel.cpp
index d8dcc42..013a5a4 100644
--- a/client/red_channel.cpp
+++
On Sun, May 08, 2011 at 04:44:55PM +0300, Yaniv Kaul wrote:
On 05/08/2011 04:11 PM, Alon Levy wrote:
---
client/red_channel.cpp | 40 +---
1 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/client/red_channel.cpp b/client/red_channel.cpp
in next revision (v6) this will be folded into the patch that introduced
the bug. update_area is a request from the guest to render everything affecting
a specific area so the guest can read the contents directly via the pci bar
surface. The operations were wrongly performed more then once. This
On Sun, May 8, 2011 at 2:27 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index b8d6a96..08096f8 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
ack all (see my comment for 2/3)
On Sun, May 8, 2011 at 2:27 PM, Alon Levy al...@redhat.com wrote:
two small fixes for red_worker extracted from the pending RFC for multiple
clients, plus a small fix for a tester.
Alon Levy (3):
server/tests: show port to connect to
server/red_worker:
On Mon, May 09, 2011 at 12:32:25AM +0200, Marc-André Lureau wrote:
On Sun, May 8, 2011 at 2:27 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index
On Sun, May 08, 2011 at 05:06:46PM +0300, Alon Levy wrote:
in next revision (v6) this will be folded into the patch that introduced
the bug. update_area is a request from the guest to render everything
affecting
a specific area so the guest can read the contents directly via the pci bar
41 matches
Mail list logo
