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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 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@xxxxxxxxxx>
> > ---
> >  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@xxxxxxxxxx>
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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]