I found the gamma setting on one of the builds needed some fiddling - have you tried that ?
Gamma was 1.2 by default, reduced it to 1.0 when setting things up. To be honest, going as low as 0.1, I'm seeing no difference compared to 1.0, doesn't seem to have any effect?
Hi,
Not sure if supposed to be posting here or if you even provide support for it, but worth asking.
Basically, using a Lightpack unit the LEDs will play the startup effect at full brightness, but when dispmanx actually runs grabbing Kodi, the lights are very dim. Previously I would use HSV valueGain of 4.5 to compensate for it. But tampering with setting on the webconfig, can't seem to make it appear any brighter.
master (GitHub-0ff4bf7/f620917-1492149514)
Anyone could provide any tips, please?
Managed to get it building, just had to tweak the crosscompile script quite a lot. Posting just the relevant bits for RPi.
#ON TARGET
#sudo apt-get install libQt4-dev libusb-1.0-0-dev rsync
#############
#ON HOST
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install git rsync cmake build-essential libqt4-dev libusb-1.0-0-dev python-dev libxrender-dev
#########
export PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin
export TARGET_IP=192.168.0.115
export TARGET_USER=pi
export RASPCROSS_DIR=$HOME/raspberrypi
export ROOTFS_DIR=$RASPCROSS_DIR/rootfs
export HYPERION_DIR=$HOME/hyperion
export TOOLCHAIN_FILE=$HYPERION_DIR/cmake/Toolchain-rpi.cmake
mkdir -p "$ROOTFS_DIR"
rsync -rlP --delete-after --copy-unsafe-links $TARGET_USER@$TARGET_IP:/{lib,usr} "$ROOTFS_DIR"
######## pi specific #########
git clone --depth 1 https://github.com/raspberrypi/firmware.git $RASPCROSS_DIR/firmware
git clone --depth 1 https://github.com/raspberrypi/tools.git $RASPCROSS_DIR/tools
ln -fs $RASPCROSS_DIR/firmware/hardfp/opt $ROOTFS_DIR/opt
# fix libvc missing deps by linking the libs over
ln -fs $ROOTFS_DIR/opt/vc/lib/libvcos.so $ROOTFS_DIR/usr/lib/arm-linux-gnueabihf/libvcos.so
ln -fs $ROOTFS_DIR/opt/vc/lib/libvchiq_arm.so $ROOTFS_DIR/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so
##### end of pi specific ######
# get hyperion sources
git clone --recursive https://github.com/hyperion-project/hyperion.git "$HYPERION_DIR"
# fix <bits/stdlib-bsearch.h> include issues by settings SYSROOT explicitly
grep -q "CMAKE_SYSROOT" $TOOLCHAIN_FILE
if [ $? -ne 0 ]; then
echo "SET(CMAKE_SYSROOT ${RASPCROSS_DIR}/rootfs)" >> $TOOLCHAIN_FILE
fi
# we do a native build first (to build the protobuf compiler for the native platform)
# then for cross-build, we specify the protoc export file to import the protobuf compiler
#
cd $HYPERION_DIR && chmod +x bin/*.sh
. bin/create_all_releases.sh
Also builds fine with Qt 5.4.2 and Python 3.4.2 given the appropriate changed to cmake files.
After lots of toolchain rebuilding and rsync resyncing, I made it further to
/home/mint/raspberrypi/rootfs/usr/include/python2.7/../stdlib.h:760:34: fatal error: bits/stdlib-bsearch.h: No such file or directory
# include <bits/stdlib-bsearch.h>
My stdlib is actually pulled into /rootfs/usr/include/arm-linux-gnueabihf, so I had to add
include_directories(${RASPCROSS_DIR}/rootfs/usr/include/arm-linux-gnueabihf)
into cmake/Toolchain-rpi.cmake
Now it's getting all the way to this. I'd pulled /lib and /usr from OSMC 2017.03-1 .. tried building with linaro 4.2 and 4.3, but always end up here. What is it not liking about the libs, the linked versions are all over the place?
Scanning dependencies of target hyperiond
[ 95%] Building CXX object src/hyperiond/CMakeFiles/hyperiond.dir/hyperiond.cpp.o
[ 95%] Linking CXX executable ../../bin/hyperiond
/home/mint/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libpython2.7.so: undefined reference to `__fdelt_chk@GLIBC_2.15'
/home/mint/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libusb-1.0.so: undefined reference to `clock_gettime@GLIBC_2.17'
/home/mint/raspberrypi/rootfs/lib/arm-linux-gnueabihf/libudev.so.1: undefined reference to `name_to_handle_at@GLIBC_2.14'
/home/mint/raspberrypi/rootfs/lib/arm-linux-gnueabihf/libudev.so.1: undefined reference to `secure_getenv@GLIBC_2.17'
collect2: error: ld returned 1 exit status
src/hyperiond/CMakeFiles/hyperiond.dir/build.make:122: recipe for target 'bin/hyperiond' failed
make[2]: *** [bin/hyperiond] Error 1
CMakeFiles/Makefile2:1352: recipe for target 'src/hyperiond/CMakeFiles/hyperiond.dir/all' failed
make[1]: *** [src/hyperiond/CMakeFiles/hyperiond.dir/all] Error 2
Makefile:149: recipe for target 'all' failedYou may need the QT4 Dev packages (libqt4-dev) iinstalled?
Indeed, except it's installed.
Qt installs as 4.8.7 from libqt4-dev.
I'm fairly sure this link well help you.
Thanks, but I wouldn't be so sure as the thread goes on to describe how to amend PATH to be able to invoke qmake, whereas I already have that working and qmake is reporting the library path to cmake by using -query. Should probably mention that qmake is just a softlink to qmake-qt4, so can call it either way as both directories are in PATH.
Tried setting QTDIR=/usr/lib/x86_64-linux-gnu/qt4 in my .bashrc to no avail either.
mint@mint-vb ~ $ which qmake
/usr/bin/qmake
mint@mint-vb ~ $ ls -la /usr/bin/qmake
lrwxrwxrwx 1 root root 9 Apr 17 10:34 /usr/bin/qmake -> qtchooser
mint@mint-vb ~ $ which qmake-qt4
/usr/bin/qmake-qt4
mint@mint-vb ~ $ ls -la /usr/bin/qmake-qt4
lrwxrwxrwx 1 root root 37 Jun 2 2016 /usr/bin/qmake-qt4 -> ../lib/x86_64-linux-gnu/qt4/bin/qmake
mint@mint-vb ~ $ qmake
Usage: /usr/lib/x86_64-linux-gnu/qt4/bin/qmake [mode] [options] [files]
...
mint@mint-vb ~ $ qtchooser -print-env
QT_SELECT="default"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"There's something else that is going on with Qt unfortunately. I had a look around for quite a while but couldn't find any indication on how to fix this.
Trying to follow the cross-compiling routines and keep running into the following problem on both Ubuntu 16.04 and Mint 18.1 KDE. Qt installs as 4.8.7 from libqt4-dev.
CPack: Create package
CPack: - package: /home/mint/hyperion/build-x86x64/hyperion-1.3.0-Linux-ambilight.sh generated.
build directory = ./build-x86x64
repository root dirrectory = .
create ./deploy/hyperion_x86x64.tar.gz
--- build release for rpi ---
-- The C compiler identification is GNU 4.8.3
-- The CXX compiler identification is GNU 4.8.3
-- Check for working C compiler: /home/mint/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc
-- Check for working C compiler: /home/mint/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/mint/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++
-- Check for working CXX compiler: /home/mint/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- ENABLE_ZEROCONF = OFF
-- ENABLE_AMLOGIC = OFF
-- ENABLE_DISPMANX = ON
-- ENABLE_FB = OFF
-- ENABLE_OSX = OFF
-- ENABLE_SPIDEV = ON
-- ENABLE_TINKERFORGE = ON
-- ENABLE_V4L2 = ON
-- ENABLE_WS2812BPWM = ON
-- ENABLE_WS281XPWM = ON
-- ENABLE_X11 = OFF
-- ENABLE_QT5 = OFF
-- ENABLE_TESTS = OFF
-- ENABLE_PROFILER = OFF
-- Current Version: master (GitHub-69f4b32/6445c35-1481143098)
CMake Warning at cmake/qt4/FindQt4.cmake:615 (message):
/usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib/x86_64-linux-gnu"
but QtCore could not be found there. Qt is NOT installed correctly for the
target build environment.
Call Stack (most recent call first):
CMakeLists.txt:154 (find_package)
CMake Error at cmake/qt4/FindQt4.cmake:619 (message):
Could NOT find QtCore. Check
/home/mint/hyperion/build-rpi/CMakeFiles/CMakeError.log for more details.
Call Stack (most recent call first):
CMakeLists.txt:154 (find_package)So the debian package is built ok, but the actual cross-compile fails. The paths are as follows and QT_INSTALL_LIBS is indeed that.
mint@mint-vb ~ $ qmake-qt4 -query
QT_INSTALL_PREFIX:/usr
QT_INSTALL_DATA:/usr/share/qt4
QT_INSTALL_DOCS:/usr/share/qt4/doc
QT_INSTALL_HEADERS:/usr/include/qt4
QT_INSTALL_LIBS:/usr/lib/x86_64-linux-gnu
QT_INSTALL_BINS:/usr/lib/x86_64-linux-gnu/qt4/bin
QT_INSTALL_PLUGINS:/usr/lib/x86_64-linux-gnu/qt4/plugins
QT_INSTALL_IMPORTS:/usr/lib/x86_64-linux-gnu/qt4/imports
QT_INSTALL_TRANSLATIONS:/usr/share/qt4/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/lib/qt4/examples
QT_INSTALL_DEMOS:/usr/lib/qt4/demos
QMAKE_MKSPECS:/usr/share/qt4/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.8.7So at the very least, FindQt4 should be finding the soft links ?
mint@mint-vb ~ $ ls -la /usr/lib/x86_64-linux-gnu | grep libQtCore
-rw-r--r-- 1 root root 655 Jun 2 2016 libQtCore.prl
lrwxrwxrwx 1 root root 18 Apr 17 20:57 libQtCore.so -> libQtCore.so.4.8.7
lrwxrwxrwx 1 root root 18 Apr 16 10:54 libQtCore.so.4 -> libQtCore.so.4.8.7
lrwxrwxrwx 1 root root 18 Apr 16 10:54 libQtCore.so.4.8 -> libQtCore.so.4.8.7
-rw-r--r-- 1 root root 3086448 Jun 2 2016 libQtCore.so.4.8.7Any help is appreciated.
Hmm, the moment after having posted this I'd stumbled upon this post on reddit.
Looks to be a production issue with the Lightpack unit itself and affecting one of the sides where the strip plugs go, the other side is fine.
Not too sure if this belongs in Hardware or Software section, but here it goes.
I have a mass production Lightpack unit, which has been configured via HyperCon. No matter what I've done in config by offsetting the first LED, I couldn't make it align the LED strip colours (I believe the individual LEDs can't be controlled, correct me if I'm wrong?) with the colours on screen. After messing around for a good while with one of them RGB youtube videos with a spinning animation, I finally made it work.. with a catch.
My Lightpack is installed in Andromeda configuration, which means the ordering of the LED if looking at the TV from the front goes counter clockwise, starting from bottom right LED strip.
The problem is, for the device to actually display colours in the right order, the LED strips have to be physically re-plugged into the Lightpack unit. Now, the left side is all OK, the right side however requires me to change the connectors as:
Strip #5 - Port #9
Strip #6 - Port #8
Strip #7 - Port #5
Strip #8 - Port #6
Strip #9 - Port #7
Anyone with this setup could chime in with their config, or perhaps just someone has any tips on how to re-arrange the right side of the unit to be in proper order? Thank you in advance.
Hi,
The only mention of this I could find was on the Github, but no suggested resolution as it appears to have fixed itself - not my case. https://github.com/hyperion-project/hyperion/issues/225
I have found a Prismatic/Lightpack fork by psieg, who has done some nifty things. And I very much would like the ability to toggle off the enclosure LED as it's unnecessary bright. However, using OSMC 2017.03.01 on a Pi3 (hyperion seems to be absolutely broken on LibreELEC 8.0.0) I ran into issues even when I'm not introducing any changes and merely compiling the FW source. Just to be sure it's not the fork itself, I've tried the official woodenshark repo and built 7.6 FW from that, which leads to the same problem. I've even got as far as downloading the Source.tar.gz from Releases on the main Lightpack repo and compiled the sources to no avail. The only firmware that allows the Hyperion daemon to communicate with the device without error is the one from lightpack.tv or from the Release section on the Lightpack repo - https://github.com/woodenshark…releases/tag/FW_version_6
Had official 7.5 before I've started tinkering with the Lightpack unit. In all other attempts to flash self-compiled FW I end up with unable to claim interface(-5): LIBUSB_ERROR_NOT_FOUND coming from hyperiond. One observation is that building under Ubuntu 16.04 LTS, I see the self-compiled firmware ends up as 17.3 Kb whereas the official unmodified 7.6 is 16.8 Kb. But it works flawlessly under OSX with Prismatic software...
Was trying to compile the NG project from Github, but cross-compiling from Ubuntu 16.04 I always run into Qt5 issues when building for the pi. So couldn't really test if the problem is there with the new codebase.
Any help is appreciated?