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

[Pekka Paalanen]

On Mon, 05 Dec 2016 16:43:24 -0500
Adam Jackson <ajax at nwnk.net> wrote:

> (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).

Hi Adam,

nice! Should I take only the property stuff, or should I try to
learn and integrate everything you have there?

I suppose I should start with only the property stuff and make my
mechanism work with that first.

> > 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.

Very good.

> > 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.

I'm not quite sure I understood the "flush commits through" part.

> > 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.

Indeed, the races are nasty. When looking into Weston XWM and how it
determines the input region and geometry of a surface (decorations
minus shadows) I was wondering if we could get Xwayland to just set the
right input region via Wayland. That would be just core Wayland, even.
Then we'd have the geometry sync'd with the right wl_surface.commits.

As for everything else, I couldn't say where the policies should be
set. That is, would zwl_x11_compat be written mainly in Wayland or X11
terms? I.e. who should be determining all the window types from X11
information which is lower level than what Wayland/desktop handles? It
is also possible that Wayland systems other than those using desktop
shell interfaces and concepts would still want to support Xwayland.
That is a quest I am unlikely to take on.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161207/47b3da4f/attachment-0001.sig>