[regression] weston errors with atomic and Xwayland

As part of implementing multi-buffering in Xwayland (xorg/xserver!316 (merged)) to fix xorg/xserver#835 (closed), I stumbled across a recent regression in Weston.

What xorg/xserver!316 (merged) does is to keep a poll of wl_buffers and keep them around untouched as long as the Wayland compositor hasn't released the buffer to avoid the X11 client from updating the wl_buffer behind's the compositor back after it's been committed.

Xwayland with xorg/xserver!316 (merged) won't destroy a buffer if it is still not released by the compositor, but may very well do so if the buffer is released.

With xorg/xserver!316 (merged) and weston from current master, sometimes Weston throws some errors and then hangs:

[11:41:54.954] atomic: couldn't commit new state: Invalid argument
[11:41:54.954] repaint-flush failed: Invalid argument

A quick git bisect shows this as the first bad commit:

2538aaccc7bef6d6f790731aa4697071eb00e23a is the first bad commit
commit 2538aaccc7bef6d6f790731aa4697071eb00e23a
Author: Marius Vlad <marius.vlad@collabora.com>
Date:   Mon Oct 14 11:05:30 2019 +0300

    backend-drm: Construct a zpos candidate list of planes
    
    In order to better optimize view assignment to HW planes, we construct
    an intermediary zpos candidate list which is used aggregate all suitable
    planes for handling scan-out capable client buffers.
    
    We go over it twice: once to construct it and once to pick-and-choose a
    suitable plane based its highest zpos position.
    
    In order to maintain the view order correctly we track current zpos
    value being applied to the plane state and use it when trying to place
    a view into a plane.
    
    Pass the computed zpos value to be applied to the plane state.
    
    Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
    Suggested-by: Daniel Stone <daniel.stone@collabora.com>

:040000 040000 20ff31044faeac2bc7cdbb8b3db7ac16c59ab0a8 98e6526ffbb6b53c4a9983bda9163b99824ed543 M	libweston

Also, this may leave the surface visible on screen when swithing to another VT.

Steps to reproduce:

1. Apply xorg/xserver!316 (merged) to Xwayland, build and install

2. Start weston (current master, as of today commit 9c4b5c49)

3. Start gtk3-demo under X11:

   $ GDK_BACKEND=x11 gtk3-demo

4. Resize the gtk3-demo window

Actual result:

Weston will log errors and hang

Expected results:

No hang

Additional info:

This occurs with gtk3-demo with x11, but not other clients such as xterm, not sure why.

But gtk3-demo uses CSD even under X11 so it has no frame (from weston), maybe that's related.