[graysky]

@popcornmix - Stating kodi-gbm from r56195-3b752afa68 leads to a blank screen on my RPi4.  I see kodi-gbm running so I am thinking it has to do with the video output.  If I downgrade to r56142.332c9642cb it works just fine.

Debug log: https://gist.github.com/graysky2/97abba1...1eb4d6a06a
/etc/boot.txt

Code:

dtoverlay=vc4-kms-v3d,cma-384
dtoverlay=rpivid-v4l2
dtparam=audio=on
disable_overscan=1

1) Do you need me to bisect or do you have any ideas based on the debug log?
2) Is posting to this forum the most efficient way to communicate with you about the gbm branch moving forward?

[asavah]

EDIT forget my comment, I was mislead by Kodi compiled 2020-10-12 by GCC 10.2.0 for Linux ARM 32-bit version 5.8.0 (329728)

Yep, 5.8/5.9 (and maybe some earlier kernels) seem to require dtoverlay=vc4-kms-v3d-pi4

This works for me

Code:

[s]dtoverlay=vc4-kms-v3d-pi4,cma-384[/s]

I'm not aware what is responsible for this difference in behavior wrt to 5.4.x tree.

[popcornmix]

Yep, 5.8/5.9 (and maybe some earlier kernels) seem to require dtoverlay=vc4-kms-v3d-pi4

No that is not true. dtoverlay=vc4-kms-v3d is fine with 5.4, 5.8, 5.9.
The only requirement is the firmware is new enough to support dt aliases (last month or two is fine) and you have copied over dtbo files.

[Nachteule]

You are doing something wrong. Current popcornmix/gbm as well as my branch brings pictures on the screen

There was no need do change anything in /boot/config.txt

[popcornmix]

@popcornmix - Stating kodi-gbm from r56195-3b752afa68 leads to a blank screen on my RPi4.  I see kodi-gbm running so I am thinking it has to do with the video output.  If I downgrade to r56142.332c9642cb it works just fine.

1) Do you need me to bisect or do you have any ideas based on the debug log?
2) Is posting to this forum the most efficient way to communicate with you about the gbm branch moving forward?

 1. Yes, but I'd guess it is https://github.com/xbmc/xbmc/pull/18489. Would be good to confirm reverting that fixes it.
2. Here is fine, but I'd suggest perhaps a main long running thread about issues with gbm builds.

[graysky]

 1. Yes, but I'd guess it is https://github.com/xbmc/xbmc/pull/18489. Would be good to confirm reverting that fixes it.
2. Here is fine, but I'd suggest perhaps a main long running thread about issues with gbm builds.

My google-fu is failing me. If I downloaded your latest commit and PR-18489 as a patch, how can I revert it?

Code:

% wget https://github.com/popcornmix/xbmc/archive/3b752afa68052dbf7ca43d265286a24f950e25bb.tar.gz
% wget https://patch-diff.githubusercontent.com/raw/xbmc/xbmc/pull/18489.patch

I tried:

Code:

% git apply -R ../18489.patch
error: patch failed: xbmc/windowing/gbm/GBMUtils.cpp:10
error: xbmc/windowing/gbm/GBMUtils.cpp: patch does not apply
error: patch failed: xbmc/windowing/gbm/GBMUtils.h:8
error: xbmc/windowing/gbm/GBMUtils.h: patch does not apply
error: patch failed: xbmc/windowing/gbm/GBMUtils.cpp:21
error: xbmc/windowing/gbm/GBMUtils.cpp: patch does not apply
error: patch failed: xbmc/windowing/gbm/GBMUtils.h:23
error: xbmc/windowing/gbm/GBMUtils.h: patch does not apply

[popcornmix]

Aren't you building from a git tree? Just git revert <hash> for each hash you are suspicious of.
You can ignore my gbm tree for this - the probablem is going to be in xbmc/master.

[asavah]

No that is not true. dtoverlay=vc4-kms-v3d is fine with 5.4, 5.8, 5.9.

That is not true here.
I will open a proper bug report on rpi kernel github once I've made sure it's not something with my kernel config or local stuff.
I have a theory that this might be because I build vc4 driver as builtin (as opposed to module)
5.9.y with vc4-kms-v3d-pi4

Code:

dmesg | grep -i vc4
[    1.224181] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    1.225441] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
[    1.225648] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    1.226062] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
[    1.226146] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
[    1.226234] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
[    1.226328] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
[    1.226403] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
[    1.226472] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
[    1.226524] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
[    1.226595] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
[    1.247629] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    1.315485] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[    1.398267]   #0: vc4-hdmi-0
[    1.398288]   #1: vc4-hdmi-1

5.9.y with  vc4-kms-v3d (no -pi4)

Code:

dmesg | grep -i vc4

Code:

vcgencmd version
Oct  8 2020 16:53:53 
Copyright (c) 2012 Broadcom
version 98d4a47662dd4fe24f8637651a89a83665d99675 (clean) (release) (start_x)

@graysky sorry for the thread hijack.

[asavah]

@popcornmix sorry for the noise.
/boot/overlays/overlay_map.dtb was missing due to an oversight in my script.

Bad:

Code:

[    6.765179] vcos: dtb_file 'bcm2711-rpi-4-b.dtb'
[    6.773169] vcos: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
[    6.773185] vcos: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xba7f
[    6.784393] vcos: brfs: File read: 47743 bytes
[    6.853914] vcos: brfs: File read: /mfs/sd/config.txt
[    6.854042] vcos: brfs: File read: 475 bytes
[    6.863688] vcos: brfs: File read: /mfs/sd/overlays/vc4-kms-v3d.dtbo
[    6.868122] vcos: dterror: can't find symbol 'i2c2'
[    6.868133] vcos: Failed to resolve overlay 'vc4-kms-v3d'

Properly installing overlay_map.dtb solves the issue.
Good:

Code:

[    6.770693] vcos: dtb_file 'bcm2711-rpi-4-b.dtb'
[    6.777986] vcos: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
[    6.778001] vcos: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xba7f
[    6.789098] vcos: brfs: File read: 47743 bytes
[    6.803374] vcos: brfs: File read: /mfs/sd/overlays/overlay_map.dtb
[    6.853679] vcos: brfs: File read: 1463 bytes
[    6.857752] vcos: brfs: File read: /mfs/sd/config.txt
[    6.858152] vcos: brfs: File read: 475 bytes
[    6.869219] vcos: brfs: File read: /mfs/sd/overlays/vc4-kms-v3d-pi4.dtbo
[    6.922132] vcos: Loaded overlay 'vc4-kms-v3d'
[    6.922144] vcos: dtparam: cma-384=true

[graysky]

Aren't you building from a git tree? Just git revert <hash> for each hash you are suspicious of.
You can ignore my gbm tree for this - the probablem is going to be in xbmc/master.

For simplicity, I am directing the build system to the commit tarball rather than git checkout.

To test your idea that PR18489 is to blame, I cloned the repo, checkout gbm, reverted the 4 commits comprising that PR you called out to give a single patch, for reference here.  It applied cleanly to r56195-3b752afa68.  BUT, reverting it (as I described) did not fix the problem.  Still no video output.

[graysky]

I also tried booting into the 5.9.y kernel (c97b595676) but that too did not give playback.  If I switch from dtoverlay=vc4-kms-v3d,cma-384 to dtoverlay=vc4-fkms-v3d,cma-384, kodi works as expected albeit with the tearing fkms is known for.

[HiassofT]

FYI: I ran into similar issues on RPi4 in LibreELEC (kernel 5.9, vc4-kms, kodi master).

There seem to be 2 different issues in play ATM: the "integer scaling" PR 18194 causes a black screen, this was later disabled in the "DRM rework" PR 18491 but that seems to have introduced another issue, instead of kodi I still see the LE splash screen - with fkms I get kodi on screen. I've informed lrusak about that, he'll have a look at it.

So better use kodi versions up to https://github.com/xbmc/xbmc/commit/c73d...7a17c9ffe5 for now

so long,

Hias

[graysky]

Thanks for the info, @HiassofT

[popcornmix]

I've reverted some commits on gbm and it starts working again (you need to revert a few to avoid conflicts)

[graysky]

I've reverted some commits on gbm and it starts working again (you need to revert a few to avoid conflicts)

This is excellent.  58e4c8bd67 works as expected, thank you!