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

[Adam Jackson]

(apologies for being so slow to get to this thread, this is great stuff)

On Mon, 2016-11-28 at 15:47 +0200, Pekka Paalanen wrote:

> Hi,
> 
> having read the above two specs, it is very much not obvious how to
> connect all the dots. It needs experimenting.
> 
> Would it be acceptable to build the knowledge of all these sync
> protocols into Xwayland server?

Sure. I'd started down these lines a while ago:

https://cgit.freedesktop.org/~ajax/xserver/log/?h=wayland-deferred-surface

Please do steal from that, specifically the bit where it adds a real
property callback. Your patch series hangs that off XACE, which is
still optional (and merely requiring it for Xwayland is a bit awkward
since it means you can't do both XACE-enabled and -disabled servers
from the same build pass).

> The thing there is that Xwayland is issuing the wl_surface.commits, and
> having XWM to explicitly trigger all commits always seems like
> unnecessary overhead. However, Xwayland does not know when to commit if
> it doesn't understand the X11 sync protocols. Either every commit
> for every window has to roundtrip through XWM, or Xwayland needs to
> understand stuff. Or the third option, which I like the least, is to
> have the Wayland compositor special-case all surface from Xwayland and
> put them through a completely different and new code paths not shared
> with anything.

Agreed, having the wm uncork commits is insane. xserver is best
positioned to make these decisions, and if that means teaching it about
client IPC conventions, okay.

> Anyway, we have three different kinds of X11 apps:
> - no sync
> - basic sync
> - extended sync
> 
> For the no-sync kind I think we still need something like my patch
> series. The other sync types would build on top, either by extending or
> replacing _XWAYLAND_ALLOW_COMMITS - or even just leaving it to XWM as a
> master switch of commits.

As mentioned further downthread the extended sync case isn't that
interesting since it's really only gtk3.

For the no-sync case I think xwayland gets to invent whatever semantics
it likes best. Without a zwl_x11_compat protocol (see below) I think
that means resizes necessarily flush commits through but that surface
content updates can be corked until the next frame. And then for basic
sync clients, resizes wait for the netwm protocol before flushing
instead.

> Mind, I am mostly thinking this in Weston XWM terms, which draws the
> window decorations through X11 like a normal window manager.

That's fine. Honestly I'd prefer a world where the wayland server was
not also the window manager, you should be able to run twm if you want
(and have it work about as well as, say, twm on win32). That'd need an
x11 compat protocol to really handle well, but again, okay. I think
that's _better_ than the current model, where mutter just magically
knows to get X geometry info through this side channel and therefore
has to worry about races, instead of Xwayland always presenting a
logically consistent view of its world to the wayland server.

- ajax