Then I recommend that we create a library/framework/API so that
companies can use spice much easier programmatically.
Spice-Gtk has a complete API. It allows to create complete clients
without GTK using spice-client-glib.
This is basically a good approach I think - also to use the whole spice
On Mon, May 02, 2011 at 01:48:27PM +0200, Kai Mosebach wrote:
This is basically a good approach I think - also to use the whole spice
client programmatically.
What I would like to see here would be a clean split between the
spice-client-glib (w/o the gtk parts) and spicy(the gtk parts) if
On Mon, May 02, 2011 at 01:59:33PM +0200, Kai Mosebach wrote:
The question is if I could get a libspice-client-glib without gtk at all?
Ah, this should be doable, but you'd need to patch configure.ac and
gtk/Makefile.am for that, patches welcome :)
Christophe
pgplacMiE2Ta6.pgp
Description:
Hi,
Audio is not working in 64-bit Windows7 Guest connected from any Linux/Windows
Client.
I noticed this problem with Spice v0.63/0.8 versions. I haven't tried on other
Spice versions.
When starting Spice Server, we are specifying -soundhw AC97 option
I have read in some forums that Qemu-kvm
Hi Alon,
After a couple of days getting a bit more familiar with the server
code, and reading each patches individually, I have made several
observations and commented some of the patches (see patch reply). I
still don't consider myself familiar enough with the server code to be
really helpful. I
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
each client supplying a smartcard channel gets it's own smartcard. If
there are not enough smartcards provided by the server (read: qemu)
then it will be as though there are none.
currently disabled - later patches that
The ref system is not clear, why is it heap allocated? Some
documentation about that Refs type would help.
Having explicit _ref() and _unref() methods would make things more
clear. Can it be pushed higher in the object hierarchy instead of
having new Refs types?
I am a bit skeptical reading:
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
Introduce functions to add (via producer method) the same item to multiple
pipes, all for the same channel.
Note: Right now there is only a single channel, but the next patches will do
the
per-channel breakdown to channel
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
+static void red_channel_client_unlink(RedChannelClient *rcc)
+{
+ ring_remove(rcc-client_link);
+ rcc-client-channels_num--;
+ ASSERT(rcc-channel-rcc == rcc);
+ rcc-channel-rcc = NULL;
+
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
TODO:
multiple todo's added for multiclient handling. I don't remember why
I wrote them exactly, and besides if I did any migration tests. So: TODO.
I tested simple migration with this commit in branch
- as a reminder, there is too many MainChannelClient typedef, and
build fails (you fixed it in your latest branch, thx).
- there is a few trailing lines added to b/server/red_channel.c
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
The remaining abort is from a double free
could be merged with 03/62 introduce RedChannelClient
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
server/red_channel.c
index 3a28304..5aad98b 100644
--
Marc-André Lureau
___
Spice-devel mailing list
We have these various channel types for main_channel_foo()
argument/return value, would be nice to make some changes:
- Channel *main_channel_init()
reds-main_channel_factory = main_channel_init();
Should we rename main_channel_init() to main_channel_factory_new()?
and perhaps rename Channel to
perhaps rename xxx_connected() - xxx_is_connected() for consistency
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
Instead of checking for worker-{display,cursor}_channel directly.
---
server/red_worker.c | 55 ++
1 files
It looks like it is later reverted in the patch:
server/red_worker: split display and cursor channels
The current code style tends to reserve _proc for function type name
only. Should we try to keep it that way?
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
check for dcc!=NULL before adding to pipe in several places.
Probably useless since red_pipe_add_drawable_*() already check for dcc != NULL.
--
Marc-André Lureau
___
Spice-devel
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/reds.c | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 0ce6f1c..dc73202 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -228,6 +228,7 @@
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
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
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 74 ++
1 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 4402570..6ab3d7c 100644
---
Could be merged with 41/62: server/red_worker: start using SURFACES_FOREACH
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
Are we scheduling each client stream independently?
Also, I never looked at this code before, but my quick understanding
is that we are trying to schedule sending frame on the server side,
although the guest and the client already schedule the frame
themselves. So what the heck are we really
Could be merged with 41/62 start using SURFACES_FOREACH
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index
Could be merged with 41/62 start using SURFACES_FOREACH
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index
Could be merged with 41/62 start using SURFACES_FOREACH
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index
(tbh, I don't understand all the implications of this patch, I have
only a partial view)
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 58 --
1 files changed, 42 insertions(+), 16 deletions(-)
Could be merged with 41/62 start using SURFACES_FOREACH
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index
Can you explain the choice to select arbitrarily some client as the
primary? (why are the clients not treated the same way?)
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 138
+--
1 files
I suppose there is a good reason, but I don't know it.
red_create_surface_item() handles dcc = NULL, so why do we want to
avoid it here?
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 9 ++---
1 files changed, 6 insertions(+), 3
could be merged with 24/62: split Surfaces from RedWorker and 27/62
move streams from RedWorker to Surfaces (especially if you merge 24
and 27 as I proposed)
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 5 -
1 files changed, 4
On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy al...@redhat.com wrote:
When we start having multiple clients each
drawable will be referenced by multiple clients, release happens when all
clients are done with it.
---
server/red_parse_qxl.h | 1 +
server/red_worker.c | 17
Should probably be merged with 37/62 use pipe_size helpers.
It's a bit awkward to have 3 similar functions, even though they will
be completed later on.
A bit of documentation to understand the intended usage could help.
From my understanding,
- sum_pipes_size(): return the sum of all the rcc
Why did you choose to do it seperately from 29/62?
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 4fbcb4f..a700f7e
Why did you choose to do it seperately from 29/62?
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index d6762be..4fbcb4f
Could be merged with 29/62: server/red_worker: split display and cursor channels
I would add the comment in the code.
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
---
server/red_worker.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Ack, could be merged with 03/62 introduce RedChannelClient
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
---
server/red_channel.c | 10 ++
server/red_channel.h | 3 +++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/server/red_channel.c
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
from server events are broadcast - leds change. The rest is client
to server, so it is just passed on.
---
server/inputs_channel.c | 77
+++
1 files changed, 38 insertions(+),
Agreed, but one patch over all spice code base instead of individual
patches would be even better.
On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy al...@redhat.com wrote:
---
server/main_channel.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/server/main_channel.c
On Tue, May 3, 2011 at 1:52 AM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
The ref system is not clear, why is it heap allocated? Some
documentation about that Refs type would help.
Forget the heap allocated part (I am not sure what I meant)
I still find myself confused by that patch
38 matches
Mail list logo
