xdg-shell: about configure, states and ack_configure

Michael Forney mforney at mforney.org
Thu Apr 21 17:44:45 UTC 2016


On Thu, Apr 21, 2016 at 03:57:52AM -0400, Olivier Fourdan wrote:
> So, for example, if the compositor sets a state maximized and a size
> larger than the client would expect, in theory, the client could
> ignore the request, not configure its surface and never send an
> ack_configure for that serial.
> 
> At least, that was my understanding and that's why I reckoned the
> client would always have the final word even if the compositor would
> not follow the min/max size hints.

In order for a compositor to successfully move a window from one size
and position to another without flicker (which is normal operation for
tiling window managers), one of the following must be true:

  * The client *must always* ack the last configure it sees in a series
    of configure events and then attach a buffer (possibly the existing
    one) and commit it.

  * The compositor must configure the client xdg_surface to be maximized
    and the client must obey the part of the spec that says "clients
    must obey window geometry when in the maximized state".

This is because the compositor needs to know (either yes or no) if the
client intends to respond with a new buffer due to the configure event,
so it can move it at the right time.

When it is in the maximized state, the compositor can assume that if it
sends a configure event for a size different than the current buffer
size, that the client will respond by acking that configure and
attaching a new buffer. When it is not, the compositor can't resize and
move the window without flicker because it may not receive any
indication that the window has seen the configure it sent.

I think things would be simpler if we required that clients always ack
the last configure in a series, but only have to obey the size when that
configure specifies maximized or fullscreen.

See also this previous mail[0] on the subject.

-Michael

[0]: https://lists.freedesktop.org/archives/wayland-devel/2014-December/018648.html


More information about the wayland-devel mailing list