[PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Jonas Ådahl]

On Wed, Apr 18, 2018 at 07:49:12AM -0400, Simon Ser wrote:
> On April 18, 2018 10:28 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> > How do you imagine avoiding state transitions that don't result in
> > incorrect intermediate state? If a compositor changes the preferred
> > mode, does it wait some arbitrary time to see if client replies with a
> > new set_mode request? Or how else would one avoid sending a new
> > configuration given the changed tiled-ness without knowing what the
> > client prefers?
> 
> I don't think "wait[ing] some arbitrary time" is an acceptable behaviour.
> Instead, I think the compositor has two choices:
> 
> - Either it decides to respect the client's choice (because it allows both
>   CSD and SSD in this situation), in which case it just sends preferred_mode and
>   lets the client send (or do not send) a set_mode request.
> - Either it decides to enforce a particular mode (because it only allows for one
>   mode in this situation), in which case it just sends configure.
> 
> This "I want to know the client's preferred mode before I decide if I force one
> mode or let the client choose" behaviour is a little weird.
> 
> > Wouldn't it be better to have actual clients that'd actually use this
> > part of the protocol before writing it down? We could still move forward
> > with a vastly simpler protocol without the set_mode and set_preferred,
> > and just have the mode enum and configure (so that the compositor can
> > switch between csd and ssd when tiling/untiling or whatever) that works
> > with the all available clients we have today.
> 
> We could always do this and add preferred_mode & set_mode later. Note that the
> current test client uses this part of the protocol (it can be configured to use
> the compositor's preferred mode or use its own preferred mode), but it's just a
> test client.
> 

Since the issue is more of a race condition kind of issue, it might not
be easily reproducable with a demo client, but must be solved by coming
up with a type of negotiation that doesn't result in incorrect
intermediate states for example the one described above.

A race free protocol is what we need though, to continue with the "every
frame is perfect" concept we are striving for.


Jonas