[PATCH weston] man: weston --xserver has been replaced

[Kristian Høgsberg]

On Thu, Sep 13, 2012 at 01:46:27PM +0300, Pekka Paalanen wrote:
> The generic module loading must be used now to load xserver.so.
> Option --xserver was removed by
> a6813d28876423b388cce3ff6d7edab7b9de0f20.

Much better, thanks... I was wondering if we should special case the
shell plugin and load it last.  Or maybe we need to have two module
loading points like you say, an init-time and a up-and-running time...

Kristian

> Signed-off-by: Pekka Paalanen <ppaalanen at gmail.com>
> ---
>  man/weston.man |   36 +++++++++++++++++++++---------------
>  1 files changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/man/weston.man b/man/weston.man
> index 7b7ae43..7667076 100644
> --- a/man/weston.man
> +++ b/man/weston.man
> @@ -1,4 +1,4 @@
> -.TH WESTON 1 "2012-08-29" "Weston __version__"
> +.TH WESTON 1 "2012-09-13" "Weston __version__"
>  .SH NAME
>  weston \- the reference Wayland server
>  .SH SYNOPSIS
> @@ -22,11 +22,8 @@ under another Wayland server), it should be done with the command
>  .B weston-launch
>  to set up proper privileged access to devices.
>  
> -Weston also supports X clients by XWayland. XWayland requires a special
> -X.org server to be installed. This X server will connect to a Wayland
> -server as a Wayland client, and X clients will connect to the X server.
> -XWayland provides backwards compatibility to X applications in a Wayland
> -stack.
> +Weston also supports X clients via 
> +.BR XWayland ", see below."
>  .
>  .\" ***************************************************************
>  .SH BACKENDS
> @@ -70,6 +67,21 @@ and the special client
>  which provides the basic user interface.
>  .
>  .\" ***************************************************************
> +.SH XWAYLAND
> +XWayland requires a special X.org server to be installed. This X server will
> +connect to a Wayland server as a Wayland client, and X clients will connect to
> +the X server. XWayland provides backwards compatibility to X applications in a
> +Wayland stack.
> +
> +XWayland is activated by instructing
> +.BR weston " to load " xwayland.so " module, see " EXAMPLES .
> +Weston starts listening on a new X display socket, and exports it in the
> +environment variable
> +.BR DISPLAY .
> +When the first X client connects, Weston launches a special X server as a
> +Wayland client to handle the X client and all future X clients.
> +.
> +.\" ***************************************************************
>  .SH OPTIONS
>  .
>  .SS Weston core options:
> @@ -113,14 +125,6 @@ Weston will export
>  .B WAYLAND_DISPLAY
>  with this value in the environment for all child processes to allow them to
>  connect to the right server automatically.
> -.TP
> -.B \-\-xserver
> -Activate XWayland. Weston starts listening on a new X display socket, and
> -exports it in the environment variable
> -.BR DISPLAY .
> -When the first X client connects, Weston launches a special X server as a
> -Wayland client to handle the X client and all future X clients.
> -.
>  .SS DRM backend options:
>  .TP
>  \fB\-\-connector\fR=\fIconnectorid\fR
> @@ -220,8 +224,10 @@ http://wayland.freedesktop.org/
>  .
>  .\" ***************************************************************
>  .SH EXAMPLES
> -.IP "Launch Weston with the DRM backend, directly on a VT"
> +.IP "Launch Weston with the DRM backend on a VT"
>  weston-launch
> +.IP "Launch Weston with the DRM backend and XWayland support"
> +weston-launch -- --modules=xwayland.so
>  .IP "Launch Weston (wayland-1) nested in another Weston instance (wayland-0)"
>  WAYLAND_DISPLAY=wayland-0 weston -Swayland-1
>  .IP "From an X terminal, launch Weston with the x11 backend"
> -- 
> 1.7.8.6
>