Re: [Spice-devel] [PATCH v7 01/12] sound: Implements config_socket RedChannel callback

... and I did it again. I replied to an old patch series. Sorry, I'm behind and trying to catch up on spice-devel mail. Nearly there. Will move to the current series now... Jonathon On Thu, 2016-12-15 at 15:44 -0600, Jonathon Jongsma wrote: > After a little more consideration, I think this

Re: [Spice-devel] [PATCH v7 01/12] sound: Implements config_socket RedChannel callback

After a little more consideration, I think this should probably be squashed into the gobject patch. I think it's fine that it was sent out for review separately, but it probably makes more sense to have it merged with the next commit before pushing. Jonathon On Mon, 2016-12-05 at 12:07 +,

Re: [Spice-devel] [PATCH spice-server] red-worker: Optimise check

On Mon, 2016-12-12 at 14:08 +, Frediano Ziglio wrote: > Use compile time check instead of running one. Change "running" to "runtime" Acked-by: Jonathon Jongsma > > Signed-off-by: Frediano Ziglio > --- >  server/red-worker.c | 2 +- >  1 file

Re: [Spice-devel] [PATCH spice-server] Sort include order in source files

Looks fine, though it looks like there's also a few additions ( On Thu, 2016-12-08 at 18:32 +, Frediano Ziglio wrote: > Sort based on coding style. > > Signed-off-by: Frediano Ziglio

[Spice-devel] [PATCH v2 9/9] Remove third argument from red_channel_client_init_send_data()

This third argument (and the 'item' member of RedChannelClient::priv::send_data) was a somewhat roundabout way to keep the RedPipeItem alive until a message is sent, just in case some data owned by that pipeitem was added to the marshaller by reference. This was a rather confusing mechanism,

[Spice-devel] [PATCH v2 8/9] DCC: change how fill_bits() marshalls data by reference

The fill_bits() function marshalls some data by reference. This data is owned by the RedDrawable that is owned by the Drawable that is owned by the RedDrawablePipeItem. Instead of keeping the RedPipeItem alive by passing it to red_channel_client_init_send_data(), simply reference the Drawable and

[Spice-devel] [PATCH v2 1/9] Avoid passing pipe item to red_channel_client_init_send_data()

The only time that the pipe item needs to be passed as the third argument to red_channel_client_init_send_data() is when the pipe item holds a data buffer that has been added to the marshaller by reference (spice_marshaller_add_by_ref()) and needs to be kept alive until the data has been sent. In

[Spice-devel] [PATCH v2 5/9] Smartcard: Don't pass pipe item to _init_send_data()

--- server/smartcard-channel-client.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/server/smartcard-channel-client.c b/server/smartcard-channel-client.c index 347e177..aece01b 100644 --- a/server/smartcard-channel-client.c +++

[Spice-devel] [PATCH v2 7/9] DCC: remove more init_send_data() arguments

--- server/dcc-send.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/server/dcc-send.c b/server/dcc-send.c index edeea62..db42ab8 100644 --- a/server/dcc-send.c +++ b/server/dcc-send.c @@ -1118,7 +1118,7 @@ static void

[Spice-devel] [PATCH v2 3/9] Refactor cursor marshalling for SET, INIT

Use spice_marshaller_add_by_ref_full() instead of spice_marshaller_add_by_ref() to allow the marshaller to manage the lifetime of the referenced data buffer rather than having to manage it by passing a PipeItem to red_channel_client_init_send_data(). Since the data is owned by CursorItem (which is

[Spice-devel] [PATCH v2 2/9] CursorChannel: minor improvement to cursor_fill()

Move all 'out' parameters to the end of the function. --- server/cursor-channel.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/server/cursor-channel.c b/server/cursor-channel.c index dedee37..04483af 100644 --- a/server/cursor-channel.c +++ b/server/cursor-channel.c

[Spice-devel] [PATCH v2 0/9] Refactor red_channel_client_init_send_data()

A series of patches refactoring the somewhat-confusing red_channel_client_init_send_data() function. The third argument to this function is a RedPipeItem and it was never very obvious when or why we should pass an item in this parameter. Sometimes callers passed NULL, and sometimes they passed an

[Spice-devel] [PATCH v2 4/9] MainChannel: remove another init_send_data arg

Use spice_marshaller_add_by_ref_full() instead of _add_by_ref() to handle the referenced data properly rather than passing the pipe item to red_channel_client_init_send_data() to keep the pipe item alive indirectly. --- server/main-channel-client.c | 14 +++--- 1 file changed, 11

[Spice-devel] [PATCH v2 6/9] Spicevmc: don't pass pipe item to init_send_data()

--- server/spicevmc.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/server/spicevmc.c b/server/spicevmc.c index d6a6ac8..4f93ca4 100644 --- a/server/spicevmc.c +++ b/server/spicevmc.c @@ -627,6 +627,12 @@ static void

[Spice-devel] [PATCH spice-html5] Condense the playback queue before adding to the Media Buffer.

This helps Firefox in situations where the incoming traffic is preventing the audio element from processing data quickly enough. Signed-off-by: Jeremy White --- playback.js | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git

Re: [Spice-devel] [PATCH v2 0/2] RHEL7 improvements

> > Hi, > > On Thu, Dec 08, 2016 at 03:43:22PM +, Frediano Ziglio wrote: > > These 2 patches attempt to join images split by RHEL7 graphic > > stack (Mesa) decreasing commands handled by spice-server. > > > > You can see the difference between the 2 video: > > -

Re: [Spice-devel] [vdagent-win v2] VDService to notify VDAgent about session status

> > Hi, > > On Wed, Dec 14, 2016 at 05:07:17PM -0500, Frediano Ziglio wrote: > > > > > > Commit 5907b6cbb5c724f9729da59a644271b4258d122e started to handle > > > Lock/Unlock events from Session at VDAgent. That seemed to work fine > > > but as pointed by Andrei at [0], it does not cover the

Re: [Spice-devel] [PATCH spice-server 1/2] Refactory Glz RedDrawable retention code

> > > > Hey, > > > > On Tue, Oct 18, 2016 at 10:28:25AM +0100, Frediano Ziglio wrote: > > > The code was quite complicated. > > > > I tried to look at this one, and it indeed is quite complicated... So > > far, too much entangled stuff that I feel confident I'm going to make a > > meaningful

[Spice-devel] [PATCH spice-html5 2/4] Display stream creation and destruction at debug level 1.

They are low frequency, useful messages and should be seen more readily. Signed-off-by: Jeremy White --- display.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/display.js b/display.js index 1012786..0646744 100644 --- a/display.js +++

[Spice-devel] [PATCH spice-html5 4/4] Include the codec type in the stream creation message.

Signed-off-by: Jeremy White --- display.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/display.js b/display.js index 788fcc6..40a809e 100644 --- a/display.js +++ b/display.js @@ -535,7 +535,7 @@ SpiceDisplayConn.prototype.process_channel_message =

[Spice-devel] [PATCH spice-html5 1/4] Show the timeupdate events at stream debug level 2, not level 1.

They are fairly noisy, and more appropriate to the more detailed level. Signed-off-by: Jeremy White --- display.js | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/display.js b/display.js index e26bff8..1012786 100644 --- a/display.js +++

[Spice-devel] [PATCH spice-html5 3/4] Move the queue length debug up to stream level 2.

It's a fair amount of noise, and not useful at level 1. Signed-off-by: Jeremy White --- display.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/display.js b/display.js index 0646744..788fcc6 100644 --- a/display.js +++ b/display.js @@ -1185,7

Re: [Spice-devel] [PATCH spice-server 1/2] Refactory Glz RedDrawable retention code

> > Hey, > > On Tue, Oct 18, 2016 at 10:28:25AM +0100, Frediano Ziglio wrote: > > The code was quite complicated. > > I tried to look at this one, and it indeed is quite complicated... So > far, too much entangled stuff that I feel confident I'm going to make a > meaningful review... > > > - a

Re: [Spice-devel] [spice-server v3 08/11] reds: drop sscanf() in favour of g_strsplit()

> > Hi, > > On Thu, Dec 15, 2016 at 06:27:21AM -0500, Frediano Ziglio wrote: > > > > > From: Victor Toso > > > > > > In case of errors in sscanf(), we were returning (codecs + n) being n > > > an uninitialized variable. That should be avoided in any circumstance. > > > > >

Re: [Spice-devel] [spice-gtk v1] win-usb: remove usbclerk

Hi, On Fri, 2016-12-09 at 18:22 +0100, Victor Toso wrote: > From: Victor Toso > > As we have UsbDk integration now which is well maintained upstream. yes, it makes a sense > > Signed-off-by: Victor Toso > --- >  doc/reference/Makefile.am|   2

Re: [Spice-devel] [spice-gtk v1] Ignore warnings about unavailable function around webdav

Ack On Fri, 2016-12-09 at 14:26 +0100, Victor Toso wrote: > From: Victor Toso > > We do an extra check in configure to enable webdav and build > everything > with a PHODAV variable check. > > The warnings below are false positive and can be ignored while we > don't > bump

Re: [Spice-devel] [spice-server v3 08/11] reds: drop sscanf() in favour of g_strsplit()

Hi, On Thu, Dec 15, 2016 at 06:27:21AM -0500, Frediano Ziglio wrote: > > > From: Victor Toso > > > > In case of errors in sscanf(), we were returning (codecs + n) being n > > an uninitialized variable. That should be avoided in any circumstance. > > > > These lines are

[Spice-devel] [qxl v2] xspice: Adjust to X.org 1.19 changes

In newer X.org versions, it's no longer supported to modify the set of FDs passed to a BlockHandler method to get notified when the FD has data to be read. This was limited anyway as we could only get read events this way, and had to do our own polling to get notified about socket writeability.

Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes

On Thu, Dec 15, 2016 at 02:01:03PM +0200, Uri Lublin wrote: > Hi Christophe, > > Please see some comments below > > On 12/14/2016 12:51 PM, Christophe Fergeau wrote: > > +static int watch_update_mask2(SpiceWatch *watch, int event_mask) > > +{ > > +SetNotifyFd(watch->fd, NULL, X_NOTIFY_NONE,

Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes

Hi Christophe, Please see some comments below On 12/14/2016 12:51 PM, Christophe Fergeau wrote: In newer X.org versions, it's no longer supported to modify the set of FDs passed to a BlockHandler method to get notified when the FD has data to be read. This was limited anyway as we could only

Re: [Spice-devel] [PATCH spice-server 1/2] Refactory Glz RedDrawable retention code

Hey, On Tue, Oct 18, 2016 at 10:28:25AM +0100, Frediano Ziglio wrote: > The code was quite complicated. I tried to look at this one, and it indeed is quite complicated... So far, too much entangled stuff that I feel confident I'm going to make a meaningful review... > - a GlzEncDictImageContext

Re: [Spice-devel] [spice-server v3 08/11] reds: drop sscanf() in favour of g_strsplit()

> From: Victor Toso > > In case of errors in sscanf(), we were returning (codecs + n) being n > an uninitialized variable. That should be avoided in any circumstance. > These lines are wrong. n is always used initialized. > As there is a need to iterate over every

Re: [Spice-devel] [spice-server v3 06/11] reds: don't replace video_codecs on failure

> > From: Victor Toso > > We should replace the video_codecs GArray only after the parsing of > input is done, otherwise we might lose previous configuration. > > Tests were updated to match this situation. Input that fails to > replace video_codecs are considered bad. >

Re: [Spice-devel] Spice-Html5 Client Query

On 12/14/2016 08:05 PM, Shirley Arava wrote: Hi, I was looking for some sort of guidance as to where I was going wrong with the spice protocol requirements. We are currently trying to use SPICE-html5 client to provide remote access to Virtual Machines hosted on a Xen hypervisor. It would be

Re: [Spice-devel] [spice-protocol v3 01/11] protocol: add preferred video codec message

> > From: Victor Toso > > Client might want to choose a preferred video codec for streaming for > different reasons which having hardware decoder support being the most > interest one. > > This message allows the client to send a list of video codecs in a > order of

Re: [Spice-devel] [qxl] Xspice: Replace malloc/strdup use with xnfalloc/xnfstrdup

Hi, On 15-12-16 10:57, Christophe Fergeau wrote: spiceqxl_*.c files are Xspice-only code. They contain a few uses of malloc/strdup, and none of these are checked for failure. It's better to replace these with xfnalloc/xnfstrdup which are provided by the X server and cannot fail (aborts on

[Spice-devel] [qxl] Xspice: Replace malloc/strdup use with xnfalloc/xnfstrdup

spiceqxl_*.c files are Xspice-only code. They contain a few uses of malloc/strdup, and none of these are checked for failure. It's better to replace these with xfnalloc/xnfstrdup which are provided by the X server and cannot fail (aborts on failure). Signed-off-by: Christophe Fergeau

Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes

On Wed, Dec 14, 2016 at 12:07:55PM +0100, Hans de Goede wrote: > Hi, > > On 14-12-16 11:51, Christophe Fergeau wrote: > > In newer X.org versions, it's no longer supported to modify the set of > > FDs passed to a BlockHandler method to get notified when the FD has data > > to be read. This was

Re: [Spice-devel] Complaint about service of Spice mobile

On 12/12/2016 07:12 AM, Mahesh Sharma wrote: I have a Spice mobile in this set complaint with keyboard light at the service centre of Sawai Madhopur the service person say incomplete of your complaint about 15 to 20 days please SOL my problem Hello, I think you are referring to a different