On Wed, Apr 18, 2018 at 07:49:12AM -0400, Simon Ser wrote: > On April 18, 2018 10:28 AM, Jonas Ådahl <jad...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel