[wsnipex]

But I couldn't find a repository where I could download the actual RaspiOS 32 bit arm HF mesa deb file.
Honestly, these Debian & Ubuntu derivatives are all opaque to me (not that much "open source" apparently - too much automation - almost M$ Windows like), no versioning on packages, no idea how to trace back the packages and inspect how these were built, no repos to browse file manually, etc...
 

Sorry, but this is completely wrong. All debian/ubuntu packages are versioned and finding the source code of a package is always just 1 (apt source) command away (if you enabled deb-src repos)

[abga]

More effort into testing this build and understanding why it doesn't work.

I went again through the strace outputs and realized that the error I presented in some posts before, where kodi is trying to find the vulkan libs, was actually the main issue - kodi would exit after that.
Again the strace errors in chronological order:
 

Code:

openat(AT_FDCWD, "/lib/libvulkan.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libvulkan.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
write(2, "MESA-LOADER: failed to open vc4:"..., 148) = 148
write(2, "failed to load driver: vc4\n", 27) = 27
geteuid32()                             = 1007
getuid32()                              = 1007
openat(AT_FDCWD, "/usr/lib/dri/tls/kms_swrast_dri.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dri/kms_swrast_dri.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 28
....
munmap(0x5d53a000, 90364)               = 0
write(2, "MESA-LOADER: failed to open kms_"..., 155) = 155
write(2, "failed to load driver: kms_swras"..., 34) = 34
geteuid32()                             = 1007
getuid32()                              = 1007
openat(AT_FDCWD, "/usr/lib/dri/tls/swrast_dri.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/dri/swrast_dri.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 28
......
ioctl(0, DRM_IOCTL_AUTH_MAGIC, 0x7edb107c) = -1 EINVAL (Invalid argument)
close(27)                               = 0
close(0)                                = 0
write(9, "2022-11-02 21:20:19.129 T:5894  "..., 109) = 109
write(2, "ERROR: Unable to create GUI. Exi"..., 37) = 37

Learned that the system mesa was built with vulkan support (generic) and I didn't have the vulkan libs installed - my fault - I considered I don't need them.
I installed the distro provided vulkan-sdk-1.2.176 and voila - kodi is starting ... and still blacking out the screen (suspend mode).
For some reason I don't really understand it enters 1280x720@50 mode - monitor enters suspend mode (BTW, it's smart enough to warn me through the OSD if the resolution is not supported, that doesn't happen).
Here the debug log:
https://pastebin.pl/view/61e0c2c8

I added framebuffer_width=1920 and framebuffer_height=1080 in my /boot/config.txt, restarted the system and noticed that kodi will pick this new resolution, although still blacking out the display - suspending.
I also learned that kodi is responsive, I was able to exit it with the help of my remote control.
However, in this try I got some EGL errors - Error: EGL_BAD_SURFACE
See the whole debug log:
https://pastebin.pl/view/2f4f4acd

In both cases there was plenty of RAM (GPU RAM incl.) available and there was no exaggerated load on all the CPU cores - plenty of resources available. It looked like Kodi was happy, started and idle.

My next approach is to rebuild mesa. I checked the distro mesa build script and found out that it was built with both llvm and swrast support and no particular broadcom vulkan support (some generic instead).
Apparently swrast is considered obsolete and not used anymore, so I removed it from the build script.
https://www.phoronix.com/news/Mesa-Kills-SWRAST
https://docs.mesa3d.org/systems.html
Relevant entries in my mesa build script (still building it for general support - not only for vc4/broadcom):
 

Code:

DRI_DRIVERS="nouveau,r100,r200"
GALLIUM_DRIVERS="virgl,r300,nouveau,freedreno,etnaviv,tegra,vc4,v3d,kmsro,lima,panfrost,zink"
...
  -Dplatforms=x11,wayland \
  -Dgallium-opencl=icd \
  -Dgallium-nine=true \
  -Dosmesa=true \
  -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 \

Started the compilation and learned that I still need to satisfy some OpenMAX IL dependencies - presumably required by -Dvulkan-drivers=broadcom:
 

Code:

Run-time dependency libomxil-bellagio found: NO (tried pkgconfig and cmake)
Run-time dependency libtizonia found: NO (tried pkgconfig and cmake)
Run-time dependency libtizplatform found: NO (tried pkgconfig and cmake)
Run-time dependency tizilheaders found: NO (tried pkgconfig and cmake)

Will need to build&install these separately (don't understand why I need them both) and restart the mesa compilation:
https://omxil.sourceforge.net/downloads.html
https://docs.tizonia.org/development/ope...zonia.html

@wsnipex I presume you're not affected by functional illiteracy (funktionaler Analphabetismus in German - able to read but not understanding what is read) , especially observing that you quoted (cherry picked - out of the context) my statement about not being able to find a repo I could browse and learn about the packages versions and build scripts in Debian & its derivative RaspiOS. I'm not running Debian and don't intend to (no interest whatsoever) and the packages available on the Debian system (LibreELEC derivative) and also listed in the official Kodi docs have - again -   "no versioning on packages", that's no version in the filename not in the official Kodi doc.
See for yourself - most of the packages have no versioning (ask someone to help you with the reading & understanding if you're unable to):
https://github.com/xbmc/xbmc/blob/master...d-packages
Besides, since you apparently are running some Debian and able to use the available tools and some "Sherlock Holmes" investigation to understand what packages are installed, you could be really helpful if you could provide a build script for mesa - how it was built on your system, that's if it is a Raspberry Pi and able to run Kodi 19.x on it.

[abga]

@popcornmix 
I managed to get mesa recompiled (will never do it again I'm sure! - libomxil-bellagio is a dead project mess that requires heavy patching and tizonia a nightmare (also apparently dying project) I had to strip of plugins&clients&player&etc.) and the results are the same, kodi is putting the monitor in suspend and I still get those errors in the kernel log.
Went to test with the utilities you proposed :
https://gitlab.freedesktop.org/mesa/drm/...s/modetest
https://gitlab.freedesktop.org/mesa/kmscube

kmscube I failed to build - some code bugs that GCC 11 doesn't tolerate.

modetest I built successfully and here are the findings (had/have no idea what I was doing - documentation is poor).
Got some inspiration from here:
https://elinux.org/R-Car/Tests:KMS-modetest

I ran:
modetest -M vc4 > output.txt
and here is the output.txt (plenty of info):
https://pastebin.pl/view/9f91f758

Noticed that my monitor is in a "disconnected" state - weird.

Then I goofed with (32 is apparently my connector):
modetest -M vc4 -s 32:800x600-60Hz
And got:
failed to find mode "800x600-60.00Hz" for connector 32
failed to create dumb buffer: Invalid argument
^C
It also put my monitor in suspend an there were no kernel messages related (no DRM errors).

Now, I start to speculate that there are maybe some driver options I need to provide to the vc4/drm/whatever (some udev rules) I'm not aware of. I say this because I compared the kernel log and loaded drivers with LE 10.0.3 and I've found consistency.
Furthermore, now, with a brand new mesa, a fresh (Raspberry upstream) kernel and also fresh firmware I still cannot "communicate" apparently with the monitor- the results from modetest.

Please advise what to try next. Thanks in advance.

[popcornmix]

It sounds like your issue isn't with kodi, but with slackware (which I'm not familiar with).
Might be best to ask questions on a slackware forum.

Personally, I'd test an PRiOS (or libreelec) image, just to confirm you equipment is working.
If you still have an issue there, then there may be an issue with hdmi display or cable.
If it works, then there's something not right with slackware install.

[abga]

@popcornmix 
Thank you for sharing your opinion. Indeed, it looks like Kodi is properly built and my issue is with the Raspberry platform. That's why I asked you for help, considering that you're the most competent here.
I can't remember asking Slackware ARM specific questions, those I cared about on my own. It's Slackware philosophy to empower the user, allow him/her to properly understand and control "the Linux".
Last question was about driver options - Raspberry drivers specific - and/or some specific udev/eudev rules I might need to implement.
Besides, ARM is just a port of Slackware, it provides generic ARM platform support and not focusing too much on the Raspberry platform, which has plenty of issues when it comes to "open-source-ness" - well, things are improving.
Nevertheless, it was me providing instructions in the Slackware ARM forum on how to build Kodi for Raspberry - Kodi 17.x and Kodi 18.x - I quit my documentation efforts with Kodi 18.x after learning that the official Kodi source code is not working and I need to use your clocksworks* stuff. Also, because I learned that Kodi 18.x (clockworks) was useless for playing PVR on analogue audio (A/V desync and waw-waw effects).
On your other points: it's the same equipment I was testing LE on - it's mentioned in the first post and the whole purpose of this thread is my effort in trying to replicate LE.
...
I'll have a look in the LE image and seek for some relevant driver options / eudev rules.
I have now this toy I can play with - modetest - and it helps in my investigation on why I cant use the monitor through DRM. As said before, I'm a noob in this GBM DRM & crap and documentation is not really available/helpful.
Found this (older) stuff that explains a little how it works:
https://www.x.org/wiki/Events/XDC2013/XD...slides.pdf

[abga]

@popcornmix 
Apparently you'll find proper documentation in the least expected place - commercial entity:
https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview
- here it's suggestively represented that the DRM&KMS framework & drivers is in the kernel space (obviously) - that's Raspberry folks competency - whereas some posts before you asked me (as a user) to put my DRM&KMS in order
https://wiki.st.com/stm32mpu/nsfr_img_au...erview.png

Some more useful documentation:
https://wiki.stmicroelectronics.cn/stm32...ldid=73965

P.S. It looks like there is a driver/kernel issue (kernel space) not "connecting" my monitor. I mentioned that some posts before when noticing those DRM "flip-flop whatever" kernel errors - said that it looks like the kernel doesn't give a beep about the libs (user space) trying to communicate with the driver.
 

Code:

kodi@pi-kodi:~$ ls -al /sys/class/drm
total 0
drwxr-xr-x  2 root root    0 Jan  1  1970 ./
drwxr-xr-x 59 root root    0 Jan  1  1970 ../
lrwxrwxrwx  1 root root    0 Nov 10 22:34 card0 -> ../../devices/platform/soc/soc:gpu/drm/card0/
lrwxrwxrwx  1 root root    0 Jan  1  1970 card0-HDMI-A-1 -> ../../devices/platform/soc/soc:gpu/drm/card0/card0-HDMI-A-1/
lrwxrwxrwx  1 root root    0 Jan  1  1970 card0-Writeback-1 -> ../../devices/platform/soc/soc:gpu/drm/card0/card0-Writeback-1/
lrwxrwxrwx  1 root root    0 Nov 10 22:34 renderD128 -> ../../devices/platform/soc/soc:gpu/drm/renderD128/
-r--r--r--  1 root root 4096 Jan  1  1970 version
kodi@pi-kodi:~$ cat /sys/class/drm/card0-HDMI-A-1/status
disconnected
kodi@pi-kodi:~$ uname -r
5.15.76-v7

Inspiration:
https://wiki.st.com/stm32mpu/wiki/DRM_KM...lass.2Fdrm

Again. the relevant /boot/config,txt directives are the ones copied from the working LE 10.0.3
 

Code:

# LE stuff - Kodi 19
hdmi_ignore_cec_init=1
display_auto_detect=1
dtoverlay=vc4-kms-v3d
disable_overscan=1
disable_fw_kms_setup=1

And (again) the kernel source I took from https://github.com/raspberrypi/linux - 5.15.76-v7 - Nov. 2  git snapshot, patched a DVB frontend and built it

Did I get a broken kernel (gpu driver)?
The vc4 looks heavily patched and modified:
https://github.com/raspberrypi/linux/com...pu/drm/vc4

Can you be so kind and point me to a stable kernel git snapshot (source) that is patched for the latest WiFi vulnerabilities and tested (released) to work with Kodi/DRM ? I might need to rebuild it if i can't find a way to make the vc4 driver working with my actual build.
Thanks again for all your help.

[popcornmix]

Can you be so kind and point me to a stable kernel git snapshot (source) that is patched for the latest WiFi vulnerabilities and tested (released) to work with Kodi/DRM ? I might need to rebuild it if i can't find a way to make the vc4 driver working with my actual build.
Thanks again for all your help.

kodi works fine on all the recent kernel trees on raspberrypi/linux.
rpi-5.10.y is currently used by LE Matrix. I believe they are currently on 5.10.110. Kodi works fine there. That tree is only updated for critical issues, so I wouldn't recommend it.
rpi-5.15.y is considered the stable tree. RPiOS is currently using 5.15.76 (which was the had of tree a week ago). Kodi works fine there.
rpi-6.0.y is currently used by LE master. I believe they are currently on 6.0.6. Kodi works fine there.
rpi-6.1.y is the bleeding edge. Currently on 6.1.0-rc4. Kodi works fine there (using RPiOS with updated kernel).

You can confirm all this by installing RPiOS and then building a kernel of your choice following documentation here.
But I'm pretty sure your issue doesn't relate to the source you are using for the linux kernel (assuming you are using one of our rpi-x.x.y branches).

But, how you build kernel, how you transfer kernel, permissions for users, udev rules, system libs, system services may all prevent drm/kodi from working.

[abga]

@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.

[abga]

Had one last idea I didn't try - load 2022-09-22-raspios-bullseye-armhf-lite on a Pi and grab all the mesa deb files, convert them to Slackware packages and install them on Slackware - check if I could make Kodi happy and verify if it's my mesa that causes the issues.
Slackware has a handy convertor that would have been useful for this - could script the conversion and installation for the whole bunch of Debian mesa deb files:
https://slackbuilds.org/repository/15.0/...ch=deb2tgz

I downloaded 2022-09-22-raspios-bullseye-armhf-lite.img.xz and extracted it. Grabbed the https://downloads.raspberrypi.org/imager..._1.7.3.exe Spyware imager (spyware because telemetry is by default activated and the user is not warned about it), found out that it's broken - not configuring properly wpa_supplicand if the SSID is hidden, had to unplug the card and create manually a wpa_supplicant.conf in the FAT partition.

Finally I got into my headless raspios-bullseye Pi and started to goof around with apt:
 

Code:

su -
apt list --installed | grep mesa
# none - obviously, it's the lite edition
apt update
apt install mesa
# well, no such package
apt install mesa*
# wow - half a page of packages and another half of additional packages - asking me something [n/Y] - I typed n
mkdir /kit && cd /kit
apt-get download mesa*
# got a bunch and I also got some permission error on one of the packages - some container ... crap like that- ignored it

The list of files I got with the download directive is pretty short - compared to the first output from apt install mesa*
 

Code:

-rw-r--r--  1 root root  1289012 May  6  2022 mesa-common-dev_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root  3573068 May  6  2022 mesa-opencl-icd_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root 41564556 May  6  2022 mesa-opencl-icd-dbgsym_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root    30400 Nov 24  2018 mesa-utils_8.4.0-1+b1_armhf.deb
-rw-r--r--  1 root root    25800 Nov 24  2018 mesa-utils-extra_8.4.0-1+b1_armhf.deb
-rw-r--r--  1 root root  2172596 May  6  2022 mesa-va-drivers_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root 18253536 May  6  2022 mesa-va-drivers-dbgsym_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root  2277408 May  6  2022 mesa-vdpau-drivers_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root 18672820 May  6  2022 mesa-vdpau-drivers-dbgsym_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root  2381512 May  6  2022 mesa-vulkan-drivers_20.3.5-1+rpt4+rpi1_armhf.deb
-rw-r--r--  1 root root 20802460 May  6  2022 mesa-vulkan-drivers-dbgsym_20.3.5-1+rpt4+rpi1_armhf.deb

Tried again - out of the /kit directory:
 

Code:

# apt install mesa*
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package mesa-deb

Well, it was there before, wasn't it? ... tried: apt clean --dry-run & apt-get autoremove & apt-get clean & apt update    without any results. I just touched it and it got broken

I'd be thankful if some of you Debian gurus could provide me with a build script - or recipe on how (what configure options) mesa is built for Raspberry (vc4) - Debian Bullseye. If that information is even available and not some confidential stuff that the package maintainer keeps under his/her pillow.
Meanwhile I formatted the SDCard and promise I'll never try it again.

[abga]

Got some more time over the weekend to play with this "Alchemy" and try to make Kodi work - to not bring my display in suspend mode.
Test system is Raspberry Pi Zero 2 W Rev 1.0 and monitor Dell 22 Monitor - P2214H

In short:
- checked that the kernel headers are in place and consistent with the running kernel - learned from here that libdrm relies on them:
https://salsa.debian.org/xorg-team/lib/libdrm
"Syncing with the Linux kernel headers
The library should be regularly updated to match the recent changes in the include/uapi/drm/."

- Slackware 15 ARM is ahead (compared to Debian Bullseye) on libdrm too, so I uninstalled the system packagelibdrm-2.4.109 and built&installed libdrm-2.4.104 - from here:
https://salsa.debian.org/xorg-team/lib/l...-2.4.104-1

- modetets (part of libdrm) is happy - displaying the color bars (communicating properly with the monitor)

- noticed that mesa relies on libdrm, removed my previous mesa 20.3.5-1 built and re-buit mesa 20.3.5-1 with this libdrm-2.4.104 in place

- then I inspected the LibreELEC patches I applied to Kodi 19.4 and considered I can live without them. Rebuilt Kodi clean - original source code from git

Building Kodi took around 20 hours with only one make job and I got it finally built late this evening. Was looking for a way to provide more info on what's happening and synced strace & drm debug (kernel log) & Kodi debug log.
Here are the files:

Kodi Debug Log - first start - clean - .kodi folder clean (only advancedsettings & lircmap in place)
https://pastebin.pl/view/59253ccf

Kodi dmesg drm debug log - result of: "echo 0xf > /sys/module/drm/parameters/debug && dmesg -wT > kodi-dmesg.log"
https://pastebin.pl/view/cf95687a

Kodi strace (timestamped) log (11MB big !!!) - result of: "strace -f -t -o kodi-strace.log /usr/local/lib/kodi/kodi-gbm"
https://www.mediafire.com/file/0zd5aes8k...e.log/file

The firmware setup is:
 

Code:

- /boot/config.txt
gpu_mem=76
hdmi_ignore_cec_init=1
display_auto_detect=1
dtoverlay=vc4-kms-v3d
disable_overscan=1
disable_fw_kms_setup=1

- output of ./vcgencmd get_config int
aphy_params_current=819
arm_freq=1000
arm_freq_min=600
audio_pwm_mode=514
camera_auto_detect=-1
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x331df0
disable_commandline_tags=2
disable_fw_kms_setup=1
disable_l2cache=1
disable_overscan=1
display_auto_detect=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
dvfs=3
enable_tvout=1
enable_uart=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
ignore_lcd=1
init_uart_clock=0x2dc6c00
mask_gpu_interrupt0=3072
mask_gpu_interrupt1=26370
max_framebuffers=-1
over_voltage_avs=6250
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
total_mem=512
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_ignore_cec_init:0=1
hdmi_pixel_freq_limit:0=0x9a7ec80

The results are the same, launching Kodi blacks out the display - which enters suspend mode.
This is how far I went to try to replicate the Raspberry Debian environment where all the Kodi platform support dev was done ... apparently and presumably by @popcornmix 
In my previous attempts I described that Kodi is choosing the 1280x720-50Hz resolution when the firmware is set as in RaspiOS - found out that this resolution is not supported by my monitor.
Furthermore, after a clean boot and the first Kodi start & stop & bringing the monitor in suspend mode, the second time I launch Kodi it doesn't pick the 1920x1080-60Hz native resolution anymore, it picks the unsupported 1280x720-50Hz instead - wondering from where does it read that.

 "modetest -M vc4 -s 32:1920x1080-60Hz" doesn't give any error but the display remains black / in suspend mode.
If I power cycle the monitor after Kodi brings it suspend mode, the OSD is informing me that there is no video signal available - meaning the Raspberry GPU system is broken.

From this chain of links I learned that there are DRM kernel issues and I'm not sure if all of them were fixed (patches applied in the Raspberry kernel):
https://bugzilla.redhat.com/show_bug.cgi?id=2008557
https://www.spinics.net/lists/dri-devel/msg323342.html
"The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to
atomic helpers") introduced a number of issues in corner cases, most of them
showing themselves in the form of either a vblank timeout or use-after-free
error."
https://lore.kernel.org/all/CAPpJ_ecMSA8...ail.com/T/

In the kernel log I presented above I can observe an apparent vblank timeout:
 

Code:

[Tue Dec  6 00:08:41 2022] vc4-drm soc:gpu: [drm:drm_vblank_enable [drm]] enabling vblank on crtc 3, ret: 0
[Tue Dec  6 00:08:51 2022] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:89:crtc-3] flip_done timed out

Besides, the cmake path issues with libEGL.so & libGLESv2.so were actually my fault. There were some symlink leftovers in /usr/lib from the time I tried to tame the Kodi 18.x build scripts not to link with the system mesa, but with /opt/vc/ instead. Removed them and the Kodi 19.4 cmake scripts are happy now.

[abga]

@popcornmix 

I dug more last weekend into this issue and came to some conclusions.
To summarize:
- noticed that the kernel (vc4) driver patches I mentioned in the ending of my previous post were already merged into the Raspberry kernel tree somewhere in Dec 2021 (navigated the git changes). But the vc4 code had many more pages of fixes and patches - quite a mess having/making it work
- you mentioned in one of your previous post that the way compiling & copying the kernel could be also a cause for the issues I'm experiencing. Well, I documented the build & copying process years ago, before it was properly documented anywhere else (incl. Raspberry official docs):
https://www.linuxquestions.org/questions...ost5959658
In this respect, I guess I'm both knowledgeable & experienced. What I didn't add in that post was gathering the header files and updating them in /usr/include. Main reasons for that were the fact that Slackware provides a kernel headers package which is also synchronized with the tool-chain, and the kernel differences should be minor - 1-2 iterations on the minor kernel version between upstream Slackware kernel and what users might compile on their own.
In my case I built 5.15.76 and Slackware was providing 5.15.73 headers - however, I checked them and found that (at least the drm headers) were identical between 5.15.73 & 5.15.76. Still to make sure I'm doing a clean job, I removed the Slackware provided 5.15.73 headers, gathered the 5.15.76 ones and put them in place ... according to:
https://www.kernel.org/doc/html/latest/k...stall.html
Then I rebuilt libdrm & mesa & Kodi without any improvements, sadly.
- related to the drm&mesa libs and test tools, apparently all the efforts I took to rebuild & come to the same version as Debian Bullseye were in vain, literally a waste of time. First, Slackware builds libdrm and doesn't add the tools in the package (libdrm upstream install makefile is incomplete), so I didn't have a modetest binary available. You need to navigate the build folders and pick all the binaries by hand - which I did. So, modetest is happy with any mesa version & kernel headers.
- then, I said I failed to build kmscube due to some compiler errors - turns out it was my fault, instead of grabbing the master code (which usually is unstable / in dev.) I took some older tree. Now I got the master & built it  (against Slackware provided mesa & drm libs !!!) & ran it - saw the nice color cube rotating:
Source:
https://gitlab.freedesktop.org/mesa/kmscube/
Execution:
 

Code:

./kmscube -A
Using display 0x5ec028 with EGL version 1.4
===================================
EGL information:
  version: "1.4"
  vendor: "Mesa Project"
  client extensions: "EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_ad                                                                     dresses EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_xcb EGL_MESA                                                                     _platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless"
  display extensions: "EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_K                                                                     HR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_K                                                                     HR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap                                                                      EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image                                                                      EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_WL_bind_wayland_display "
===================================
OpenGL ES 2.x information:
  version: "OpenGL ES 2.0 Mesa 21.3.5"
  shading language version: "OpenGL ES GLSL ES 1.0.16"
  vendor: "Broadcom"
  renderer: "VC4 V3D 2.1"
  extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint                                                                      GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth                                                                     _texture GL_AMD_performance_monitor GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra                                                                      GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_pack_reverse_row_order GL_EXT_occlusion_quer                                                                     y_boolean GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer                                                                     _range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_separate_shader_objec                                                                     ts GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL                                                                     _OES_texture_border_clamp GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order GL_MESA_bgra "
===================================
Rendered 118 frames in 2.007261 sec (58.786583 fps)
Rendered 239 frames in 4.023923 sec (59.394775 fps)
Rendered 359 frames in 6.023926 sec (59.595686 fps)
Rendered 480 frames in 8.040589 sec (59.697120 fps)
Rendered 601 frames in 10.057252 sec (59.757873 fps)
Rendered 721 frames in 12.057291 sec (59.797843 fps)
Rendered 842 frames in 14.073961 sec (59.826797 fps)
Rendered 963 frames in 16.090605 sec (59.848587 fps)
Rendered 1083 frames in 18.090608 sec (59.865318 fps)
Rendered 1204 frames in 20.107269 sec (59.878844 fps)
Rendered 1325 frames in 22.123937 sec (59.889882 fps)
Rendered 1446 frames in 24.140603 sec (59.899083 fps)
Rendered 1566 frames in 26.140633 sec (59.906737 fps)
Rendered 1686 frames in 28.140635 sec (59.913360 fps)
Rendered 1806 frames in 30.140638 sec (59.919102 fps)
^C

- finally, googling around I stumbled upon this kmsxx project - https://github.com/tomba/kmsxx Built it (again against the Slackware provided libs) and goofed around with some of the tools:
 

Code:

kmsprint
Connector 0 (32) HDMI-A-1 (connected)
  Encoder 0 (31) TMDS
    Crtc 3 (89) [email protected] 148.500 1920/88/44/148/+ 1080/4/5/36/+ 60 (60.00) P|D
      Plane 3 (79) fb-id: 291 (crtcs: 3) 0,0 1920x1080 -> 0,0 1920x1080 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU12 YV12 NV12 NV21 NV16 NV61 RGB8                                                                      BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12)
        FB 291 1920x1080 RG16

############# then:

kmstest -c HDMI-A-1 -r 1920x1080@60 -f XR24 -p 400x400 -f XB24
Connector 0/@32: HDMI-A-1
  Crtc 3/@89: [email protected] 148.500 1920/88/44/148/+ 1080/4/5/36/+ 60 (60.00) P|D
  Plane 3/@79: 0,0-1920x1080
    Fb 293 1920x1080-XR24
  Plane 4/@90: 760,340-400x400
    Fb 294 400x400-XB24

The color bars and squares were displayed properly.
- having all these tools properly working, that's initializing the display, displaying the test graphics, not corrupting the display and not getting any kernel error messages, I believe that I satisfy your requirement "You would probably be better off confirming that you have a working drm/kms install."
Actually, Slackware as it is delivered by default satisfies it - as said, I just wasted my time recompiling the libs & Kodi.

Now, on Kodi, I rebuilt it already 6 times, in different system environments/statuses - default Slackware libs, my mesa & drm libs, RaspriOS officially built kernel & headers, your Kodi source mirror ( https://github.com/popcornmix/xbmc/tree/gbm_matrix ) and latest attempt - the official Kodi source unpatched against the Slackware default libs and my kernel compilation. In all the cases the output is the same, Kodi inits the display - blacks it out (suspends it) and according to the debug log continues to load,  displaying the GUI as if the display was properly initialized & working.
Which leads me to believe that maybe Kodi does a poor job (code) with the display initialization sequence - ergo, insufficient exception handling (in English - poor quality coding).
I tried to find the source file where the display init is defined in the Kodi source tree and failed so far - it's a rather big project. I'm not that good in coding myself, but able to somewhat understand already written C code.

I would be happy if you or some other devs can come with some ideas in form of additional source code (patches?) that I can apply to the Kodi source tree & build it again,  in order to try to properly init the display or gather more info on what is actually happening during the process.

Some extra details about the "platform" - that's' Slackware:
-  Slackware is systemd free
-  the default daemons/processes that are running (note that the lats two - lircd&irexec are my work):
 

Code:

/sbin/udevd --daemon
/usr/sbin/syslogd -s
/usr/bin/dbus-daemon --system
elogind-daemon
/usr/sbin/inetd
/usr/sbin/atd -b 15 -l 1
/usr/sbin/gpm -m /dev/mouse -t imps2
sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
/sbin/agetty (a few instances)
/usr/sbin/crond -l notice
/usr/local/sbin/lircd
/usr/local/bin/irexec

- I also build FFMpeg separately from the Kodi tree - just because I'm too lazy to modify the internal Kodi makefile and I have more control (visibility) over the options (I need ffplay & I don't need a lot of other crap). But FFMpeg shouldn't interfere with the display init sequence, I guess.

[popcornmix]

Are you still getting this?

Code:

[Tue Dec  6 00:08:41 2022] vc4-drm soc:gpu: [drm:drm_vblank_enable [drm]] enabling vblank on crtc 3, ret: 0
[Tue Dec  6 00:08:51 2022] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:89:crtc-3] flip_done timed out

That is a fatal message (it guarantees a blank screen) that needs fixing (likely from kernel side).
It's likely unrelated to kodi, and would probably occur if modetest (or other app) requsted the same hdmi mode.

A dmesg, and (debug enabled) kodi.log from your system (in the configuration where kmscube is working) would be useful.

[abga]

@popcornmix 
Thanks for your care on this issue.

I know you're busy& all over the place in the Raspberry internals, therefore I understand that you haven't followed in detail my rather boring and maybe too explicit monologue here.
Therefore I'd like to recap some of my affirmations/details:
- kmscube, kmsprint & modetest work in all the configurations I enumerated in this thread. I only had an issue with modetest some posts above, it didn't work because I was building libdrm-2.4.104, didn't install it and was launching modetest from within the libdrm-2.4.104 build directory while the Slackware provided libdrm-2.4.109 (which doesn't contain the modetest binary) was still installed and available - modetest apparently linked with the latter. That confused me & maybe you. My confusion due to this modetest thing drove me to rebuild mesa ... and waste a lot of time trying to fix my system .. which wasn't faulty to start with
- then, I paid attention not to fiddle with any graphic utility (incl. modetest) before launching Kodi in my tests. Actually I always rebooted the system and the first thing after the reboot was launching Kodi and providing the logs here in the forum.

Now, on your question about the "drm_vblank_enable & flip_done timed out" sequence - it doesn't seem to pop up again, but I'll provide you with full debug logs in the following.

The test system is the same as described in post #25, as for SW - Slackware default mesa 21.3.5 & libdrm-2.4.109 & Raspberry upstream kernel 5.15.33-v7 & firmware e5a963efa66a1974127860b42e913d2374139ff5
In the kernel debug logs you might notice that I'm disconnecting the monitor after finishing the test - don't get confused by that (ignore). I only have one monitor on this desk that is connected to both my computer & the Raspberry, using a HDMI Switcher - manually pressing the button.

I started the system clean an ran the tests with all the utilities - enabled the DRM debugging in the kernel. All the tests were successful! Here the logs:
- modetest:
https://pastebin.pl/view/fa4f21d5
- kmstest:
https://pastebin.pl/view/6f318fbb
- kmscube:
https://pastebin.pl/view/492cf7d5

Then I rebooted the system and launched Kodi 19.4 - a clean build against Slackware default libs (detailed them above) and with an empty /home/kodi/.kodi/ folder (only put in /userdata the files advancedsettings.xml for enabling debugging and Lircmap.xml - remote). Also enabled the DRM debug log. This test failed, Kodi, as usual, blacked out my display - put it in suspend mode.
Here are (again) the requested logs:
- Kodi debug log:
https://pastebin.pl/view/6b8d36e4
- dmesg - DRM debugging enabled:
https://pastebin.pl/view/db37a127
Struggled to kill the kodi-gbm process - many kill -9 $KODI_PID - got it finally.

Then (without rebooting) I ran modetest with 1920x1080-60Hz - I tried to "translate" & test & investigate what you hinted with modetest interfering with Kodi -  "would probably occur if modetest (or other app) requsted the same hdmi mode"
The screen (as expected) remained black (suspend mode) - but the kernel debug log might help you:
https://pastebin.pl/view/e532cd47

Then I said - well, let's try a different resolution and voila! modetest was happy with 1024x768-60Hz, revived my screen, displayed the color bars and restored the Linux console (framebuffer).
Here is the log (failed to capture the beginning of the kernel DRM debugging - it's flooding like crazy):
https://pastebin.pl/view/f9a68d58

OK, so now that I have again a functioning display, let's start Kodi again & Evrika! It works! Finally! (FFS .. I might add)
- Kodi debug log:
https://pastebin.pl/view/960ff507
- Kernel DRM debug:
https://pastebin.pl/view/8b2b0213

It's up to you to decide what to fix. My understanding now is that Kodi is messing up the display in the first attempt to init it . Then, modetest switches the resolution and "revives" it. After this, the second time I launch Kodi, everything seems to work.
I might create a small script as a workaround, launching Kodi first, then kill it (that's pretty hard as it enters the uninterruptible sleep state), launching modetest with a different resolution and finally launching Kodi again. Pretty lame, isn't it?

[abga]

@popcornmix 

Just wanted to wrap this up and provide the latest (and final) updates and findings, until I have a fresh memory on the details.

Went on and adopted the dirty workaround mentioned in the previous post, initializing the display at boot time (using rc.local - the last script executed in the Slackware BSD style init system ). Quite a challenge to make modetest run non-interactively, had to use screen as helper.
Added the following in /etc/rc.d/rc.local
 

Code:

# display init workaround
sudo -H -u kodi /usr/local/bin/kodi >> /dev/null 2>&1 &
/usr/bin/sleep 8
/bin/kill -9 $(pidof /usr/local/lib/kodi/kodi-gbm)
/usr/bin/sleep 3
/usr/bin/screen -dm /home/kodi/modetest -M vc4 -s 32:1024x768-60Hz
/usr/bin/sleep 3
/bin/kill -9 $(pidof /home/kodi/modetest)

Then I found out that by using vc4-kms-v3d I had no way to bring the monitor/TV in suspend mode after exiting Kodi, vcgencmd display_power is not compatible anymore. Quite a handicap and no solution form Raspberry, who apparently shifted the responsibility to the "kernel tools", as if the Raspberry had a BIOS ...
Well, setterm doesn't work, fbset & vbetool require a BIOS implementation (x86) and xset (dpms force off) has no way of executing non-interactively in an xinit session.
The only really dumb/overkill solution to use the X tools for suspending the screen was to run a WM free xinit session and setup the screen timeout (1 minute) in the X conf - inspiration from here:
https://wiki.archlinux.org/title/Display...th_setterm
Way to do (at least on Slackware):
- remove/hide .xinitrc from the user home - also remove the symlink to the WM in /etc/X11/xinit/
- add the following sections in /etc/X11/xorg.conf.d/xorg.conf
 

Code:

Section "ServerFlags"
    Option "StandbyTime" "0"
    Option "SuspendTime" "0"
    Option "OffTime" "1"
    Option "BlankTime" "0"
EndSection

Section "Monitor"
  Identifier  "Monitor0"
  VendorName  "Monitor Vendor"
  ModelName  "Monitor Model"
  Option "DPMS" "true"
EndSection

- run a simple instance of xinit and after 1 minute the screen will turn off
- killing xinit brings the monitor back on

But then I discovered a more elegant and simple solution, using /sys/class/graphics/fb0/blank, which under vc4-kms-v3d doesn't only blank the display (as it does in normal mode) but also suspends it.
The monitor/TV needs to be connected in order for /sys/class/graphics/fb0/blank to be available and user permissions are required - either implemented by a udev rule or a simple boot time init "hack" line like:
 

Code:

chmod a+rw /sys/class/graphics/fb0/blank

Then:
 

Code:

# suspending the display
echo 1 > /sys/class/graphics/fb0/blank
# bringing the display back from suspend mode
echo 0 > /sys/class/graphics/fb0/blank

Now, after all this effort, I found out that Kodi 19.x is still useless for playing PVR (tvheadend) content, both my compilation and LibreELEC 10.x. My fault, I should have tested LE 10.x thoroughly before starting my own build...
It appears that there is some improvement from Kodi 18.x under which by not using OpenMAX but MMAL, I got the audio speeding-up/slowing-down constantly (waw-waw effect). In Kodi 19.x, in addition to the audio waw-waw I also get the video playback speeding up constantly, noticing in the Kodi log a lot of re-syncing  entries. Funny, it looks like SD channels are suffering form the same audio/video sync issues, although their bitrate is way lower.
Furthermore, there looks to be some memory management issues too (buffering algorithm), Kodi 19.x crashing constantly with "out of memory" on PiZero2W (512MB RAM).
The OOM crashes appear to happen only if I play a HD channel for a longer period (20-30 minutes) and then switching the channel to another HD channel. Switching HD channels fast (playing only a few minutes ~ 5 minutes) doesn't trigger an OOM. SD channels switching and playback don't appear to trigger an OOM.
On the PiZero2W the system (kernel + linux) uses around 60MB of RAM and by running Kodi 19.x and playing HD channels I get around 360MB RAM usage without an apparent increase after a long playback (20-30 minutes). Switching HD channels after those 20-30mintes looks to trigger some excessive memory usage and the remaining 140MB of RAM become insufficient - thus the resulting OOM.
On the performance side (on both Pi2B and PiZero2W boards), I tried to max out the frequencies without any positive result:
 

Code:

arm_freq=900
arm_freq_min=900
gpu_freq=400
gpu_freq_min=400
core_freq_min=400
core_freq=400
disable_auto_turbo=0
force_turbo=1

Note that I was only able to set the core_freq at 500 on the older PiZero v1 boards, on Pi2B and PiZero2W setting it at 500 renders the system unstable (SDCard controller issues and Kodi GUI crashing). I also set arm_freq at 900 on the PiZero2W in order to keep the temp under 65C - noticing that the extra 100Mhz to 1000 don't really help at all.

My verdict after all this effort, is that Pi2B & Pi3B are not able to reproduce properly PVR content (SD channels at 4-6 Mbps & HD channels at 8-12 Mbps) under Kodi 19.x, even without the GPU generated Audio - I bought and used an external HDMI Audio extractor with it's own DAC.
Not sure how the Pi4B handles this, but I doubt it does it properly and I'm also not sure if there are any "fundamental" changes in the playback engine from Kodi 20.x (which was recently released).

As mentioned, I bought an external HDMI Audio extractor and using it now on the PiZero2W with Kodi 17.x & OpenMAX acceleration. Your rocket guy colleague (the one signing his posts on the Raspi Forum with "Rockets are loud") that excelled in overwhelming the GPU with the newest "audio redux" algorithm has now green light for further "improvements for the worse".

____________________

For other users that followed this thread and maybe interested in compiling their own Kodi 19.x for Raspberry Pi, the way I got the Kodi compilation is already available. FFMpeg I've built separately (before Kodi - obviously - it's a dependency) and it requires patching and special configuration directives in order to enable the DRM Prime HW accelerated decoder.
At least for Pi2B/Pi3B which are using the v4l2 DRM prime decoder I followed this:
- LibreELEC - package.mk - the initial inspiration
https://github.com/LibreELEC/LibreELEC.t...package.mk
- got ffmpeg:
https://github.com/xbmc/FFmpeg/archive/4...9.1.tar.gz
- patches to apply:
https://raw.githubusercontent.com/LibreE...elec.patch
https://github.com/LibreELEC/LibreELEC.t...-rpi.patch
- respect the order:
patch -p1 < patches/ffmpeg-001-rpi.patch
patch -p1 < patches/ffmpeg-001-libreelec.patch
- Observation. This patch apparently breaks the code - I didn't apply it:
https://raw.githubusercontent.com/LibreE...rime.patch

- then, the compilation conf directives I used (just for inspiration!). Note that I'm also building the ffmpeg player (because I need it) & doing some extra tuning. Again, I post it just for inspiration.

Code:

./configure \
--extra-cflags="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" \
--extra-cxxflags="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" \
--target-os="linux" \
--enable-hwaccels \
--disable-mmal \
--enable-v4l2_m2m \
--enable-libdrm \
--disable-debug \
--enable-stripping \
--enable-neon \
--enable-libdav1d \
--enable-ffplay \
--enable-ffmpeg \
--disable-vaapi \
--disable-vdpau \
--disable-static \
--enable-shared \
--enable-nonfree \
--disable-version3 \
--enable-logging \
--disable-doc \
--enable-pic \
--enable-optimizations \
--disable-extra-warnings \
--enable-avdevice \
--enable-avcodec \
--enable-avformat \
--enable-swscale \
--enable-postproc \
--enable-avfilter \
--disable-devices \
--enable-pthreads \
--enable-network \
--enable-gnutls \
--disable-openssl \
--disable-gray \
--enable-swscale-alpha \
--disable-small \
--enable-dct \
--enable-fft \
--enable-mdct \
--enable-rdft \
--disable-crystalhd \
--enable-runtime-cpudetect \
--disable-hardcoded-tables \
--disable-encoders \
--enable-encoder=ac3 \
--enable-encoder=aac \
--enable-encoder=wmav2 \
--enable-encoder=mjpeg \
--enable-encoder=png \
--disable-muxers \
--enable-muxer=spdif \
--enable-muxer=adts \
--enable-muxer=asf \
--enable-muxer=ipod \
--enable-muxer=mpegts \
--enable-demuxers \
--enable-parsers \
--enable-bsfs \
--enable-protocol=http \
--disable-indevs \
--disable-outdevs \
--enable-filters \
--disable-avisynth \
--enable-bzlib \
--disable-lzma \
--disable-alsa \
--disable-frei0r \
--disable-libopencore-amrnb \
--disable-libopencore-amrwb \
--disable-libopencv \
--disable-libdc1394 \
--disable-libfreetype \
--disable-libgsm \
--disable-libopenjpeg \
--disable-librtmp \
--disable-libtheora \
--disable-libvo-amrwbenc \
--disable-libvorbis \
--disable-libvpx \
--disable-libx264 \
--disable-libxavs \
--disable-libxvid \
--enable-zlib \
--enable-asm \
--disable-altivec \
--disable-symver \
--enable-libass \
--enable-gpl \
--disable-altivec \
--disable-symver \
--disable-rpi \
--enable-sand

[popcornmix]

Furthermore, there looks to be some memory management issues too (buffering algorithm), Kodi 19.x crashing constantly with "out of memory" on PiZero2W (512MB RAM).
The OOM crashes appear to happen only if I play a HD channel for a longer period (20-30 minutes) and then switching the channel to another HD channel.

See here

LibreELEC 10.x also dropped support for Raspberry Pi Zero and other 512MB RAM devices as 1GB is now considered as the minimum RAM needed for a good Kodi experience.