[RFC xserver 0/3] Allow XWM to control Xwayland commits

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>

Hi,

this is probably the first time I'm sending patches for the xserver, so
pointing out API misuse, coding style issues etc. would be appreciated. The
last patch also has some XXX comments with questions.

The first patch, refactoring, is not absolutely necessary (anymore - I used to
have a use for it while brewing this), but I think it makes things look nicer.

The fundamental problem is that Xwayland and the Wayland compositor (window
manager) are racing, particularly when windows are being mapped. This can lead
to glitches. The specific glitch I bumped into is described at
https://phabricator.freedesktop.org/T7622 .

The proposed solution allows the WM to temporarily prohibit commits.

It would be awkward for Weston to postpone mapping certain windows since it
would leak quite much Xwayland into the heart of the window manager. A Wayland
compositor also cannot ignore commits, because Xwayland will wait for frame
callbacks until it commits again. To not get stuck, one would need to fire
frame callbacks outside of their normal path. It seems much simpler to just
control Xwayland's commits, which also ensures that the first commit will carry
fully drawn window decorations too.

This series is the Xwayland side of the fix to T7622. The Weston side is still
brewing, but I was able to test that the Xwayland code works.


Thanks,
pq

Pekka Paalanen (3):
  xwayland: refactor into xwl_window_post_damage()
  xwayland: fix 'buffer' may be used uninitialized warning
  Xwayland: use _XWAYLAND_ALLOW_COMMITS property

 hw/xwayland/xwayland.c | 166 ++++++++++++++++++++++++++++++++++++++++++-------
 hw/xwayland/xwayland.h |   3 +
 2 files changed, 146 insertions(+), 23 deletions(-)

-- 
2.7.3