>
> Frediano Ziglio writes:
>
> > This give an hint to client which can optimise rendering.
> >
> > Signed-off-by: Frediano Ziglio <fziglio@xxxxxxxxxx>
> > ---
> > 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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel