[Spice-devel] [PATCH spice-common 1/2] RFC protocol: Allow to specify a surface will be streamed

[Frediano Ziglio]

> 
> Frediano Ziglio writes:
> 
> > This flag will allow the client to perform some optimisations
> > on output and buffering processing.
> > Old clients will ignore this additional flag.
> >
> > Signed-off-by: Frediano Ziglio <fziglio at redhat.com>
> > ---
> >  spice.proto | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/spice.proto b/spice.proto
> > index 867ef9b..2896966 100644
> > --- a/spice.proto
> > +++ b/spice.proto
> > @@ -467,7 +467,8 @@ flags8 string_flags {
> >  flags32 surface_flags {
> >      /* Adding flags requires some caps check, since old clients only
> >         treat the value as an enum and not as a flag (flag == PRIMARY) */
> > -    PRIMARY
> > +    PRIMARY,
> > +    STREAMING_MODE,
> 
> This does not seem to be related to the capability in the other patch.
> But then, there is a comment suggesting there should be a capability if
> you add a flag. Do we need another capability?
> 

In this case not. In the case of a new message we need to know if client
support it otherwise client will trigger an error. Also we want the client
to process the new message.
In this case this flag is an hint. Old clients will ignore the flag
and client will just don't consider it but work correctly.
Currently the client does not check if there are additional unknown
flags so former clients will just ignore the bit.

But I think you refer to the comment above PRIMARY:

     /* Adding flags requires some caps check, since old clients only
        treat the value as an enum and not as a flag (flag == PRIMARY) */

this was fixed by:

commit 5b6e3d1c16457c926322ce28d341af2e8d39efb5
Author: Marc-André Lureau <marcandre.lureau at redhat.com>
Date:   Wed Aug 21 18:09:11 2013 +0200

    display: use bitfields for surface flags

    Checking by value make the flag fields useless. Unfortunately, when
    adding more flags, the server will have to ensure it can safely send it,
    by checking some of new client caps (for some features).

Looking at display capabilities added after this commit, removing
compile defined one (LZ4 depending on LZ4 availability and GL_SCANOUT
depending on Unix and EGL) I found SPICE_DISPLAY_CAP_MULTI_CODEC.
I think would make sense to assume if client support this capability
to send the additional bit. Giving that this flag is useful with clients
with advanced code support it would make sense.
Some additional comments (from above explanation) are however mandatory.

> 
> >  };
> >
> >  enum32 surface_fmt {
> 

Frediano