Have you swapped the WiFi dongle from a USB 2.0 port to a USB 3.0 port? - If yes, move it back.
If no, see if this makes a difference (unlikely):
echo "options mt76_usb disable_usb_sg=1" > /storage/.config/modprobe.d/mt76x2u.conf
rebootAny difference?
echo 'module nouveau +p' > /sys/kernel/debug/dynamic_debug/control
dmesg -n 8
systemctl restart kodiOn the GBM image can you do that ^ .. it should put nouveau into debug mode and that might generate some log info on interaction with mesa and upper layers of the graphics stack.
NB: There's no need to unpack .tar files, just put them in /storage/.update and reboot. Nothing in /storage will be touched by an update unless a Kodi version bump happens (and then only minor changes to /storage/.kodi).
The GBM log doesn't contain as much debug output from nouveau, but that could be due to kodi.conf not being present? Otherwise it looks no different, which was largely expected.
Have you tried the Geforce 9400GT card recently? - I rather suspect Kodi logic for outscan format is to blame, but I'm also wondering if age of hardware (and thus features exposed to nouveau) are related. It would be interesting to see if the 'modetest' output from the Geforce 9400GT card is any different from 6100.
Settings > Services > Control > Application Control > Allow remote control from applications on other systems > enable
Have you done that ^ ?
2025-01-24 08:35:39.301 T:986 info <general>: Opening stream: 0 source: 256
2025-01-24 08:35:39.301 T:986 info <general>: [WHITELIST] Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, 3D: false
2025-01-24 08:35:39.301 T:986 debug <general>: [WHITELIST] Searching for an exact resolution with an exact refresh rate
2025-01-24 08:35:39.301 T:986 debug <general>: [WHITELIST] Matched an exact resolution with an exact refresh rate 3840x2160 @ 23.976025 Hz (32)
2025-01-24 08:35:39.301 T:986 info <general>: Display resolution ADJUST : 3840x2160 @ 23.976025 Hz (32) (weight: 0.000)This ^ shows Kodi correctly detecting and selecting the [email protected] mode.
2025-01-24 08:35:39.659 T:899 debug <general>: CDRMUtils::SetMode - found crtc mode: 3840x2160 @ 24 HzThis ^ means some code is rounding the value to 24Hz. I'm not sure if it's Kodi or the underlying kernel DRM layer, but I see the same on an LG TV and I have no playback issues, so this can be ignored.
I can see from the log that you didn't whitelist any 1080p modes. That's probably a bad idea, but not related to this issue. Have a read of the wiki acticle here for recommendations: https://wiki.libreelec.tv/configuration/4k-hdr
If seeing bad values in the log wasn't the issue? - how do you determine the projector is at 24Hz?
It also has an unsupported RK3032 chip.
If you are connecting the project through an AVR, remove it from the HDMI chain and connect direct to confirm things working as expected (then blame the AVR). If not doing that, put Kodi into debug mode, reboot, demonstrate the issue with 23.976 media, then run "pastekodi" and share the URL so we can see the DRM modes available and what Kodi selects.
In GBM images we can find the plane details, e.g. this is from an Amlogic S905 board:
2025-01-20 19:16:58.075 T:734 info <general>: CDRMUtils::FindConnector - using connector: HDMI-A-1
2025-01-20 19:16:58.075 T:734 info <general>: CDRMUtils::FindEncoder - using encoder: 34
2025-01-20 19:16:58.075 T:734 debug <general>: CDRMUtils::FindCrtc - original crtc mode: 3840x2160 @ 60 Hz
2025-01-20 19:16:58.075 T:734 info <general>: CDRMUtils::FindPlanes - using crtc: 43
2025-01-20 19:16:58.075 T:734 debug <general>: CDRMUtils::FindPlanes - using video plane 40
2025-01-20 19:16:58.075 T:734 debug <general>: CDRMUtils::FindPlanes - using gui plane 37
2025-01-20 19:16:58.076 T:734 debug <general>: CDRMAtomic::InitDrm - initialized atomic DRMThe GUI is using plane 37 so we can check the plane capabilities using modetest output:
Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
37 43 49 0,0 0,0 0 0x000000ff
formats: AR24 AB24 XR24 XB24 RG24 RG16
props:
8 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
30 IN_FORMATS:
flags: immutable blob
blobs:
value:
01000000000000000600000018000000
01000000300000004152323441423234
58523234584232345247323452473136
3f000000000000000000000000000000
0000000000000000
in_formats blob decoded:
AR24: LINEAR(0x0)
AB24: LINEAR(0x0)
XR24: LINEAR(0x0)
XB24: LINEAR(0x0)
RG24: LINEAR(0x0)
RG16: LINEAR(0x0)
39 zpos:
flags: immutable range
values: 1 1
value: 1Here you can see that the plane supports LINEAR formats.
From the 'Nouveau' GBM kodi.log:
2025-01-23 16:04:45.957 T:917 info <general>: CDRMUtils::FindConnector - using connector: DVI-D-1
2025-01-23 16:04:45.957 T:917 info <general>: CDRMUtils::FindEncoder - using encoder: 45
2025-01-23 16:04:45.957 T:917 debug <general>: CDRMUtils::FindCrtc - original crtc mode: 1920x1080 @ 60 Hz
2025-01-23 16:04:45.957 T:917 info <general>: CDRMUtils::FindPlanes - using crtc: 39
2025-01-23 16:04:45.957 T:917 debug <general>: CDRMUtils::FindPlanes - using gui plane 38
2025-01-23 16:04:45.957 T:917 debug <general>: CDRMLegacy::InitDrm - initialized legacy DRMPlane 38 has the following capabilities:
Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
38 39 61 0,0 0,0 0 0x00000001
formats: XR24 RG16 XR15
props:
8 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1Folks on IRC said "Seems like the GPU doesn't like the pushbuf due to an invalid render target format. I would guess the framebuffer isn't properly set at the time of the flush and the userspace driver just flushes the current (invalid) state, which has the GPU grumpy." and also "you can't use a linear frontbuffer with depth" .. not clear to me if that refers to zpos or alpha-channel.
I've opened https://github.com/xbmc/xbmc/issues/26345 to discuss with Kodi devs.
In the background I also created this:
--- a/xbmc/windowing/gbm/drm/DRMUtils.cpp
+++ b/xbmc/windowing/gbm/drm/DRMUtils.cpp
@@ -191,7 +191,7 @@ bool CDRMUtils::FindPlanes()
auto videoPlane = std::find_if(m_planes.begin(), m_planes.end(), [&i](auto& plane) {
if (plane->GetPossibleCrtcs() & (1 << i))
{
- return plane->SupportsFormat(DRM_FORMAT_NV12);
+ return (plane->SupportsFormat(DRM_FORMAT_NV12) || plane->SupportsFormat(DRM_FORMAT_XRGB8888));
}
return false;
});
@@ -206,7 +206,8 @@ bool CDRMUtils::FindPlanes()
if (plane->GetPossibleCrtcs() & (1 << i))
{
return (plane->GetPlaneId() != videoPlaneId &&
- (videoPlaneId == 0 || plane->SupportsFormat(DRM_FORMAT_ARGB8888)) &&
+ (videoPlaneId == 0 || plane->SupportsFormat(DRM_FORMAT_ARGB8888) ||
+ plane->SupportsFormat(DRM_FORMAT_XRGB8888)) &&
(plane->SupportsFormat(DRM_FORMAT_XRGB2101010) ||
plane->SupportsFormat(DRM_FORMAT_XRGB8888)));
}This is partly inspired by a patch previously used with Odroid XU4 boards that don't support YUV formats and needed some extra help to use XRGB8888 output, but I'm honestly guessing in the wind. I'm not sure there's a real issue with selecting planes (as we select a plane) but I'm interested to see if anything changes - so please update to the latest images pushed to my test share and do the usual log sharing again.
Johpin can you run "modetest | paste" on the 'Nouveau' (GBM) image and share the URL please.
Xorg now looks generally happy (some xorg.conf tweaking can clean some minor things up) but it now clearly shows an identical fault to the GBM image, so the IRC comments about "using linear scanout with depth" apply and we need to tweak something on the Kodi side to resolve this.
RPi5:~ # ls -l /flash/overlays/*pwm*
-rwxr-xr-x 1 root root 1825 Jan 17 14:26 /flash/overlays/i2c-pwm-pca9685a.dtbo
-rwxr-xr-x 1 root root 1059 Jan 17 14:26 /flash/overlays/pwm-2chan.dtbo
-rwxr-xr-x 1 root root 3558 Jan 17 14:26 /flash/overlays/pwm-gpio-fan.dtbo
-rwxr-xr-x 1 root root 1006 Jan 17 14:26 /flash/overlays/pwm-gpio.dtbo
-rwxr-xr-x 1 root root 1035 Jan 17 14:26 /flash/overlays/pwm-ir-tx.dtbo
-rwxr-xr-x 1 root root 1010 Jan 17 14:26 /flash/overlays/pwm-pio.dtbo
-rwxr-xr-x 1 root root 948 Jan 17 14:26 /flash/overlays/pwm.dtbo
-rwxr-xr-x 1 root root 1493 Jan 17 14:26 /flash/overlays/pwm1.dtboFrom a current LE13 nightly with RPi Linux 6.12.y kernel ^ - I don't have an LE12 device but we bumped the kernel for the 12.0.2 release (shipped last night) so if RPi devs backported the change to their Linux 6.6.y kernel it should be included there too.
Some things to experiment with:
a) Remove the SD card and see if the RPi firmware screen shows?
b) Use a different mini-HDMI to HDMI cable; do not use adapter + cables
c) Use a different HDMI port on the TV
d) Use video=HDMI-A-1:1920x1080M@60 not video=HDMI-A-1:1920x1080@60D
e) Update the firmware on the board using RPi imager
f) Use LE 12.0.2 which was released last night, or an LE 13 nightly
From experience I'd point fingers at cables or ports being the issue.
You boot from Ubuntu and install grub to the boot device, then create a grub-format bootloader config file. Start with seeing if the device will reliably boot Ubuntu on the hardware?
info <general>: CDRMUtils::FindConnector - using connector: HDMI-A-2^ this shows you are using the HDMI connector furthest from the power connector. Move HDMI to the port nearest the power port and CEC will work again. Support for CEC on both connectors has been intentionally removed due to problems seen when multiple HDMI connections are active. It is now only supported on HDMI-A-1.
mglae See the IRC chat that starts here: https://oftc.irclog.whitequark.org/dri-devel/2025-01-23#33941062
This change causes the dri2 error under X11: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29969 - so I've added support for legacy-x11=dri2 in mesa package.mk
Johpin I've pushed an updated pair of images to https://chewitt.libreelec.tv/testing/ and I have a hunch "Nouveau-Legacy" with DRI2 support should now work? - If it does, please test whether this /storage/.config/xorg.conf also works? (probably not)
Section "Device"
Identifier "Nouveau"
Driver "nouveau"
Option "DRI" "3"
EndSectionThe main mission is still to get GBM working so nouveau can be added to the normal Generic image. I'll need to chat with Kodi devs about that though, I'm not really understanding the DRM format comments in the IRC chat.
I don't see any difference in the log, which is positive as we can eliminate Kodi changes from suspicion and focus on interaction between libgallium and the kernel driver. I think it's time to push discussion to the mesa mailing list.
NB: Rolling back the mesa version back that far will require more than a simple version/sha256 change in package.mk as the build options have changed format and things have been added/removed over time (look at the git history for mesa package.mk). I did look at reverting, but in the end we need to fix the current version so better to pursue that for now.
