Weston xwm as a client

[Tiago Vignatti]

Hi. We were wondering about splitting the XWM from Weston into its own 
process. This email discusses that.


We have Xwayland as one process and weston + xwm as another on the 
current architecture. Xwayland is a Wayland client and it's the X 
server. xwm is a module of the Wayland server and a X client [0]. Quite 
often xwayland triggers a Wayland event that blocks while xwm is already 
blocked waiting a X request from xwayland [1]. There's too much 
potential for deadlock when we're working with two different protocol 
streams tied up with two different processes. Other cons of the current 
architecture is that we need a server-side "small toolkit" for window 
decoration and things like cursor settings.

Now, I see two possible solutions when breaking in xwayland, weston and 
xwm, where the last being a separate process:

     #1 solution: XWM maps the windows.
         - little tricky, since the xwm need to access the wl_surfaces 
of the xwayland client.
         - we'd need a way to share wl_surface objects among clients.
         - would avoid weston_shell_interface, since the xwm will now 
access it as a regular client.

     #2 solution: compositor maps the windows.
         - replicate inside the compositor all the windows position, 
surface and related information.
         - WM wayland protocol sends a configure window (wid, x, y, w, 
h) to the compositor, triggered at ConfigureNotify. Xwayland sends a 
set_window_id when realize_window is done with the surface created. 
Compositor combine both information acquired and maps the window on the 
screen (stack it properly, activate, etc).
         - we'd still need weston_shell_interface


These both solutions should solve the deadlock problem we're facing. 
Decoration drawing can be made now on client side, and cursor settings 
and all toolkit integration looks easier now. Also, IMHO just the fact 
of separate the Window Manager implies an architecture more modularized 
where it naturally fits better with the X one. Both solutions still 
create a shell_surface, which is great cause we can rotate, switch 
windows, etc.  The first solution requires more thoughts and more 
understanding but looks more pretty a bit. The second solution still 
requires some internal interfaces on Weston just for Xwayland, but it 
seems more easy to implement.

In fact I've started a draft of second solution and it seems to work 
okey so far: surface mapping, move, resize and decoration all work as 
expected [2]. I'm pasting the new private protocol to discuss here. I'm 
sure there's a lot to do (for instance the connection protocol and its 
set up) but maybe now we could talk whether this is really feasible or 
not for our purposes? Please comment on, thanks!


<protocol name="xwayland">

   <interface name="xserver_connect" version="1">
     <description summary="handle X server XWayland start-up connections">
         Used by Xwayland X server only.
     </description>

     <event name="wm">
       <description summary="send window manager socket fd">
         This is one tip of the opened socket pair; the other has to be 
sent via wm_connect interface in order to plug both X server and 
Xwayland Window Manager. This event must be used only once.
       </description>
       <arg name="fd" type="fd"/>
     </event>

     <event name="client">
       <description summary="send client to be listened on opened fd">
         In principle, this is used to send the first real client to 
XWayland, the one that triggered its initialization but had to wait for 
the Window Manager (WM) gets connected before. A good practice is to 
forward this event when WM is bound, meaning that it's ready to sniff 
other clients.
       </description>
       <arg name="fd" type="fd"/>
     </event>
   </interface>

   <interface name="xserver" version="1">

     <request name="set_window_id">
       <arg name="surface" type="object" interface="wl_surface"/>
       <arg name="id" type="uint"/>
     </request>
   </interface>

   <interface name="wm_connect" version="1">
     <description summary="handle Xwayland Window Manager start-up 
connections">
         Used by Xwayland Window Manager only.
     </description>

     <event name="xserver">
       <description summary="send Xwayland socket fd">
         This is the other tip of the socket pair.
       </description>
       <arg name="fd" type="fd"/>
     </event>
   </interface>

   <interface name="wm" version="1">

     <enum name="window">
       <entry name="inactive" value="0x1" summary="do not set keyboard 
focus"/>
     </enum>

    <request name="set_window">
      <description summary="specify window id, geometries and positioning">
         Teaches the compositor about the window id and its 
configuration regarding size and location on the screen. The compositor 
is responsible for looking the surface based on the id and map it on the 
screen. The x and y arguments specify the global position of the surface 
on the current output -- exactly how X11 works. The flags argument is 
used to control whether the surface will receive the keyboard focus or 
not, after being mapped.
      </description>

       <arg name="id" type="uint"/>
       <arg name="x" type="int"/>
       <arg name="y" type="int"/>
       <arg name="width" type="int"/>
       <arg name="height" type="int"/>
       <arg name="flags" type="uint"/>
     </request>

     <request name="move">
       <arg name="id" type="uint"/>
     </request>

     <request name="resize">
       <arg name="id" type="uint"/>
       <arg name="edges" type="uint"/>
     </request>

     <event name="configure">
       <description summary="suggest resize">
         The configure event asks the client to resize its surface.
         The size is a hint, in the sense that the client is free to
         ignore it if it doesn't resize, pick a smaller size (to
         satisfy aspect ration or resize in steps of NxM pixels).  The
         client is free to dismiss all but the last configure event it
         received.
       </description>

       <arg name="id" type="uint"/>
       <arg name="edges" type="uint"/>
       <arg name="width" type="int"/>
       <arg name="height" type="int"/>
     </event>

     <event name="activate">
       <arg name="id" type="uint"/>
     </event>
   </interface>

</protocol>


[0] http://vignatti.files.wordpress.com/2012/06/xwayland.png
[1] http://paste.ubuntu.com/1137607/
[2] http://cgit.freedesktop.org/~vignatti/weston/log/?h=xwm-client