While it is possible to run X clients in Weston by loading the xwayland.so module, running X window managers in an ordinary Weston session doesn't work because Weston normally runs its own window manager.

For those who would like to get on the Wayland bandwagon but don't want to give up on their favorite X window manager yet, here is Xweston, a little hack to try and make X window managers run in Weston.

Xweston runs Weston with a dummy shell client, which means there is no Weston window manager running, it now becomes possible to run an X window manager or even a display manager instead.



X session running i3 running Xweston running i3. Note the weston-terminal on top of the two tiled xterms.

Installation and setup

To try out Xweston, build and install the package from the AUR.

No further configuration is needed.

Next, start Xweston like a normal X session, specifying Xweston as the server to use. For example:

$ startx -- /usr/bin/Xweston

If all goes well, Weston and Xwayland should start, followed by the X clients and/or window manager which you have specified in ${HOME}/.xinitrc .

Contributing

The source code is licensed under the GPL version2, and is hosted on Github. Any issue reports, pull requests, Wiki edits are very welcome.

Tested display managers

LightDM - Works. To add a dynamic seat using LightDM, do: # dm-tool add-seat xlocal xserver-command=/usr/bin/Xweston

Tested window managers

awesome - Works.

dwm - Works.

i3 - Works, but i3bar icons don't respond to hovering or clicking.

LXQt? - Works.

OpenBox - Starts, but has invisible menu & window decorations.

PekWM - Some problems.

ratpoison - Works.

wmii - Works.

XMonad (+XMobar + dmenu) - Works.

Known issues

When running Xweston in an existing X session, be sure that any keys to be used by the X window manager running in Weston aren't being captured by either Weston or the hosting X window manager. Remap them if needed.

Sometimes the mouse pointer doesn't show up until the first X client is started. An obvious workaround is to start one, such as an xterm (don't forget to put it in the background by adding an `&`!) before exec'ing the window manager.

When Xweston is started from a VT, it is possible that on quitting the X window manager, Weston doesn't shut down properly. If there is no X running on another VT, it may not be possible to switch VTs in order to try and kill Weston. Be warned!

Running (X)weston from a VT on systems with ATI video cards can result in system freezes or kernel panics involving radeon_crtc_handle_flip. This will hopefully be fixed with Linux kernel 3.16.

When running in a separate session on a VT, switching VTs may not work well, this is most often caused by Xwayland segfaulting. Known upstream, AFAICT, a fix is in the works.

When running in a session started from a display manager, trying to run native Wayland applications results in "Permission denied" errors. This is because the wayland-0 socket (which starts out owned by root) is not shared with the running user yet. Workaround (assuming $USER is in the group 'users', note the security implications!), do: # chown :users /tmp/.Xweston/ # chown $USER /tmp/.Xweston/$DISPLAY # chown $USER /tmp/.Xweston/$DISPLAY/wayland-0 then do: $ ln -s /tmp/.Xweston/$DISPLAY/wayland-0 "$XDG_RUNTIME_DIR/wayland-${DISPLAY#:}" $ export WAYLAND_DISPLAY=wayland-${DISPLAY#:}

It goes without saying that all of this is highly experimental, and that I cannot guarantee anything whatsoever. Please let me know what you think of it. Suggestions and fixes are very welcome.

Thanks to all for reporting their experiences

Last edited by ackalker (2014-08-15 13:59:15)