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.salva...@ossystems.com.br]
Sent: Monday, December 21, 2015 5:24 AM
To: Thomas Hochstein <tom.hochst...@freescale.com>
Cc: Prabhu Sundararaj <prabhu.sundara...@freescale.com>; Patches and
discussions about the oe-core layer <openembedded-core@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.hochst...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
