[Spice-devel] [PATCH spice-server v3] stream-channel: Tell client we are just streaming data

[Frediano Ziglio]

>
> Frediano Ziglio writes:
> 
> > This give an hint to client which can optimise rendering.
> >
> > Signed-off-by: Frediano Ziglio <fziglio at redhat.com>
> > ---
> >  server/stream-channel.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > Changes since v2:
> > - remove conditional code.
> 
> OK, now I'm confused :-)
> 
> Does that mean that:
> 
> a) you simply want this to be independent from your identity macros patch?
> 
> b) you feel it's OK (or maybe even good) to break the build if the wrong
>    protocol package is included?
>

This is actually the way we manage updates so it's not a regression,
people trying to compile master spice-server should have master spice-protocol.
To compile in this specific case you don't need spice-common update but
obviously you want the spice-common patch in (as it should produce the updated
file in spice-protocol).

I think identity macros are useful as they allow a bit of independence
between specific commit even if they could introduce some potential
problems (is up to the user to use them or not).

> >
> > diff --git a/server/stream-channel.c b/server/stream-channel.c
> > index c7ca0206..568ceac8 100644
> > --- a/server/stream-channel.c
> > +++ b/server/stream-channel.c
> > @@ -203,6 +203,13 @@ stream_channel_send_item(RedChannelClient *rcc,
> > RedPipeItem *pipe_item)
> >              channel->width, channel->height,
> >              SPICE_SURFACE_FMT_32_xRGB, SPICE_SURFACE_FLAGS_PRIMARY
> >          };
> > +
> > +        // give an hint to client that we are sending just streaming
> > +        // see spice.proto for capability check here
> > +        if (red_channel_client_test_remote_cap(rcc,
> > SPICE_DISPLAY_CAP_MULTI_CODEC)) {
> > +            surface_create.flags |= SPICE_SURFACE_FLAGS_STREAMING_MODE;
> > +        }
> > +
> >          spice_marshall_msg_display_surface_create(m, &surface_create);
> >          break;
> >      }
> 

Frediano