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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
