Open ifreund opened 4 years ago
If wonder if it would be desirable to change this to a ping/pong mechanism similar to xdg-shell.
Clarified that all clients must ack and rebased onto #87 to avoid conflicts.
If wonder if it would be desirable to change this to a ping/pong mechanism similar to xdg-shell.
If I understand correctly, this would just make the ability to use this to achieve atomicity of new outputs implicit instead of explicit. The logic would stay the same from the server's point of view:
This seems like it would work just as well and could be more generally useful than the new output specific language.
The disadvantage to solving this race implicitly through a ping/pong is that clients which for whatever reason make the pong request before get_layer_surface will still be racy. We could certainly explain how compositors could use ping/pong to solve this in the protocol and encourage clients to respond to the events in order though.
Opened up #90 to explore the ping/pong alternative approach.
If I understand correctly, this would just make the ability to use this to achieve atomicity of new outputs implicit instead of explicit.
Yeah. That would work similarly to wl_display_roundtrip
: the ping-pong roundtrip guarantees that the client has processed all events until the ping request.
This also has more use-cases, like detecting unresponsive layer-shell clients (like xdg-shell).
Tweaked the descriptions to clarify that the compositor may create several new outputs at once before sending this event. Also bumped the protocol version to 4 as there was a wlroots release with version 3 since this PR was opened.
To make sure I understand correctly:
Is this the intended sequence? Also, another question. Why do we choose this design over the following:
It seems to me this second variant will be easier to implement because compositor doesn't have to guess when a client is ready, although I may be missing something.
BTW, wayfire does something similar with a private protocol: https://github.com/WayfireWM/wayfire/blob/master/proto/wayfire-shell-unstable-v2.xml#L47-L64, which is used for ex. for fade-in animation when an output is plugged in or at startup. (Note that this mechanism in wayfire-shell-unstable is racy, I'd switch to the ack_output once it is implemented).
Is this the intended sequence? Also, another question. Why do we choose this design over the following:
Yes, that's the intended sequence. This was chosen mostly for consistency with other established ack sequences (e.g. in xdg_shell) where the ack sent in response to a configure indicates that the next commit takes the change in state into account.
It seems to me this second variant will be easier to implement because compositor doesn't have to guess when a client is ready, although I may be missing something.
There's no guessing here unless I'm missing something. Only new surfaces created on the new output(s) before the client sends the ack_new_output
request are waited on. Each surface is "ready" exactly when it has attached and committed its first buffer, which will then be part of the first frame rendered on the new output.
Is this the intended sequence? Also, another question. Why do we choose this design over the following:
Yes, that's the intended sequence. This was chosen mostly for consistency with other established ack sequences (e.g. in xdg_shell) where the ack sent in response to a configure indicates that the next commit takes the change in state into account.
It seems to me this second variant will be easier to implement because compositor doesn't have to guess when a client is ready, although I may be missing something.
There's no guessing here unless I'm missing something. Only new surfaces created on the new output(s) before the client sends the
ack_new_output
request are waited on. Each surface is "ready" exactly when it has attached and committed its first buffer, which will then be part of the first frame rendered on the new output.
Ok, thanks for the explanation.
Overall looks good. Would be nice to see a client & compositor implementation!
wlr-protocols has migrated to gitlab.freedesktop.org. This pull request has been moved to:
https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/86
This ack sequence eliminates the race between a client creating a new layer surface and the compositor rendering the first frame of a new output.
This race is especially important for screenlockers using layer-shell such as swaylock https://github.com/swaywm/swaylock/issues/16