@
popcornmix
Thanks again for your time and pointers. I spent some time last weekend focusing on the last reported issues and got some progress.
But first, just to clear some apparent misconceptions and set some principles. I'm a Slackware user (for more than 2 decades) and Slackware is Linux. I feel the need to add that Slackware was and still remains a (if I'm allowed) purest "manifestation" of Linux. There's nothing particular you need to know about Slackware as a distro - there are very few distro specific tools (mainly for handling packages management), the rest is just "almost untouched - some code patches applied" upstream packages, classic Linux tools and a simple clear text (scripts) System V init system. My goal here is to make Kodi 19.4 run on Linux, which apparently, according to the Kodi documentation, is supported. In my queries here I'm focusing solely on standard Linux architecture, packages configurations and (system) commands.
I felt the need to write all the above because of your last sentence from your last post ... which sounded like Alchemy
But then, I'm not wondering how people perceive Linux by using an opaque & heavily customized & automated distro like Debian. I would definitely feel limited/insecure/suspicious in my understanding and knowledge.
Now, I followed your latest pointers and started with the kernel. Found an older built of mine I've used some time ago (was working fine) - kernel 5.10.92-v7 together with the modules and 58e03c94953762222f2b838390dde54d46c38381 firmware (I bundle and archive them before I make a kernel upgrade).
Enabled dtoverlay=vc4-kms-v3d and booted this kernel. It turned my monitor off during booting exactly when switching to the vc4drmfb frame buffer device FB mode. Dmesg output:
Code:
[ 18.391116] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:76:crtc-3] flip_done timed out
[ 18.391246] Console: switching to colour frame buffer device 240x67
[ 28.631090] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:76:crtc-3] flip_done timed out
[ 33.111019] cam1-reg: disabling
[ 33.111029] cam-dummy-reg: disabling
[ 38.871081] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:32:HDMI-A-1] flip_done timed out
[ 49.111080] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:69:plane-3] flip_done timed out
[ 59.351077] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:76:crtc-3] flip_done timed out
[ 59.414952] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
Cool!
Note that all of my Raspberries are headless and the ones running Kodi 17.4 don't need dtoverlay=vc4-kms-v3d - so I never cared about it / didn't enabled it.
Then I d/l the latest Raspberry Pi OS Lite image from here:
https://www.raspberrypi.com/software/operating-systems/
Mounted it and extracted the goodies - kernel - modules - firmware & udev rules collection - pretty much how it's documented here (simpler form):
https://docs.slackware.com/howtos:hardwa...aspberrypi
Booted this kernel & firmware and found no positive results when launching Kodi or modetest.
Also, I compared the kernel config from this official Raspberry kernel with mine and found no inconsistencies (I'm building the bcm2709_defconfig make target), just the extra networking and DVB stuff I'm enabling.
I switched back to my latest kernel build 5.15.76-v7 and c72ad6b26ff40c91ef776b847436094ee63fabee firmware.
Noticed that the modetest binary is heavily linked on the mesa libs and came back to my suspicion from post #6 that my mesa (version) is still the issue.
I found the Debian Bullseye mesa package source code & patches here:
https://salsa.debian.org/xorg-team/lib/m...a-20.3.5-1
https://sources.debian.org/src/mesa/20.3...n/patches/
Still no build script available - or recipe on how (what configure options) it is built for Raspberry (vc4). Shocked (and scared TBH) that no one could provide me this info yet in this thread.
Started to build it and got into a crash - had to apply an additional patch:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/4200
https://gitlab.freedesktop.org/mesa/mesa...Type.patch
My build configuration (relevant part from the build script) is this:
Code:
DRI_DRIVERS="nouveau,r100,r200"
GALLIUM_DRIVERS="virgl,r300,nouveau,freedreno,etnaviv,tegra,vc4,v3d,kmsro,lima,panfrost,zink"
export SLKCFLAGS="$SLKCFLAGS -fexceptions -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
export SLKCXXFLAGS="$SLKCFLAGS"
export SLKLDFLAGS="-Wl,-z,relro -Wl,--as-needed"
export CFLAGS="$SLKCFLAGS"
export CXXFLAGS="$SLKCXXFLAGS"
export LDFLAGS="$SLKLDFLAGS"
mkdir meson-build
cd meson-build
meson setup \
--prefix=/usr \
--libdir=/usr/lib \
--libexecdir=/usr/libexec \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--includedir=/usr/include \
--datadir=/usr/share \
--mandir=/usr/man \
--sysconfdir=/etc \
--localstatedir=/var \
--buildtype=release \
-Dplatforms=x11,wayland \
-Dgallium-opencl=icd \
-Dgbm=enabled \
-Ddri-drivers=$DRI_DRIVERS \
-Dgallium-drivers=$GALLIUM_DRIVERS \
-Dvulkan-drivers=broadcom \
-Dglvnd=true \
-Dllvm=enabled \
-Dshared-llvm=enabled \
-Dshared-glapi=enabled \
-Degl=enabled \
-Dgles1=enabled \
-Dgles2=enabled \
-Dopengl=true \
-Dglx=dri
- result:
Message: Configuration summary:
prefix: /usr
libdir: lib
includedir: include
OpenGL: yes (ES1: yes ES2: yes)
OSMesa: no
DRI platform: drm
DRI drivers: nouveau r100 r200
DRI driver dir: /usr/lib/dri
GLX: DRI-based
EGL: yes
EGL drivers: builtin:egl_dri2 builtin:egl_dri3
GBM: yes
EGL/Vulkan/VL platforms: x11 wayland surfaceless drm
Vulkan drivers: broadcom
Vulkan ICD dir: share/vulkan/icd.d\
llvm: yes
llvm-version: 13.0.0
Gallium drivers: virgl r300 nouveau freedreno etnaviv tegra vc4 v3d kmsro lima panfrost zink
Gallium st: mesa xa xvmc xvmc vdpau va clover
HUD lmsensors: yes
Shared-glapi: yes
Build targets in project: 261
Removed the distro provided mesa and substituted it with this build. modetest was finally happy - it displayed the test screen (color bars) and I could see my monitor connected - no errors in the kernel log.
Code:
$modetest -M vc4 | more
Encoders:
id crtc type possible crtcs possible clones
31 89 TMDS 0x00000008 0x00000001
44 0 Virtual 0x00000001 0x00000002
Connectors:
id encoder status name size (mm) modes encoders
32 31 connected HDMI-A-1 480x270 12 31
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
#0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
#1 1600x900 60.00 1600 1624 1704 1800 900 901 904 1000 108000 flags: phsync, pvsync; type: driver
#2 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: phsync, pvsync; type: driver
#3 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver
#4 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, pvsync; type: driver
.... etc
& screen test - color bars:
$modetest -M vc4 -s 32:1920x1080-60Hz
setting mode 1920x1080-60.00Hz on connectors 32, crtc 89
Kodi was still not happy, still putting my monitor in suspend mode and (almost) flooding the kernel log with those drm / vc4-drm soc:gpu: [drm] *ERROR* .
Also, in one firmware configuration Kodi was hanging and had to reboot the system - more on that in the following.
Next, I recompiled Kodi with the working mesa 20.3.5-1 installed - pretty useless but you never know what versioning conditional checks are there in that pretty big cmake build scripts bundle. This step had no positive effect, but at least I got over it.
Then I started to inspect the udev rules, looking for permissions I might need to apply - keeping in mind that modetest was happy launched as user kodi - so the user kodi should have had already all necessary permissions (mainly member of the video group I guess it's sufficient).
Anyways, noticed that Debian splits the permissions on drm - from video to render group in 50-udev-default.rules - looks like a cosmetic and not that much functional change.
Added the group render and made kodi a member of it, amended my 50-udev-default.rules:
Code:
commented:
#SUBSYSTEM=="drm", GROUP="video"
#SUBSYSTEM=="drm", GROUP="video", MODE="0666"
added:
#RaspiOS/LibreELEC
SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video"
SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666"
Then noticed in the Kodi debug log that there are some extra permission errors:
Code:
2022-11-28 22:18:24.596 T:2844 DEBUG <general>: CUDMABufferObject::Register - unable to open /dev/udmabuf: No such file or directory
2022-11-28 22:18:24.596 T:2844 DEBUG <general>: CDMAHeapBufferObject::Register unable to open /dev/dma_heap/reserved: No such file or directory
2022-11-28 22:18:24.596 T:2844 DEBUG <general>: CDMAHeapBufferObject::Register unable to open /dev/dma_heap/linux,cma: Permission denied
2022-11-28 22:18:24.596 T:2844 DEBUG <general>: CDMAHeapBufferObject::Register unable to open /dev/dma_heap/system: Permission denied
Addressed these too - took inspiration from here:
https://github.com/RPi-Distro/raspberryp...-com.rules
https://github.com/graysky2/kodi-standal...kodi.rules
Created an extra 99-kodi.rules with the following content:
Code:
KERNEL=="vcsm-cma", GROUP="video", MODE="0660"
KERNEL=="vchiq",GROUP="video",MODE="0660"
SUBSYSTEM=="dma_heap",KERNEL=="linux*",GROUP="video",MODE="0660"
SUBSYSTEM=="dma_heap",KERNEL=="system",GROUP="video",MODE="0660"
And got rid of the permission errors, still none of the above helped Kodi not bringing my monitor in suspend when launching.
Latest tests and findings. Before looking at LibreELEC on how they configure the firmware for Kodi 19.4 I used the following - calling it set A:
Code:
hdmi_drive=1
max_framebuffers=2
dtoverlay=vc4-kms-v3d
LibreELEC configuration - set B:
Code:
gpu_mem=76
hdmi_ignore_cec_init=1
display_auto_detect=1
dtoverlay=vc4-kms-v3d
disable_overscan=1
disable_fw_kms_setup=1
With set A Kodi picks the resolution 1280x720 , no EGL Errors in Kodi log and it's suspending the display.
- Kodi debug log:
https://pastebin.pl/view/ad4983ad
With set B Kodi picks the native resolution 1920x1080, there are EGL errors "EGL_BAD_SURFACE" and it's suspending the display.
Also , in this case, if left alone for a while (minutes) the Kodi process will get into an uninterruptible sleep state and cannot kill it.
Code:
kodi 1371 0.0 0.5 3248 2128 ? S 04:44 0:00 \_ /bin/sh /usr/local/bin/kodi
kodi 1376 2.2 18.7 254232 79620 ? Dl 04:44 0:08 \_ /usr/local/lib/kodi/kodi-gbm
- Kodi debug log:
https://pastebin.pl/view/0d78e6bc
In both cases the kernel log is getting repeated drm/vc4 flip_done timed out error messages, as if Kodi is still hammering the vc4 driver.
And in both cases the graphics (driver/firmware) is getting apparently corrupted - can't bring the monitor back from suspend mode, even tried with vcgencmd display_power 1. Only a reboot will revive the screen.
Worth mentioning that I also tried to modify set B (libreELEC) - commented gpu_mem=76 and added dtoverlay=vc4-kms-v3d,cma-256 and ,cma-512 with no positive effects. Also, in all the tests I monitored the GPU mem with that bcmstats script and found no issues - plenty of GPU mem available.
From here I learned that you can actually debug the drm exchange:
https://bugzilla.redhat.com/show_bug.cgi?id=1792515
by using:
Code:
echo 0xf > /sys/module/drm/parameters/debug
So I ran modetest -M vc4 -s 32:1920x1080-60Hz and here is the drm debug log:
https://pastebin.pl/view/7a938e9b
Then got a Kodi drm debug log (towards the end I switched the HDMI input - using a HDMI switcher - the "status updated from connected to disconnected" might be because of that action):
https://pastebin.pl/view/7cee1a83
Now I got modetest happy and Kodi suspending my monitor.
That's it, running out of ideas and stuck with Kodi 17.4 - OMX accel. & the horrible audio crackling
-------------------- that was for popcornmix ------------------
Now, Kodi devs:
With my second Kodi 19.4 compilation I stumbled upon a bug in the build scripts. In my first compilation I learned that I only can use 1 ninja make job wit 1 GB of RAM and started the second compilation accordingly.
Soon after starting the compilation - at around 4% - I got a build crash:
Code:
[ 4%] Built target fmt
/usr/bin/gmake -f build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/build.make build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/depend
gmake[2]: Entering directory '/db/kit/KODI/KODI-19/kodi-build'
cd /db/kit/KODI/KODI-19/kodi-build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /db/kit/KODI/KODI-19/xbmc /db/kit/KODI/KODI-19/xbmc/xbmc/network/httprequesthandler/python /db/kit/KODI/KODI-19/kodi-build /db/kit/KODI/KODI-19/kodi-build/build/network/httprequesthandler/python /db/kit/KODI/KODI-19/kodi-build/build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/DependInfo.cmake --color=
gmake[2]: Leaving directory '/db/kit/KODI/KODI-19/kodi-build'
/usr/bin/gmake -f build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/build.make build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/build
gmake[2]: Entering directory '/db/kit/KODI/KODI-19/kodi-build'
[ 4%] Building CXX object build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonInvoker.cpp.o
cd /db/kit/KODI/KODI-19/kodi-build/build/network/httprequesthandler/python && /usr/bin/c++ -DHAS_NEON -I/db/kit/KODI/KODI-19/xbmc -I/db/kit/KODI/KODI-19/xbmc/lib -I/db/kit/KODI/KODI-19/xbmc/xbmc -I/db/kit/KODI/KODI-19/xbmc/xbmc/platform/linux -I/db/kit/KODI/KODI-19/xbmc/xbmc/cores/VideoPlayer -I/db/kit/KODI/KODI-19/kodi-build/build -I/db/kit/KODI/KODI-19/kodi-build/build/include -I/db/kit/KODI/KODI-19/xbmc/xbmc/platform/posix -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/python3.9 -I/usr/include/samba-4.0 -I/usr/include/libxml2 -I/db/kit/KODI/KODI-19/kodi-build/build/cores/RetroPlayer/messages -I/usr/include/freetype2 -I/usr/include/fribidi -I/db/kit/KODI/KODI-19/xbmc/xbmc/contrib -I/db/kit/KODI/KODI-19/kodi-build/build/libdvd/include -I/usr/include/lzo -I/usr/include/libdrm -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -fPIC -mcpu=cortex-a7 -Wall -O3 -DNDEBUG -s -DTARGET_POSIX -DTARGET_LINUX -D_GNU_SOURCE -DHAVE_LINUX_UDMABUF=1 -DHAVE_LINUX_DMA_HEAP=1 -DHAVE_LINUX_DMA_BUF=1 -DHAVE_MKOSTEMP=1 -DHAVE_LINUX_MEMFD=1 -DHAVE_STATX=1 -D__STDC_CONSTANT_MACROS -D_FILE_OFFSET_BITS=64 -DHAS_POSIX_NETWORK -DHAS_LINUX_NETWORK -DHAS_BUILTIN_SYNC_ADD_AND_FETCH=1 -DHAS_BUILTIN_SYNC_SUB_AND_FETCH=1 -DHAS_BUILTIN_SYNC_VAL_COMPARE_AND_SWAP=1 -DHAVE_INOTIFY=1 -DHAVE_POSIX_FADVISE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_INTTYPES_H=1 -DHAS_ALSA=1 -DHAS_DBUS=1 -DHAS_ISO9660PP=1 -DHAVE_LCMS2=1 -DHAS_LIRC=1 -DHAS_WEB_SERVER=1 -DHAS_WEB_INTERFACE=1 -DHAS_PULSEAUDIO=1 -DHAS_PYTHON=1 -DHAS_FILESYSTEM_SMB=1 -DHAVE_LIBUDEV=1 -DHAVE_LIBXSLT=1 -DFFMPEG_VER_SHA=\"4.3\" -I/usr/include/fribidi -DSPDLOG_FMT_EXTERNAL -DSPDLOG_DEBUG_ON -DSPDLOG_NO_ATOMIC_LEVELS -DSPDLOG_ENABLE_PATTERN_PADDING -DHAS_EGL=1 -DHAVE_GBM=1 -DHAS_GBM_BO_MAP=1 -DHAS_GBM_MODIFIERS=1 -DHAVE_HDR_OUTPUT_METADATA=1 -DHAS_GLES=3 -DHAS_MYSQL=1 -DBIN_INSTALL_PATH=\"/usr/local/lib/kodi\" -DINSTALL_PATH=\"/usr/local/share/kodi\" -std=c++14 -MD -MT build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonInvoker.cpp.o -MF CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonInvoker.cpp.o.d -o CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonInvoker.cpp.o -c /db/kit/KODI/KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.cpp
cc1plus: warning: switch ‘-mcpu=cortex-a7’ conflicts with switch ‘-march=armv7-a+neon-vfpv4’
In file included from /db/kit/KODI/KODI-19/xbmc/xbmc/interfaces/legacy/Exception.h:12,
from /db/kit/KODI/KODI-19/xbmc/xbmc/interfaces/legacy/Addon.h:13,
from /db/kit/KODI/KODI-19/xbmc/xbmc/interfaces/python/PythonInvoker.h:12,
from /db/kit/KODI/KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.h:11,
from /db/kit/KODI/KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.cpp:9:
/db/kit/KODI/KODI-19/xbmc/xbmc/utils/log.h:25:10: fatal error: spdlog/spdlog.h: No such file or directory
25 | #include <spdlog/spdlog.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
gmake[2]: *** [build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/build.make:76: build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonInvoker.cpp.o] Error 1
gmake[2]: Leaving directory '/db/kit/KODI/KODI-19/kodi-build'
gmake[1]: *** [CMakeFiles/Makefile2:10229: build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/all] Error 2
gmake[1]: Leaving directory '/db/kit/KODI/KODI-19/kodi-build'
gmake: *** [Makefile:146: all] Error 2
Apparently with only one ninja make job spdlog is not getting built (ready) by the time it is required. I tried to switch the order I provided in the conf to cmake:
Code:
from:
-DENABLE_INTERNAL_FMT=ON \
-DENABLE_INTERNAL_SPDLOG=ON \
to:
-DENABLE_INTERNAL_SPDLOG=ON \
-DENABLE_INTERNAL_FMT=ON \
and it didn't help, the build crashed as before.
My solution/hack was to start the compilation with two ninja jobs and then at around 8% I deliberately killed a cc1plus process in order to crash the build process. Started it again with only one ninja make job after that.