• Simon Ser's avatar
    xdg-output: deprecate the xdg_output.done event · 962dd535
    Simon Ser authored
    This commit makes it so a wl_output.done event is guaranteed to be sent with a
    xdg_output.done event.
    
    This protocol change has been discussed in a recent xorg-devel discussions [1].
    
    First let's recap why a change is needed: Xwayland listens to both wl_output and
    xdg_output changes. When an output's properties change, Xwayland expects to
    receive both a wl_output.done event and an xdg_output.done event. If that's not
    the case, Xwayland doesn't update its state (so old state is still exposed to
    X11 clients).
    
    Most of the time, both objects will be updated at the same time (e.g. the
    current mode is changed, so both wl_output.mode and xdg_output.logical_size are
    sent) so this won't be an issue. However in some situations only one of
    wl_output or xdg_output changes. For instance:
    
    - The mode is changed at the same time as the scale, resulting in the same
      logical_size.
    - The compositor doesn't expose the outputs' position via wl_output, so whenever
      the position changes only xdg_output is updated.
    
    Both KDE [2] and wlroots [3] have experienced this issue.
    
    For this reason, I'd like to update the xdg-output protocol to make it mandatory
    to always send a wl_output.done event after xdg_output changes. This effectively
    makes wl_output.done atomically apply all output state (including the state of
    add-on objects like xdg_output). This approach is pretty similar to
    wl_surface.commit: this request will atomically apply surface state including
    the state of e.g. the xdg_surface object tied to the wl_surface.
    
    To update the protocol to reflect this new requirement we can either:
    
    - **Bump xdg_output version**. The current protocol doesn't specify that
      wl_output.done must be sent, adding this new requirement would be a breaking
      change. We need to fix Xwayland for the current xdg_output version (maybe make
      it non-atomic for the current version, atomic for the new one?). Should we
      deprecate xdg_output.done in the new version?
    - **Don't bump xdg_output version**. This clarifies what is expected in practice
      by Xwayland, a major xdg_output consumer, and what is currently implemented by
      all compositors.
    
    There's one issue with the "don't bump" approach: indeed in practice compositors
    always send wl_output.done and xdg_output.done in pairs, however the ordering
    between those two events is not guaranteed. This means some compositors might
    send this sequence:
    
        wl_output.geometry(…)
        wl_output.done()
        xdg_output.logical_position(…)
        xdg_output.done()
    
    In this case the wl_output.done event fails to atomically apply the xdg_output
    state.
    
    For this reason, I think bumping the version is a better approach.
    
    This commit also deprecates xdg_output.done, which doesn't have any purpose
    anymore.
    
    [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html
    [2]: https://phabricator.kde.org/D19253
    [3]: https://github.com/swaywm/sway/issues/4064Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
    Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
    962dd535
Name
Last commit
Last update
m4 Loading commit data...
stable Loading commit data...
tests Loading commit data...
unstable Loading commit data...
.gitignore Loading commit data...
COPYING Loading commit data...
Makefile.am Loading commit data...
README Loading commit data...
autogen.sh Loading commit data...
configure.ac Loading commit data...
wayland-protocols-uninstalled.pc.in Loading commit data...
wayland-protocols.pc.in Loading commit data...