Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Christophe de Dinechin
> On 4 Aug 2017, at 14:49, Victor Toso wrote: > > On Fri, Aug 04, 2017 at 02:34:44PM +0200, Christophe de Dinechin wrote: >> >>> On 4 Aug 2017, at 14:03, Frediano Ziglio wrote: >>> Hi, On Fri, Aug 04, 2017 at 01:01:05PM +0200,

Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Victor Toso
On Fri, Aug 04, 2017 at 02:34:44PM +0200, Christophe de Dinechin wrote: > > > On 4 Aug 2017, at 14:03, Frediano Ziglio wrote: > > > >> > >> Hi, > >> > >> On Fri, Aug 04, 2017 at 01:01:05PM +0200, Christophe de Dinechin wrote: > It does not check if given patch was

Re: [Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

2017-08-04 Thread Christophe de Dinechin
> On 4 Aug 2017, at 13:44, Christophe Fergeau wrote: > > On Fri, Aug 04, 2017 at 12:11:44PM +0200, Christophe de Dinechin wrote: >> >>> On 18 Jul 2017, at 16:48, Christophe Fergeau wrote: >>> >>> Hey, >>> >>> On Tue, Jul 18, 2017 at 04:37:29PM

Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Christophe de Dinechin
> On 4 Aug 2017, at 14:03, Frediano Ziglio wrote: > >> >> Hi, >> >> On Fri, Aug 04, 2017 at 01:01:05PM +0200, Christophe de Dinechin wrote: It does not check if given patch was pushed, no. :( >>> >>> If so, that’s a lot less useful than PRs. >> >> All comes down to

Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Frediano Ziglio
> > Hi, > > On Fri, Aug 04, 2017 at 01:01:05PM +0200, Christophe de Dinechin wrote: > > > It does not check if given patch was pushed, no. :( > > > > If so, that’s a lot less useful than PRs. > > All comes down to workflow in the end... Some people love it :) > https://patchwork.linuxtv.org/ >

Re: [Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

2017-08-04 Thread Christophe Fergeau
On Fri, Aug 04, 2017 at 12:11:44PM +0200, Christophe de Dinechin wrote: > > > On 18 Jul 2017, at 16:48, Christophe Fergeau wrote: > > > > Hey, > > > > On Tue, Jul 18, 2017 at 04:37:29PM +0200, Christophe de Dinechin wrote: > >> OK. Since you seem to feel more strongly

Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Victor Toso
Hi, On Fri, Aug 04, 2017 at 01:01:05PM +0200, Christophe de Dinechin wrote: > > It does not check if given patch was pushed, no. :( > > If so, that’s a lot less useful than PRs. All comes down to workflow in the end... Some people love it :) https://patchwork.linuxtv.org/ signature.asc

Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Christophe de Dinechin
> On 4 Aug 2017, at 12:48, Victor Toso wrote: > > Hi, > > On Fri, Aug 04, 2017 at 12:42:39PM +0200, Christophe de Dinechin wrote: >> During the discussion on PRs and stuff, several people pointed to >> patchwork. >> >> Does anyone know why this tool does not acknowledge

Re: [Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Victor Toso
Hi, On Fri, Aug 04, 2017 at 12:42:39PM +0200, Christophe de Dinechin wrote: > During the discussion on PRs and stuff, several people pointed to > patchwork. > > Does anyone know why this tool does not acknowledge acks? For example > https://patchwork.freedesktop.org/series/27298/ has a "Acked-by:

[Spice-devel] Getting patchwork to acknowledge acks?

2017-08-04 Thread Christophe de Dinechin
During the discussion on PRs and stuff, several people pointed to patchwork. Does anyone know why this tool does not acknowledge acks? For example https://patchwork.freedesktop.org/series/27298/ has a "Acked-by: Christophe de Dinechin ” in the fifth comment, and has been

Re: [Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

2017-08-04 Thread Christophe de Dinechin
> On 18 Jul 2017, at 16:48, Christophe Fergeau wrote: > > Hey, > > On Tue, Jul 18, 2017 at 04:37:29PM +0200, Christophe de Dinechin wrote: >> OK. Since you seem to feel more strongly about this than me, I changed it. >> Pushed to freedesktop.org. Since this is the first

[Spice-devel] [PATCH spice-common 3/5] quic: remove Channel::encoder

2017-08-04 Thread Frediano Ziglio
This field is easily accessible from Encoder structure. Signed-off-by: Frediano Ziglio --- common/quic.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/common/quic.c b/common/quic.c index 42670ad..a4c46d3 100644 --- a/common/quic.c +++

[Spice-devel] [PATCH spice-common 5/5] quic: turn back some commented out checks as compile time

2017-08-04 Thread Frediano Ziglio
Signed-off-by: Frediano Ziglio --- common/quic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/quic.c b/common/quic.c index 7c069e4..1be28c6 100644 --- a/common/quic.c +++ b/common/quic.c @@ -223,8 +223,8 @@ static const unsigned int

[Spice-devel] [PATCH spice-common 1/5] quic: remove only assigned num_channels field

2017-08-04 Thread Frediano Ziglio
Signed-off-by: Frediano Ziglio --- common/quic.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/common/quic.c b/common/quic.c index b753d07..511e733 100644 --- a/common/quic.c +++ b/common/quic.c @@ -153,7 +153,6 @@ struct Encoder { QuicImageType type;

[Spice-devel] [PATCH spice-common 2/5] quic: remove only assigned CommonState::encoder

2017-08-04 Thread Frediano Ziglio
Signed-off-by: Frediano Ziglio --- common/quic.c | 4 1 file changed, 4 deletions(-) diff --git a/common/quic.c b/common/quic.c index 511e733..42670ad 100644 --- a/common/quic.c +++ b/common/quic.c @@ -103,8 +103,6 @@ typedef struct s_bucket { typedef struct Encoder

[Spice-devel] [PATCH spice-common 4/5] quic: use 32 bit for bppmask

2017-08-04 Thread Frediano Ziglio
In most occurrences bppmask is converted to 32 bit anyway. In the left one a possible more bigger precision is not needed. Signed-off-by: Frediano Ziglio --- common/quic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/quic.c b/common/quic.c

Re: [Spice-devel] [spice-common v3 06/12] quic: Factor common code

2017-08-04 Thread Frediano Ziglio
> > We don't need 2 different implementations when the only difference is > the CommonState which is being used. > > Signed-off-by: Christophe Fergeau > --- > common/quic.c | 194 > ++ > 1 file changed, 73

Re: [Spice-devel] [spice-common v3 05/12] quic: Get rid of RLE #define

2017-08-04 Thread Frediano Ziglio
> > It's always set, no need to have conditional compilation based on it. > > Signed-off-by: Christophe Fergeau > --- > common/quic.c | 9 - > common/quic_rgb_tmpl.c | 12 > common/quic_tmpl.c | 12 > 3 files changed, 33

Re: [Spice-devel] [spice-common v3 04/12] quic: Get rid of RLE_STAT #define

2017-08-04 Thread Frediano Ziglio
> > It's always set, no need to have conditional compilation based on it. > > Signed-off-by: Christophe Fergeau > --- > common/quic.c | 53 > ++--- > common/quic_tmpl.c | 12 > 2 files changed, 2

Re: [Spice-devel] [spice-common v3 03/12] quic: Get rid of QUIC_RGB #define

2017-08-04 Thread Frediano Ziglio
> > It's always set, no need to have conditional compilation based on it. > > Signed-off-by: Christophe Fergeau > --- > common/quic.c | 151 > - > common/quic_tmpl.c | 6 --- > 2 files changed, 157 deletions(-) >

Re: [Spice-devel] [spice-common v3 02/12] quic: Remove configurable PRED

2017-08-04 Thread Frediano Ziglio
> > It's hardcoded at compile-time, and I don't think it was changed in > years... > > Signed-off-by: Christophe Fergeau > --- > common/quic.c | 1 - > common/quic_rgb_tmpl.c | 31 --- > common/quic_tmpl.c | 38

Re: [Spice-devel] [spice-common v3 01/12] quic: Remove configurable RLE_PRED

2017-08-04 Thread Frediano Ziglio
> > It's hardcoded at compile-time, and I don't think it was changed in > years... > > Signed-off-by: Christophe Fergeau > --- > common/quic.c | 3 --- > common/quic_rgb_tmpl.c | 55 > -- > common/quic_tmpl.c |

Re: [Spice-devel] [PATCH spice-gtk 0/2] Disabling mmtime adjustment in the client (from audio backend)

2017-08-04 Thread Victor Toso
Hi, On Thu, Aug 03, 2017 at 10:13:10AM -0400, Marc-André Lureau wrote: > Hi > > - Original Message - > > > I start to be worried about all of our streaming tweaks and issues. Is > > > there any effort to use RTP/SRTP instead? I think this would be a big > > > opportunity to improve the