Hi,<div class="gmail_extra"><br><br><div class="gmail_quote">On 8 November 2012 04:06, Tiago Vignatti <span dir="ltr"><<a href="mailto:tiago.vignatti@linux.intel.com" target="_blank">tiago.vignatti@linux.intel.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I was thinking only about porting XWayland for the new registry scheme and the surface atomic commit we've introduced in 0.95 -> 1.0. In fact, I've applied on X server these patches:<br>

</div>
<br>
XWayland: Add init_complete protocol<br>
XWayland: Port to Wayland 1.0 API<br>
<br>
and on Weston this one:<br>
<br>
XWayland: Only initialise WM on signal from the server<br>
<br>
and now XWayland is working like expected against Wayland 1.0.</blockquote><div><br></div><div>Ah, good to hear! I think most of the patches are still valuable on their own (fixing crashes, compile warnings, leaks, or in one case a failure to ever show proper window contents).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm quite sure we can even work better the WM initialization (maybe calling<br>
weston_wm_create in the idle handler) and remove the need for the init_complete request you're introducing.</blockquote><div><br></div><div>Hm, the idle handler still doesn't help, because the race you get on slower machines is:</div>

<div>  - Weston spawns X server</div><div>  - X server spends ages trying to load modules, etc</div><div>  - Weston hits idle loop</div><div>  - Weston starts window manager, which tries to connect to X socket</div><div>
  - X server has, in the meantime, started doing roundtrips to the Wayland server, waiting for outputs to become visible before it clears ScreenInit</div>
<div>  - X server is waiting on Wayland compositor, which is blocked on X server ...</div><div><br></div><div>I actually meant to look at if we could maybe move the socket passing later too (when the WM's ready), but forgot about it later whilst fixing a couple of the Weston SHM buffer bugs.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moreover, WM initialization touches exactly the guts of the work I've been carrying on lately, to split it as a client. So we'll be changing it anyway on the next. Then you're patching also the resize logic and the decoration drawing on XWM. Both I've worked already on xwm-as-a-client and would be changing drastically if we go with that solution.<br>

</blockquote><div><br></div><div>I'm more than happy to drop those for the moment and see if there's anything still to be done on XWM as a client.  It's definitely the better long-term approach.</div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I mean, my point is whether is worth to change that much now for 1.0.x only given we have the other XWayland private protocol I've been designing done in parallel.<br></blockquote><div><br></div><div>Well, I think we could take all the server patches (including init_complete), and drop the Expose and resize patches from Weston if you like.  But at the moment, XWayland doesn't build (on the server side), or start when you fix it building, or show any window contents when you fix it starting, or resize properly when you fix the window contents.  So I think we definitely need to get it fixed one way or another, but if there's anything that touches protocol between the compositor and server, then there's no point having my branch and the client-side stuff diverge.</div>
<div><br></div><div>I'm going to take a look at your branch today and see what I can make of it.  Thanks for taking a look at mine!</div>
<div><br></div><div>Cheers,</div><div>Daniel </div></div></div>