staging only.Expand description
This protocol adds a xwayland_surface role which allows an Xwayland server to associate an X11 window to a wl_surface.
Before this protocol, this would be done via the Xwayland server providing the wl_surface’s resource id via the a client message with the WL_SURFACE_ID atom on the X window. This was problematic as a race could occur if the wl_surface associated with a WL_SURFACE_ID for a window was destroyed before the client message was processed by the compositor and another surface (or other object) had taken its id due to recycling.
This protocol solves the problem by moving the X11 window to wl_surface association step to the Wayland side, which means that the association cannot happen out-of-sync with the resource lifetime of the wl_surface.
This protocol avoids duplicating the race on the other side by adding a
non-zero monotonic serial number which is entirely unique that is set on
both the wl_surface (via. xwayland_surface_v1’s set_serial method) and
the X11 window (via. the WL_SURFACE_SERIAL client message) that can be
used to associate them, and synchronize the two timelines.
The key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in IETF RFC 2119.