On Wed, Apr 18, 2018 at 11:32:09AM -0400, Simon Ser wrote: > On April 18, 2018 1:05 PM, Jonas Ådahl <[email protected]> wrote: > > 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. > > I see where you're getting at and agree with you. > > I can think of a fix which would make it mandatory for clients to issue a > set_mode request after receiving a preferred_mode event. A serial is probably > needed for this. What do you think?
Not sure serials will do any good here. One idea that comes to mind would be to the client send a series of supported modes in order of preference, then always let the compositor decide via the configure. > > Like you said, it's probably better to take preferred_mode/set_mode out of the > protocol for now, move forward and add them later (making sure there's no > race). > I'll send a v5 with the renaming and the simplification. > That'd definitely be the best way to get a first version landed faster, while still experimenting with how to solve the other problem race free. Jonas _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
