[OE-core] [<OE-core][PATCH v2 1/4] weston-init: Handle Weston startup correctly.

[Tom Hochstein]

Hi Otavio,

I'm still not clear on your proposal. Here is my last proposed weston-start script (called from sysvinit and systemd):

#! /bin/sh
# There are multiple ways to start weston.
if [ "$WAYLAND_DISPLAY" ]; then
    echo -e "\aError: Weston is already running."
    echo "This script does not support launching Weston nested."
    exit 1
else
    if [ "$DISPLAY" ]; then
        echo "Launching Weston"
        openvt -s -- sh -c "weston -- $OPTARGS > /var/log/weston.log 2>&1"
    else
        echo "Launching Weston"
        export XDG_CONFIG_HOME=/etc
        if [ -f /usr/lib/weston/xwayland.so ]; then
            mkdir -p /tmp/.X11-unix
            OPTARGS="--modules=xwayland.so $OPTARGS"
        fi
        openvt $OPENVT_ARGS -- sh -c "weston-launch -- $OPTARGS > /var/log/weston.log 2>&1"
    fi
fi

Do you want to move this whole script to weston-launch? I think that doesn't make sense because it would unexpectedly change the fundamental behavior of weston-launch for the user.

Or do you want to keep weston-start and just move the weston-launch portion of the script (the last else-statement) to the new weston-launch script, something like this:

#! /bin/sh
export XDG_CONFIG_HOME=/etc
if [ -f /usr/lib/weston/xwayland.so ]; then
    mkdir -p /tmp/.X11-unix
    MODULES="--modules=xwayland.so"
    OPTARGS="$MODULES $OPTARGS"
fi
if [ $USE_OPENVT ]; then
    openvt $OPENVT_ARGS -- sh -c "/usr/bin/weston-wrapped/weston-launch -- $OPTARGS > /var/log/weston.log 2>&1"
else
    /usr/bin/weston-wrapped/weston-launch "$@"
Fi

Regarding your idea for the separate xwayland script file, there is a usage problem if the user wants to change his deployed image from Wayland to XWayland. Since the script file is not there, it is hard to know the appropriate settings for this reconfiguration.

Instead, I propose to add a new variable in the script called 'USE_XWAYLAND', to be initialized by Yocto based on user preference, and easily changed after deployment:

#! /bin/sh
USE_XWAYLAND="1"
if [ $USE_XWAYLAND = "1" ]; then
    mkdir -p /tmp/.X11-unix
    MODULES="--modules=xwayland.so"
    OPTARGS="$MODULES $OPTARGS"
Fi

Do you think I should pursue your proposed idea of a new image or DISTRO_FEATURE to control the initial state of USE_XWAYLAND?

Tom

-----Original Message-----
From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br] 
Sent: Monday, December 21, 2015 5:24 AM
To: Thomas Hochstein <Tom.Hochstein at freescale.com>
Cc: Prabhu Sundararaj <Prabhu.Sundararaj at freescale.com>; Patches and discussions about the oe-core layer <openembedded-core at lists.openembedded.org>
Subject: Re: [OE-core] [<OE-core][PATCH v2 1/4] weston-init: Handle Weston startup correctly.

Hello Tom,

On Sat, Dec 19, 2015 at 4:08 PM, Tom Hochstein <Tom.Hochstein at freescale.com> wrote:
> Can you be more explicit about what you mean by weston-launch wrapper? Do you want to hide the current weston-launch binary and replace it by a new weston-launch wrapper? What happens to my proposed weston-start, which is itself a wrapper? Does its functionality move into weston-launch?

Yes; my proposal is to use weston-launch to hide the real binary and call it internally. This allows for everyone using weston-launch (even on terminal or serial console) to benefit from it otherwise people will be aware of the custom script.

> Can you help me understand the rationale for the extra XWayland script? The existing weston recipe installs xwayland.so when the XWayland package is specified. In your proposal, the weston recipe would also install the extra script when the XWayland package is specified. Since the same XWayland package mechanism is used in both cases, the benefit of the extra script isn't clear to me.

Because it would allow for same distro to generate one XWayland based image[1] and another pure Wayland image[2].

1. xserver-xorg-xwayland (a) -> weston-module-xwayland (b)

   So (a) includes the inner script which says to weston-launch wrapper to load the xwayland.so module. (b) is split out from normal weston package so it avoids unneeded runtime dependencies.

2. weston

  weston includes just the normal weston bits so allowing pure Weston images without manual changes.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750