(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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
