[PATCH weston 00/11] XWayland update for 1.0

[Daniel Stone]

Hi,


On 8 November 2012 04:06, Tiago Vignatti <tiago.vignatti at linux.intel.com>wrote:

> 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:
>
> XWayland: Add init_complete protocol
> XWayland: Port to Wayland 1.0 API
>
> and on Weston this one:
>
> XWayland: Only initialise WM on signal from the server
>
> and now XWayland is working like expected against Wayland 1.0.


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


> I'm quite sure we can even work better the WM initialization (maybe calling
> weston_wm_create in the idle handler) and remove the need for the
> init_complete request you're introducing.


Hm, the idle handler still doesn't help, because the race you get on slower
machines is:
  - Weston spawns X server
  - X server spends ages trying to load modules, etc
  - Weston hits idle loop
  - Weston starts window manager, which tries to connect to X socket
  - X server has, in the meantime, started doing roundtrips to the Wayland
server, waiting for outputs to become visible before it clears ScreenInit
  - X server is waiting on Wayland compositor, which is blocked on X server
...

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.


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

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.


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

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.

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!

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20121108/c053a2c1/attachment.html>