layer-shell: add ping/pong #90
Conversation
This mechanism is similar to the one already in use by xdg-shell, with the added specification that the server may use this in order to achieve frame-perfection when creating new outputs on which layer-shell clients wish to create a new layer surface.
| create a new layer surface in response to the creation of a new | ||
| output global, the client should make the get_layer_surface request | ||
| immediately on receiving the wl_registry.global event with the new | ||
| output and before processing any further events. |
There was a problem hiding this comment.
Hm. There is one issue with this approach though: if the client needs to preform more requests to decide whether to create a new layer-shell surface or not. A classic example of this is a client that only creates a layer-shell surface on an output named "DP-1": the client would need to retrieve the output name via xdg-output prior to creating the layer surface.
There was a problem hiding this comment.
Yeah, that's a problem. I think we may need to go with the special purpose new_output/ack_new_output version because of this. However a ping/pong may also be worth adding for other use cases (and without this special language).
|
XDG Shell's ping/pong is on the wm_base global, so not tied to creating an xdg_surface object. That makes it usable in combination with layer-shell already. The only difference is that arguably a client could not bind to the wm_base effectively making it client-side optional; but that should be fine for the case described. |
|
That's true. layer-shell has a dependency on xdg-shell already for popups, so IMHO it's fine to rely on xdg-shell for ping/pong. |
|
Yeah, that makes sense to me. I'm going to go ahead and close this. |
This mechanism is similar to the one already in use by xdg-shell, with
the added specification that the server may use this in order to achieve
frame-perfection when creating new outputs on which layer-shell clients
wish to create a new layer surface.
Consider this an alternative to #86. I'm not entirely sure which approach is preferable.