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

[Bill Spitzak]

On Dec 3, 2012, at 9:19 AM, Tiago Vignatti wrote:

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

Would it be possible for the xserver to talk to the xwm process instead of it being a wayland client? Ie either:

    Wayland <---> xwm <---> xserver <---> xclient

or (I suspect more likely):

    Wayland <---> xserver <---> xclient
                               ^
                               v
                            xwm

I am very worried about the need to add a special "xwm" shell api to wayland. If wayland is unable to emulate x without adding internal support then something is missing from the desktop shell api. Note that rootless x servers have been implemented on OS/X and Windows and they certainly did not add any special xwm api to their internal servers! I am also very worried that clients (myself for instance) are going to use the xwm api for nefarious purposes, such as to get and set the window positions.