xdg_toplevel configure with undefined window dimensions

I recently came across an issue in mutter that is related to the xdg_toplevel.configure event: https://gitlab.gnome.org/GNOME/mutter/issues/928

In the presented case, a xdg toplevel surface is created with a 200x200 pxl buffer, and additional decoration surfaces. The second xdg_toplevel.configure event from mutter contains the correct toplevel dimension (xdg_toplevel@21.configure(200, 200, array)) whereas weston provides undefined dimensions (xdg_toplevel@21.configure(0, 0, array)).

The xdg_toplevel.configure documentation states:

This may happen when the compositor needs to configure the state of the surface but doesn't have any information about any previous or expected dimension.

Form my interpretation, weston knows about the expected dimensions of the toplevel surface, since the buffer size of the attached wl_surface is known, and must provide those with the configure event.

Due to the different behaviour in weston, I would like to ask for clarity, when the toplevel configure event must include valid window dimensions (>0) and when not.

The "undefined dimension" just means that the compositor doesn't have a preference: the client can choose any size.

This leaves quite a lot of room for interpretation. Since there is no "governed" Wayland compositor and no widely accepted/used conformity test suite, the interpretation should be quite tight.

Ideally, all compositors that implement a protocol will interpret the behaviour in the same way such that their IPC produces the same messages with the same payload.

Is there any way to resolve ambiguity in the protocol implementation? Should all compositors align with the behaviour of weston?

Ideally, all compositors that implement a protocol will interpret the behaviour in the same way such that their IPC produces the same messages with the same payload.

That's not going to happen, since a lot of behaviour is compositor-specific. A tiling compositor won't configure surfaces like GNOME, for instance.

Is there any way to resolve ambiguity in the protocol implementation? Should all compositors align with the behaviour of weston?

Weston doesn't implement all protocols and has bugs. I just think we should make sure the protocol is unambiguous enough.

In this case, I'm not sure where the ambiguity comes from. Maybe we should replace "doesn't have any information about any previous or expected dimension" with "doesn't have a preference about the surface dimension"?

AFAIU "doesn't have a preference about the surface dimension" is the correct interpretation.

So Weston does not care, but what Mutter is saying is that if you made your window 200x200 before, it suggests you to keep it the same size even after the state changes it asks for. Neither behaviour is incorrect. Either or both behaviours could be unintended, but they are both valid things to ask the client to do. The intention comes from how the particular compositor wants to manage its windows and it completely up to the implemented policy.

That's not going to happen, since a lot of behaviour is compositor-specific. A tiling compositor won't configure surfaces like GNOME, for instance.

I think you could still define expected behaviour within a category of compositors like stacking, tiling, kiosk-mode.

"doesn't have a preference about the surface dimension"

While this reflects the intended meaning, it further increases the uncertainty about who is responsible for keeping track of the client's window state.

Further recommendations for the configure event window dimensions are given from transitioning from maximised or fullscreen to stacking/floating mode.

unset_maximized:

	If available and applicable, the compositor will include the window
	geometry dimensions the window had prior to being maximized in the
	configure event.

unset_fullscreen:

	The compositor may include the previous window geometry dimensions in
	the configure event, if applicable.

I interpret these too as "if the compositor knows about the previous window dimensions, it must provide those to the client". It suggests that the server is responsible for keeping track of window dimensions.

However, if the interpretation is "doesn't have a preference", then a compositor could always provide (0,0). In such a case, I see the application of window dimensions in the configure event only for transitioning into maximised or fullscreen modes, since the client cannot know about the output size and the derived maximised / fullscreen dimension.

I think it's worthwhile to define if the server or client is responsible to keep track of dimensions:

1. If the server is responsible for keeping track of window states, then the configure event must always contain the window dimensions of the state, or (0,0) if the client has no state yet, e.g. if it hasn't committed to the toplevel buffer yet.

2. If the client is responsible for keeping track of its own window state, then the configure event should only contain valid values (>0) if the client cannot know about the maximised or fullscreen dimension. In all other cases, the window dimension must be (0,0).

I prefer to move this responsibility to the server to simply implementing clients. Since there are more clients than servers, it is more efficient to implement that logic in the server, than having every client implement the same logic over-and-over again. Also, the server is the only instance that has a holistic view of the outputs and all client surfaces.

I interpret these too as "if the compositor knows about the previous window dimensions, it must provide those to the client". It suggests that the server is responsible for keeping track of window dimensions.

may != must

The compositor is definitely not responsible for keeping track of the toplevel dimensions on behalf of the client. You can see the configure events as resize requests, with zero meaning "don't resize"/"i don't care".

However, if the interpretation is "doesn't have a preference", then a compositor could always provide (0,0).

Yes, this is correct.

In such a case, I see the application of window dimensions in the configure event only for transitioning into maximised or fullscreen modes, since the client cannot know about the output size and the derived maximised / fullscreen dimension.

This is also useful if the compositor remembers the previous window size, like GNOME does (across reboots too IIRC). There's no guarantee a compositor would do that.

If the server is responsible for keeping track of window states, then the configure event must always contain the window dimensions of the state, or (0,0) if the client has no state yet, e.g. if it hasn't committed to the toplevel buffer yet.

1. This would be a breaking change.
2. I don't see why the server should do this. With the current status quo, the client just needs to ignore the configure size if it's zero. I don't see where the complexity is.

If the client is responsible for keeping track of its own window state, then the configure event should only contain valid values (>0) if the client cannot know about the maximised or fullscreen dimension. In all other cases, the window dimension must be (0,0).

No: the client should never try to guess maximize/fullscreen dimensions, and the compositor might want to resize a client for compositor-defined reasons.

This is also useful if the compositor remembers the previous window size, like GNOME does (across reboots too IIRC). There's no guarantee a compositor would do that.

Alright, such a use-case makes sense.

I don't see why the server should do this. With the current status quo, the client just needs to ignore the configure size if it's zero. I don't see where the complexity is.

The complexity comes from the need to implement client-side tracking of the state in every client, rather than the single compositor.

No: the client should never try to guess maximize/fullscreen dimensions, and the compositor might want to resize a client for compositor-defined reasons.

That is why I wrote that the configure event has to contain valid dimensions (>0) so that the client does not have to guess the size of the output.

---

In any case, I think it's worthwhile to clarify these roles. What I gathered up until now is that the responsibility of keeping track of window states lies in the client. The configure event is basically a request to the client to resize. With (0,0) it tells the client that there is no update request from the server. When emitted with valid values (>0) must the client respect those values and resize accordingly, or can it ignore it?

The complexity comes from the need to implement client-side tracking of the state in every client, rather than the single compositor.

Clients will always have to track all of their state in any case. The configure event with size is an extremely rare special case, usually clients have no API to get back what they sent to the compositor at all. Because why would you roundtrip to the server, when you already know what you sent before - the server does not magically change things behind your back (if it needs to, there are events to tell you about it).

That is why I wrote that the configure event has to contain valid dimensions (>0) so that the client does not have to guess the size of the output.

Is that not already happening for the cases where the compositor actually cares about what size the window will be?

"The cases where the compositor actually cares" is of course compositor-dependent, probably coming from user policies and what not, so it cannot be written down in a protocol spec for everything.

What I gathered up until now is that the responsibility of keeping track of window states lies in the client.

Yes, the client must track everything, but compositor also tracks what it deems useful for itself.

The configure event is basically a request to the client to resize.

It can be, but it can also be any state change without explicit resize. If the compositor cares about the resulting window size, it sets the size. If it does not care, it sets zero size.

With (0,0) it tells the client that there is no update request from the server.

No, it only says that the server does not mind what size the client will pick as a result of this bunch of configure events.

When emitted with valid values (>0) must the client respect those values and resize accordingly, or can it ignore it?

Generally yes, but it depends on other window state if disobeying an explicitly asked size is a protocol error or not. That is documented with each window state flag where it matters. Some require exact size, some use it as maximum size.

I am not sure how, but then it would probably good if this could be clarified in the protocol documentation.

Right, that's the problem: it is clear to me, so I don't see how to clarify it.

Should this bug be moved to wayland-protocols for clarifying the protocol spec wording?

moved from weston#318 (moved)

added xdg-shell label