nVidia Nouveau Driver

Quote from chewitt

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

chewitt Excellent. Either setting Option "DRI" "3" in xorg-i915.conf or building with -Dlegacy-x11=dri2 let kodi start in Intel HW again.

BTW: the issue on GBM seen with vmware driver on Virtualbox is fixed by mesa 24.3.4 update.

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 DRM

The 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: 1

Here 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 DRM

Plane 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: 1

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

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.

echo 'module nouveau +p' > /sys/kernel/debug/dynamic_debug/control
dmesg -n 8
systemctl restart kodi

On 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).

I can see from the Kodi crashlog that my patch changes the issue and we're not generating the nouveau error. I've pushed updated images which revert that to restore the original crash. NB: I'm only interested in the "pastekodi" output as this contains both Kodi and system log in one paste.

EDIT: Current images in my test share have the previous patch reverted and something added that forces EGL_DEPTH_SIZE to zero (EGL_STENCIL_SIZE is already zero). As always, no guarantees my guesswork is correct. Please run tests again.

Quote from Johpin

.update/ gives sometimes compatibility problems.

LE update logic currently see Nouveau and Nouveau-legacy images as not compatible.

Extend your update procedure to suppress the check:

touch /storage/.update/.nocompat

Couple of things to do:

a) Please run "modetest | paste" on the 9400GT box (either image is fine, the output will be the same) and share the URL so we can see what DRM properties are advertised.

b) Save the current Legacy image file(s) in a folder called "depth-size-patch" so we know they contain that change. Now update to the latest Legacy image in my test share (which does not contain the patch). If the image works fine, the patch is irrelevant. If the image does not work, we know it's important. Let me know which is true?

There are probably Xorg properties that can be configured to reduce CPU load. This is all code archaeology for me though, and I'll need to do some reading. The goal is still to have the GBM image work though.

formats: C8 RG16 XR15 AR15 XR24 AR24 XB30 AB30 XB24 AB24 XB4H AB4H

The 9400GT is advertising AR24 which the default format Kodi tries to use.

AR24:  NVIDIA_BLOCK_LINEAR_2D,HEIGHT=0,KIND=122,GEN=1,SECTOR=1,COMPRESSION=0(0x30000000057a010)

And AR24 supports NVIDIA_BLOCK_LINEAR_2D scanout.

EDIT: I'm interested to know what kernel, mesa, and X11 versions are used on the Slackware install that works with the 6100 card?

Also, if the 6100 slackware install has modetest? or drm_info -j ? .. please run it and pastebin the output.

Perhaps try with --install-test-programs=true instead?

NB: It's modetest not testmode