SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
At this point in time I really only care about functional bug reports.
I can haz then a really, BUT really, really functional bug report?
The stock XWayland server from Slackware-current is broken (in my subjective empirical opinion, over half of Wayland/Plasma5 crashes are provoked by it) and it is slow like the Holly Snail - because (and not only) it implements its Glamour API on top of Softpipe.
Heck, they do not used even the LLVMpipe! You can believe this?
This affects ANY Wayland desktop environment you imagine, not only Wayland/Plasma5.
Proposed solution: switch to the stand-alone Xwayland server releases of same Xorg, which releases fixes all those issues.
Last edited by LuckyCyborg; 04-15-2021 at 02:05 PM.
My proposal is to stop to create a wish-list of fixes, improvements etc. Dealing with all points on this wish-list may delay Slackware release about next 6 months. So be careful what you wish. As AlienBob said with true modesty: Slackware is not 100% perfect.
My proposal is to stop to create a wish-list of fixes, improvements etc. Dealing with all points on this wish-list may delay Slackware release about next 6 months. So be careful what you wish. As AlienBob said with true modesty: Slackware is not 100% perfect.
None of those things will delay Slackware with 6 months...
Because all is about some minor things which we already did ourselves so many times, to bring up our Wayland/Plasma5 at least at the level of the one from openSUSE, which is the best today.
Consumes some time only the Qt5 rebuilding - this when the builder has a 45W CPU at disposition, like me. I talk about a count of 10 hours.
BTW, there's stand-alone XWayland's SlackBuild
Code:
#!/bin/bash
# Copyright 2016, 2018, 2019 Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
cd $(dirname $0) ; CWD=$(pwd)
PKGNAM=xorg-server-xwayland
SRCNAM=xwayland
VERSION=${VERSION:-$(echo $SRCNAM-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
BUILD=${BUILD:-1}
# Default font paths to be used by the X server:
DEF_FONTPATH="/usr/share/fonts/misc,/usr/share/fonts/local,/usr/share/fonts/TTF,/usr/share/fonts/OTF,/usr/share/fonts/Type1,/usr/share/fonts/CID,/usr/share/fonts/75dpi/:unscaled,/usr/share/fonts/100dpi/:unscaled,/usr/share/fonts/75dpi,/usr/share/fonts/100dpi,/usr/share/fonts/cyrillic"
NUMJOBS=${NUMJOBS:-" -j$(expr $(nproc) + 1) "}
# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) export ARCH=i586 ;;
arm*) export ARCH=arm ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) export ARCH=$( uname -m ) ;;
esac
fi
# If the variable PRINT_PACKAGE_NAME is set, then this script will report what
# the name of the created package would be, and then exit. This information
# could be useful to other scripts.
if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then
echo "$PKGNAM-$VERSION-$ARCH-$BUILD.txz"
exit 0
fi
if [ "$ARCH" = "i586" ]; then
SLKCFLAGS="-O2 -march=i586 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
SLKCFLAGS="-O2 -march=i686 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
else
SLKCFLAGS="-O2"
LIBDIRSUFFIX=""
fi
TMP=${TMP:-/tmp}
PKG=$TMP/package-$PKGNAM
rm -rf $PKG
mkdir -p $TMP $PKG
cd $TMP || exit 1
rm -rf $PKGNAM-$VERSION
tar xvf $CWD/$SRCNAM-$VERSION.tar.?z || exit 1
mv $SRCNAM-$VERSION $PKGNAM-$VERSION || exit 1
cd $PKGNAM-$VERSION || exit 1
chown -R root:root .
find . \
\( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
-exec chmod 755 {} \+ -o \
\( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
-exec chmod 644 {} \+
# Configure, build, and install:
export CFLAGS="$SLKCFLAGS"
export CXXFLAGS="$SLKCFLAGS"
mkdir meson-build
cd meson-build
meson setup \
--prefix=/usr \
--libdir=lib${LIBDIRSUFFIX} \
--libexecdir=/usr/libexec \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--includedir=/usr/include \
--datadir=/usr/share \
--mandir=/usr/man \
--sysconfdir=/etc \
--localstatedir=/var \
--buildtype=release \
-Dxwayland_eglstream=true \
-Ddefault_font_path="${DEF_FONTPATH}" \
-Dbuilder_string="Build ID: $PKGNAM $VERSION-$BUILD" \
-Dxkb_output_dir=/var/lib/xkb \
-Dvendor_name="Slackware Linux Project" \
-Dxdmcp=false \
-Dxcsecurity=true \
-Dglamor=true \
-Ddri3=true \
.. || exit 1
"${NINJA:=ninja}" $NUMJOBS || exit 1
DESTDIR=$PKG $NINJA install || exit 1
cd ..
# Remove unwanted files/dirs:
rm $PKG/usr/man/man1/Xserver.1*
rm -Rf $PKG/usr/lib${LIBDIRSUFFIX}/xorg
rm -Rf $PKG/usr/include/xorg
rm -Rf $PKG/usr/share/aclocal
rm -Rf $PKG/var/lib/xkb
# Strip the binaries:
find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \
| cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
# Compress and link manpages, if any:
if [ -d $PKG/usr/man ]; then
( cd $PKG/usr/man
for manpagedir in $(find . -type d -name "man*") ; do
( cd $manpagedir
for eachpage in $( find . -type l -maxdepth 1) ; do
ln -s $( readlink $eachpage ).gz $eachpage.gz
rm $eachpage
done
gzip -9 *.?
)
done
)
fi
mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION
cp -a \
AUTHORS COPYING* CREDITS INSTALL NEWS README* \
$PKG/usr/doc/$PKGNAM-$VERSION
# If there's a ChangeLog, installing at least part of the recent history
# is useful, but don't let it get totally out of control:
if [ -r ChangeLog ]; then
DOCSDIR=$(echo $PKG/usr/doc/${PKGNAM}-$VERSION)
cat ChangeLog | head -n 1000 > $DOCSDIR/ChangeLog
touch -r ChangeLog $DOCSDIR/ChangeLog
fi
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
cd $PKG
/sbin/makepkg -l y -c n $TMP/$PKGNAM-$VERSION-$ARCH-$BUILD.txz
and the slack-desc
Code:
# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description. Line
# up the first '|' above the ':' following the base package name, and the '|' on
# the right side marks the last column you can put a character in. You must make
# exactly 11 lines for the formatting to be correct. It's also customary to
# leave one space after the ':'.
|-----handy-ruler------------------------------------------------------|
xorg-server-xwayland: xorg-server-xwayland (X Clients under Wayland)
xorg-server-xwayland:
xorg-server-xwayland: Wayland is a complete window system in itself, but even so, if we're
xorg-server-xwayland: migrating away from X, it makes sense to have a good backwards
xorg-server-xwayland: compatibility story. With a few changes, the Xorg server can be
xorg-server-xwayland: modified to use Wayland input devices for input and forward either the
xorg-server-xwayland: root window or individual top-level windows as wayland surfaces. The
xorg-server-xwayland: server still runs the same 2D driver with the same acceleration code
xorg-server-xwayland: as it does when it runs natively. The main difference is that Wayland
xorg-server-xwayland: handles presentation of the windows instead of KMS.
xorg-server-xwayland:
Of course Wayland/Plasma is important for you - for other people other things are more important. Essentially not every one Slackware user is using KDE/Plasma. Now if everyone will post here what thinks is important and need to be fixed - then I am sure 6 months won't be enough. To tell the truth I really don't care totally about Wayland. For me just may not exists at all. I need basic functionality ok, not to take care about beautification. Just paint your monitor if you think it looks ugly.
Edit:I may add that the race with RHEL derivatives to have working Wayland is senseless.
Wayland is necessary in the long run because Xorg is in fact spaghetti code, but it works. Wayland just isn't a requirement today or this year... but soon, because there are very few people still alive that developed code for Xorg that is still in there to this day. It is a patchwork quilt and many of the (interconnected) patches are barely remembered or understood as to the hows and whys.
I can haz a really, BUT really, really functional bug report?
The stock XWayland server from Slackware-current is broken (in my subjective empirical opinion, over half of Wayland/Plasma5 crashes are provoked by it) and it is slow like the Holly Snail - because (and not only) it implements its Glamour API on top of Softpipe.
Heck, they do not used even the LLVMpipe! You can believe this?
This affects ANY Wayland desktop environment you imagine, not only Wayland/Plasma5.
Proposed solution: switch to the stand-alone Xwayland server releases of same Xorg, which releases fixes all those issues.
I would like a lot of things to be applied to slackware-current, among which fully functional Wayland sessions, a pipewire server setup that can replace pulseaudio, but I know the limits of a distro which is maintained by a single person. Therefore I would gladly leave all of that for a post-15.0 slackware-current.
This is all stuff that is not hard to bolt on yourself after a stable release, as long as the core packages are properly built. And right now, I think that only would apply to the 'qt5' package.
Xwayland can be provided from a 3rd-party repository but qt5 is not trivial to compile and takes a long time too.
Ideally 'qt5-webengine' should be split off the 'qt5' package so that we can have the latest Chromium patches and - just as relevant - end up with a slimmed-down 'qt5' which is considerably faster to compile and recompile.
But there's not more of distro tweaking that I would like to see beyond this.
Wayland is necessary in the long run because Xorg is in fact spaghetti code, but it works. Wayland just isn't a requirement today or this year... but soon, because there are very few people still alive that developed code for Xorg that is still in there to this day. It is a patchwork quilt and many of the (interconnected) patches are barely remembered or understood as to the hows and whys.
I would like a lot of things to be applied to slackware-current, among which fully functional Wayland sessions, a pipewire server setup that can replace pulseaudio, but I know the limits of a distro which is maintained by a single person.
Well, hmm... I can raise the hand, please?
With all respect, IF you do not noticed yet, I would like to inform you that we already have for Slackware a PipeWire server setup that can replace successfully the PulseAudio server. And we already use it.
I for one, I use it since some time, because it have way better performances on handling the Bluetooth audio devices.
Yes, it works fine also on standard X11 sessions of whatever DE - the single condition is that that DE to be XDG-autostart aware, of other things takes care ZhaoLin1457's little daemon supervisor...
With all respect, IF you do not noticed yet, I would like to inform you that we already have for Slackware a PipeWire server setup that can replace successfully the PulseAudio server. And we already use it.
Alien is worried that implementing those properly for Slackware will require more testing on something that it seems like is not Pat's priority for the 15.0 release. As Alien said, it seems that Wayland was not added to -current for a perfect implementation, but rather to give users a starting point that they can work on. All the work being done on Wayland is great right now, but Alien's worry is that if Pat focuses on getting Wayland as functional as possible in -current today, will delay 15.0 even further. You might think it's ready for prime time, but that doesn't mean that Pat does.
At least, if 15 is soon released, I hope these changes, wayland and pipewire, will very soon land in current for extensive testing.
I would understand this way to have sooner a release and not so far a .1 release !
Alien is worried that implementing those properly for Slackware will require more testing on something that it seems like is not Pat's priority for the 15.0 release. As Alien said, it seems that Wayland was not added to -current for a perfect implementation, but rather to give users a starting point that they can work on. All the work being done on Wayland is great right now, but Alien's worry is that if Pat focuses on getting Wayland as functional as possible in -current today, will delay 15.0 even further. You might think it's ready for prime time, but that doesn't mean that Pat does.
Mr. Hameleers have no reasons to worry about eventually delays on Slackware by making the Wayland as functionally as possible in -current today.
Because we already did this job, and as someone who literally uses this particular desktop environment, I tell you that we reached something similar with what openSUSE achieved. And looks like no one is better at packaging Wayland/Plasma5 yet.
How long takes for this genius developer who's our BDFL to integrate our small changes? An evening? My bet is still for ONE HOUR.
Because in the end, that's all about: some small changes. And I talk from the position of someone who knows what's about.
BUT, imagine that after few months after Fedora announces like a roaster that they uses PipeWire for audio, Slackware announce too that we are "PipeWire ready, but not as default" and that's the truth, we already are ready. Just like them.
Imagine also that the bloggers who will test Wayland/Plasma5 on Slackware 15.0, will discover that it is as rock solid like is on openSUSE. Not perfect, BUT no one's better too. While, Slackware announced only, with modesty, that we are "Wayland/Plasma5 ready, but not as default", which is the truth, we are already ready.
Our really small contribution to Slackware can be a very good PR for Slackware, IF it is played right...
Trust a Russian - after all we won the Space Race with a ball of steel, on which was enclosed a battery and a radio transmitter on vacuum tubes, who did: beep, beep, beep.
You known it as Sputnik, BTW...
Last edited by LuckyCyborg; 04-15-2021 at 03:43 PM.
Mr. Volkerding will make the final call on what is included, implemented in 15.0. This isn't a democracy; our BDFL has a proven track record of getting it right. This development model works for me. I like where Beta 1 is heading.
Well, I know what happened. I told the guy in my reply yesterday that this was a valid bug report, but it was buried in 500 pages of requests. Some things fall through the cracks.
Slackware needs a pinned bug report thread on here to separate the bug reports from the requests.
With all respect, IF you do not noticed yet, I would like to inform you that we already have for Slackware a PipeWire server setup that can replace successfully the PulseAudio server. And we already use it.
I for one, I use it since some time, because it have way better performances on handling the Bluetooth audio devices.
Yes, it works fine also on standard X11 sessions of whatever DE - the single condition is that that DE to be XDG-autostart aware, of other things takes care ZhaoLin1457's little daemon supervisor...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.