[PATCH weston 17/17] xwayland: Fix window positioning

[Tiago Vignatti]

On 11/30/2012 10:01 PM, Bill Spitzak wrote:
> Tiago Vignatti wrote:
>
>> The approach used here shows a weakness of the Weston WM-as-client
>> architecture: one cannot guarantee that the X11 stream needed to create
>> windows with its right position will happen before Weston maps the
>> surface,
>> via Wayland. IOW we'd like always ConfigureNotify with the coordinates
>> coming
>> and only then Wayland compositor could map the surface:
>>
>>     1. xwm: gets XCB_CREATE_NOTIFY (via X11)
>>     2. xwm: gets XCB_CONFIGURE_NOTIFY (via X11)
>>     3. weston: gets correct position (wm_get_window, via Wayland)
>>     4. weston: maps the surface (xserver_get_window_surface, via X11)
>>
>> but it was happening:
>>
>>     1. xwm: gets XCB_CREATE_NOTIFY (via X11)
>>     2. weston: maps w/ wrong position (xserver_get_window_surface, via
>> X11)
>>     3. xwm: gets XCB_CONFIGURE_NOTIFY (via X11)
>>     4. weston: gets outdated position (wm_get_window, via Wayland)
>
> How come the compositor knows anything about a window before the xserver
> has decided to really physically map it (not the map override, but the
> real map)? It would seem that if it did not hear anything until after
> xwm got the XCB_CONFIGURE_NOTIFY there would be no synchronization
> problem and no need for the extra messages you are proposing adding.

as I said, the X server has two protocol streams in which messages 
cannot be ordered. Say that ConfigureNotify (via X11) arrives in xwm, 
the compositor might already have tried to map the X client content 
surface on screen because it got a xserver_get_window_surface (via 
Wayland). So I'm proposing here to wrap all the mapping stream via 
Wayland only.


> I may be missing a reason weston has to know the window exists before it
> is mapped. A *buffer* may be allocated, but I don't see a weston surface
> needing to exist at all.

Wayland doesn't let a client knows about the surface of other client. 
That being said, we have two Wayland clients on this architecture: the 
xwm which knows about the X window configuration and XWayland which owns 
the content surface of it. In order to map the content surface on 
screen, the compositor acts as the broker through combining the 
information of both clients and placing the X window on the right place.


     Tiago