Re: [Spice-devel] [RFC v4 18/62] server/red_channel: introduce pipes functions

On Tue, May 03, 2011 at 01:52:38AM +0200, Marc-André Lureau wrote: > On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 th

Re: [Spice-devel] [RFC v4 16/62] server/main_channel: move link_id from reds

On Tue, May 03, 2011 at 01:52:52AM +0200, Marc-André Lureau wrote: > On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 s

Re: [Spice-devel] [RFC v4 13/62] server: Add RedClient

On Tue, May 03, 2011 at 01:53:01AM +0200, Marc-André Lureau wrote: > - 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,

Re: [Spice-devel] [RFC v4 54/62] server/red_worker: split cursor pipe item from cursor item

On Tue, May 03, 2011 at 01:54:05AM +0200, Marc-André Lureau wrote: > On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 suc

Re: [Spice-devel] [RFC v4 57/62] server/reds: add RedsState.allow_multiple_clients (temp - add accessors too)

On Tue, May 03, 2011 at 01:53:53AM +0200, Marc-André Lureau wrote: > On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 10064

Re: [Spice-devel] [RFC v4 00/62] server: multiple client support

On Tue, May 03, 2011 at 01:51:46AM +0200, Marc-André Lureau wrote: > 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'

Re: [Spice-devel] Audio Fails in 64-bit Windows7 Guest

On Tue, May 3, 2011 at 2:34 AM, Naga Mohan Pothula < nagamohan.poth...@yahoo.com> wrote: > 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 star

[Spice-devel] jpeg and jpeg_alpha in spice

Hi,All! I've found a problem that when 1. using qxl,thus the image type will be SPICE_BITMAP_FMT_RGBA; 2. and forcing the use of red_jpeg_compress_image ('cause I want to get only JPEG in client) in spice server then SPICE_IMAGE_TYPE_JPEG_ALPHA will be produced,but this will cause the color d

Re: [Spice-devel] [RFC v4 20/62] server/main_channel: support multiple clients

On Tue, May 3, 2011 at 1:52 AM, Marc-André Lureau 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 and all the various Ref

Re: [Spice-devel] [RFC v4 06/62] server/main_channel.c: set NET_TEST_STAGE_INVALID=0 explicitly

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 wrote: > --- >  server/main_channel.c |    2 +- >  1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/server/main_channel.c b/server/main_c

Re: [Spice-devel] [RFC v4 21/62] server/inputs_channel: support multiple clients

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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(+), 39 deletion

Re: [Spice-devel] [RFC v4 22/62] server/red_tunnel_worker: trivial multi client support

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > s/TunnelChannel/TunnelChannelClient/ > > That's about it.  this is probably the wrong way to do it. Not tested > at all. What do we want, a separate interface per client? same interface > for all clients? probably the later. This doesn't do that

Re: [Spice-devel] [RFC v4 28/62] server/red_channel: add two helper functions

Ack, could be merged with 03/62 introduce RedChannelClient On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 b/server/red_

Re: [Spice-devel] [RFC v4 30/62] server/red_worker: don't send redundant create surface to client

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 wrote: > --- >  server/red_worker.c |    2 +- >  1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/server/red_worker.c

Re: [Spice-devel] [RFC v4 31/62] server/red_worker: fix red_pipe_add_drawable_to_tail

Why did you choose to do it seperately from 29/62? On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > --- >  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 2bc0abf..d6762be 100644 > --- a

Re: [Spice-devel] [RFC v4 32/62] server/red_worker: fix red_pipe_get_tail

Why did you choose to do it seperately from 29/62? On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 100644 > --

Re: [Spice-devel] [RFC v4 33/62] server/red_worker: fix red_pipe_remove_drawable

Why did you choose to do it seperately from 29/62? On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 100644 > --

Re: [Spice-devel] [RFC v4 34/62] server/red_worker: remove more direct access to RedChannelClient.rcc

Is the description matching the patch changes? (if it really does, then it could be merged with the next patch 35/62 I suppose) On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > --- >  server/red_worker.c |   97 > ++- >  1 files changed, 57 ins

Re: [Spice-devel] [RFC v4 35/62] server/red_worker: more removal of direct rcc access

It looks like it could be merged with 05/62 move pipe from RedChannel to RedChannelClient On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy wrote: > --- >  server/red_worker.c |   21 + >  1 files changed, 13 insertions(+), 8 deletions(-) > > diff --git a/server/red_worker.c b/server

Re: [Spice-devel] [RFC v4 36/62] server/red_channel: add pipe_size helpers

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 pi

Re: [Spice-devel] [RFC v4 38/62] server/red_channel: introduce client ring in RedChannel

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy wrote: > main_channel and red_worker had several locations that still accessed rcc > directly, so they had to be touched too, but the changes are minimal. > > Most changes are in red_channel: drop the single client reference in > RedChannel > and add a

Re: [Spice-devel] [RFC v4 40/62] server/red_worker: add ref counting to RedDrawable

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 - >  2 f

Re: [Spice-devel] [RFC v4 42/62] server/red_worker: tiny cleanups

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 wrote: > --- >  server/red_worker.c |    5 - >  1 files changed, 4 insertions(+), 1 deletio

Re: [Spice-devel] [RFC v4 43/62] server/red_worker: red_create_surface - check for dcc before sending messages

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 wrote: > --- >  server/red_worker.c |    9 ++--- >  1 files changed, 6 insertions(+), 3 deletions(-) > > diff --

Re: [Spice-devel] [RFC v4 27/62] server/red_worker: move streams from RedWorker to Surfaces

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > Now Surfaces will keep a copy of the current video streams. This is > again just a technical move, no functional changes. ack, could easily be merged with 24/62 server/red_worker: split Surfaces from RedWorker -- Marc-André Lureau ___

Re: [Spice-devel] [RFC v4 45/62] server/red_worker: copy and free new surfaces after first client

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 wrote: > --- >  server/red_worker.c |  138 > +-- >  1 files changed, 134 inse

Re: [Spice-devel] [RFC v4 46/62] server/red_worker: handle_dev_update: for all clients (checkme)

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy wrote: > 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 ma

Re: [Spice-devel] [RFC v4 47/62] server/red_worker: handle_dev_destroy_surface_wait: all clients surfaces

Could be merged with 41/62 start using SURFACES_FOREACH On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 550bda9..9795dab 100644

Re: [Spice-devel] [RFC v4 41/62] server/red_worker: start using SURFACES_FOREACH

(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 wrote: > --- >  server/red_worker.c |   58 -- >  1 files changed, 42 insertions(+), 16 deletions(-) > > diff --git a

Re: [Spice-devel] [RFC v4 48/62] server/red_worker: handle_dev_destroy_surfaces: clear all surfaces

Could be merged with 41/62 start using SURFACES_FOREACH On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 9795dab..ca59

Re: [Spice-devel] [RFC v4 49/62] server/red_worker: handle_dev_destroy_primary_surface: clear all primary copies

Could be merged with 41/62 start using SURFACES_FOREACH On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 ca59662..5fb8a5f 1006

Re: [Spice-devel] [RFC v4 50/62] server/red_worker: handle_dev_input RED_WORKER_MESSAGE_STOP: all clients

Could be merged with 41/62 start using SURFACES_FOREACH On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 5fb8a5f..fe21a4c 10064

Re: [Spice-devel] [RFC v4 51/62] server/red_worker: get_streams_timeout: go over all clients

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 doing

Re: [Spice-devel] [RFC v4 52/62] server/red_worker: red_worker_main: call red_handle_streams_timeout for all clients

Could be merged with 41/62: server/red_worker: start using SURFACES_FOREACH On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 > index 7e022f6.

Re: [Spice-devel] [RFC v4 53/62] server/red_worker: move free from display_channel_send_item to _release_item

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 > --- a/server/

Re: [Spice-devel] [RFC v4 54/62] server/red_worker: split cursor pipe item from cursor item

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 item per C

Re: [Spice-devel] [RFC v4 56/62] server/red_worker: add cursor_channel_client_disconnect

Could eventually be merged with 13/62: Add RedClient On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy wrote: > makes RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT disconnect only a > single client. -- Marc-André Lureau ___ Spice-devel mailing list Spice-de

Re: [Spice-devel] [RFC v4 57/62] server/reds: add RedsState.allow_multiple_clients (temp - add accessors too)

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 @@ typedef struc

Re: [Spice-devel] [RFC v4 59/62] server/red_worker: red_current_add_equal: add dcc null checks

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy 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 mailing list Spice-d

Re: [Spice-devel] [RFC v4 01/62] server/red_channel: renames to use _proc postfix consistently

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 wrote: > s/channel_handle_migrate_flush

Re: [Spice-devel] [RFC v4 04/62] server/red_worker: introduce {display, cursor}_connected

perhaps rename xxx_connected() -> xxx_is_connected() for consistency On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > Instead of checking for worker->{display,cursor}_channel directly. > --- >  server/red_worker.c |   55 ++ >  1 files changed, 3

Re: [Spice-devel] [RFC v4 07/62] server/main_channel: use MainChannel in sig

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

Re: [Spice-devel] [RFC v4 11/62] server/red_channel: merge into red_channel_client_release_item introduction - bug

could be merged with 03/62 introduce RedChannelClient On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > server/red_channel.c > index 3a28304..5aad98b 100644 -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http:

Re: [Spice-devel] [RFC v4 12/62] server/main_channel+reds: make main_channel_init return MainChannelClient

The description doesn't describe the changes correctly. This patch also partially address and worsen the main_channel_foo() consistency evoked in 07/62 review. On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy wrote: > This makes it easier to introduce RedClient in the next patch. > --- >  server/main

Re: [Spice-devel] [RFC v4 13/62] server: Add RedClient

- 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 wrote: > The remaining abort is from a double free in the main chan

Re: [Spice-devel] [RFC v4 16/62] server/main_channel: move link_id from reds

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 alon/server_multi_client.v5.mid. It

Re: [Spice-devel] [RFC v4 19/62] server/red_channel: add RedChannel.clients_num

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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; > +    rcc->channel->clients_

Re: [Spice-devel] [RFC v4 18/62] server/red_channel: introduce pipes functions

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 and channel_

Re: [Spice-devel] [RFC v4 20/62] server/main_channel: support multiple clients

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: swi

Re: [Spice-devel] [RFC v4 23/62] server/smartcard: support multiple clients

On Tue, Apr 26, 2011 at 12:54 PM, Alon Levy 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 enable smartcard

Re: [Spice-devel] [RFC v4 39/62] server/red_worker: introduce RedSurfaceReleaseInfo

On Tue, Apr 26, 2011 at 12:55 PM, Alon Levy wrote: > 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,

Re: [Spice-devel] [RFC v4 00/62] server: multiple client support

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

[Spice-devel] Audio Fails in 64-bit Windows7 Guest

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-kv

Re: [Spice-devel] OSX spice-gtk and pyparsing

That looks more like an X error to meŠ Try getting the latest X11 from http://xquartz.macosforge.org/ Cheers Kai From: Cliff Sharp Date: Mon, 2 May 2011 14:35:12 -0500 To: Kai Mosebach Cc: Attila Sukosd , Christophe Fergeau Subject: Re: [Spice-de

Re: [Spice-devel] spicec and spice-gtk

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: PG

Re: [Spice-devel] spicec and spice-gtk

The question is if I could get a libspice-client-glib without gtk at all? On 5/2/11 1:57 PM, "Christophe Fergeau" wrote: >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

Re: [Spice-devel] spicec and spice-gtk

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 t

Re: [Spice-devel] spicec and spice-gtk

>> >>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 whol

Re: [Spice-devel] [PATCH 0/8] Rework autotools build system

On Wed, Apr 27, 2011 at 05:43:10PM +0200, Marc-André Lureau wrote: > It would be great to get an ACK first from someone building with > Windows before merging. Ping? Anyone on the list who could test a build with these patches applied? If no one chimes in, I'll just commit them in a few days, and