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

[Adam Jackson]

On Wed, 2016-12-07 at 12:49 +0200, Pekka Paalanen wrote:

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

I guess I should have said "steal whatever you need from that". The
property callback I'll insist on, the rest you can take or leave as you
wish.

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

A commit that doesn't change surface dimensions is something X can
withhold from Wayland until the next frame (or whenever). So you might
have a sequence like:

A: PutImage
B: PutImage
C: ConfigureWindow

A and B would merely mark X's view of the surface as dirty, and we'd
commit that at the next frame; but if C happens before the next frame,
then because the wayland server is getting geometry via the X protocol
the wayland view of the surface needs to match that geometry, and thus
we would need to commit immediately, "flushing" the putimages through.

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

Probably. Doesn't handle explicit window coordinates though.

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

I don't think that's something I could answer in advance of actually
having written the protocol. (Or rather: answering it definitively
would require having written something that works correctly.)

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

Sure why not. I think what I'm saying is, if that wayland server
exposes at least some shell protocol and the compat extension, then
X+twm should work like it does on (say) cygwin, and if that ends up
breaking your shell metaphor, don't expose the compat extension.
Rootful mode will work either way.

The wayland server would of course be free to only expose the compat
extension to clients that it knows are Xwayland, if it really wanted to
make native clients work worse than X11.

- ajax