Please update to the Legacy image in my test share which should now have LLVM support. Please see if that runs on the 6100 or 7300LE cards? If yes, share a Kodi debug log.
NB: Firmware will download on the first boot of the image. Please also check it's present in /storage/.config/firmware/nouveau?
EDIT: I'm also interested to know if you have working audio output on the LE image?
info <general>: GL_VENDOR = Mesa
info <general>: GL_RENDERER = llvmpipe (LLVM 19.1.7, 128 bits)
info <general>: GL_VERSION = 4.5 (Compatibility Profile) Mesa 24.3.4^ The 7300 log shows it fails to evaluate VDPAU (because https://nouveau.freedesktop.org/VideoAcceleration.html shows 7-series is not currently supported) then falls back to llvmpipe, so it's not using nouveau. LE only builds mesa with nouveau, not with swrast or llvmpipe (although that could be changed) so this explains why you see the GUI.
info <general>: GL_VENDOR = Mesa
info <general>: GL_RENDERER = NV96
info <general>: GL_VERSION = 3.3 (Compatibility Profile) Mesa 24.3.4^ The 9400 inits VDPAU and uses nouveau, but:
2025-01-30 11:48:08.789 T:1589 warning <general>: VDPAU::Open: requested picture dimensions (1920, 800) exceed hardware capabilities ( 0, 0).
2025-01-30 11:48:08.789 T:1589 info <general>: (VDPAU) Close
2025-01-30 11:48:08.791 T:1589 info <general>: VDPAU::Close - closing decoder context^ The 9400 fails with the same error that I see on the LE image (which proves it's not LE related).
MPlayer required only 35% CPU load on Slackware with 7300LE. For 9400GT the load is higher (more system) 75%
^ The interesting thing here is that llvmpipe appears to be more efficient at software decode than nouveau.
In summary: the Slackware image support and behaviour with nouveau/VDPAU is exactly the same as the LE image. Thanks for sharing the full logs, it really helped to un-confuse things 
The firmware files required for newer nVidia cards are distributed as part of the vendor driver package which ships with a license that prevents separate redistribution of component parts of the driver. The approach taken by most distros is to package a script that downloads, extracts, and installs the firmware files where they need to be on first bood; so I've reworked the package to do the same. It does require a reboot to setup the firmware overlay from /storage/.config/firmware/nouveuu, but that's not too bad.
I'll have a look at building llvmpipe into the image as a fallback.
Q200 is external PHY to support 10/100/1000 chips, but the kernel does 'magic' to ensure it works with all varieties of PHY chip; the upstream kernel avoid magic and requires us to be specific. Q201 is for internal PHY boxes and supports 10/100 max.
The image only shows the Wireless/BT module so is not helpful. I'd need to see a pic of the entire board on both sides.
NB: The boot log under CE might also be useful, the log is quite verbose.
I'm not interested in compile issues and testing with newer Kodi because there are Kodi GitHub indications of VDPAU issues with nouveau being present for a long time. Patching FFMpeg just complicates the issue (and you have invalid/incomplete patches). Kodi GBM is not compatible with X11 so failure is probably correct/expected, and we know GBM without VDPAU is a dead-end so no need to test - the info just adds noise/confusion.
Please remove any xorg.conf and kodi.conf files from /storage/.config or /run locations and create /storage/.kodi/userdata/advancedsettings.xml to enable debug logging (even if Kodi does not start) and then reboot to capture a clean and more useful failure log. Please provide full debug logs (not snippets, which are not informative) showing 1080p/H264 media playback for:
a) Slackware-current on 7300LE
b) Slackware-current on 9400GT
c) Latest LE 'Legacy' image on 7300LE
d) Latest LE 'Legacy' image on 9400GT
Apologies for the rework. And I appreciate you are trying to be creative, but it's just confusing the task. Four full debug logs on standard Slackware and the latest LE image will be helpful.
Please check one of the older cards (6100 or 7300) on:
Slackware development image, working?
Current LE image, working?
Please pastebin a Kodi debug log from the Slackware install (9400GT card) to confirm the VDPAU error/issue is the same.
Two version back Kodi was also shown with a Geforce 6100 (it was usable).
For clarity, are we talking about my image (two versions back) or Slackware?
The screenshot is from my image, or Slackware?
video=HDMI-A-1:dThis kernel boot param ^ will disable the DRM connector at boot time. I've no idea if it can be done post-boot through /sys, but that might be worth exploring.
NB: Reading https://nouveau.freedesktop.org/VideoAcceleration.html it's clear lots of older cards have no VDPAU support. Can you confirm this with the GeForce 6100 card under Slackware? (press 'o' on the keyboard during Kodi playback to check).
https://github.com/xbmc/xbmc/pull/26238 might be involved. Team Kodi decided to not backport the fix to Omega because of the last-minute timing of the latest Omega release (it had already been built) and because if a little inconvenience inspires more people to workaround the issue by creating secure shares instead of insecure ones, that's a good thing.
I remembered that I have an Xstreamer Ultra2 board in my collection. It's an Atom/ION board with a GT520 (Fermi) card which is a little more recent than the 9400GT you have. It boots both images (GBM and Legacy) to the Kodi home screen without needing an xorg.conf or kodi.conf file creating. It does require some nVidia firmware blobs extracted from the vendor driver to silence a couple of system log messages and provide firmware for decoding. I created https://github.com/LibreELEC/nouveau-firmware earlier to address that, and the commits in my nouveau branch are revised to use it and remove VAAPI support.
The GBM image detects libva support and tries to use it during playback, and fails. Rebuilding without VAAPI support allows software decode playback to work. There is no VDPAU support because mesa reports ERROR: Feature gallium-vdpau cannot be enabled: VDPAU state tracker requires X11 support. during compile. I'll have a chat about VDPAU with mesa devs, but GBM without hardware decode makes no sense, so for now, further effort on GBM (Nouveau) stops.
The X11 image is also now built without VAAPI support and VDPAU is detected and attempted. All 1080p and H264 media I've tried currently fails with VDPAU::Open: requested picture dimensions (1920, 1088) exceed hardware capabilities ( 0, 0) but some 720p/SD resolution MPEG4 media is being hardware decoded properly. I'll have to query the error with Kodi folks.
LE requires two partitions to run from and /flash and /storage must be separate. As you can now drop the 'Nouveau' image that should make things easier for testing. Please remove any config that's been added to boot params or /storage or make a clean install so you are using a default image. Also focus only on the 9400GT card for now. I appreciate the old cards work on Slackware, but your Slackware install is using significantly older software versions and bisecting to find the breaking changes will be a major effort, so that's deferred to a future date.
NB: I've pushed an image that matches GitHub commits a few seconds ago. Please check all is okay with the Legacy image after the cleanup or fresh start.
LE10/11 use 'arm' userspace and LE12 uses 'aarch64' userspace. The LE11 settings add-on is not showing an update because there is no 'arm' update. This also stops users from blindly updating and experiencing crashes due to arch-incompatible binary add-ons.
To do an in-place update you will need to first uninstall all binary add-ons (keeping their config). Then manually download (wget) the LE12.0.2 .tar update file to /storage/.update and reboot to update. Once the update completes you can reinstall binary addons (to use aarch64 versions).
Install the multimedia tools add-on and user alsamixer from the SSH console to reduce output volume. Pops and Clicks are normally the result of signals being overdriven.
Hmm.. I'll see if I can update the LE12 branch with the same patches. LE13 will be along soon enough and is quite stable though.
Please use an LE13 nightly from https://test.libreelec.tv or the test image here https://chewitt.libreelec.tv/testing/
SMB services are on by default to facilitate log collection in the event the users device doesn't successfully boot to the Kodi home screen. This is considered low risk because on first boot there are no sources configured and thus no cleartext passwords being stored and exposed anywhere. After the user adds SMB/NFS sources and add-ons that store credentials (and Kodi or the add-on stores them in cleartext) the risk profile of the installation has changed.
I think the most sensible option is to make Samba shares configurable through the LE settings add-on. Samba can then be started by default and with the logfile share defined and default enabled. Then if users want to enable other pre-defined (but default disabled) share locations they need to visit Samba settings to toggle the state. This will ensure the Kodi userdata folder is not default exposed, thus mitigating the risk of exposure from plaintext stored credentials. The logic of that is a good balance between security and usability and I'll be happy to accept your changes to add that capability to the add-on.
NB: If you want to also address Kodi storing credentials in plaintext, send code changes to upstream Kodi. The solution to this needs to be simple and work for all currently supported Kodi OS platforms and other distros, not just for Linux on LE.
If you need better wireless on legacy kernels it's often better to acquire a wireless bridge device. You can get something on Amazon that powers itself from USB and presents an Ethernet interface to the box which requires no WiFi drivers, and being an external device the reception/range is typically better.
Perhaps try with --install-test-programs=true instead?
NB: It's modetest not testmode
The log doesn't show any Ethernet related errors so next step is to open up the box and take pics of the board inside so we can see what Ethernet chip is being used. It probably needs something based on Q200 (as Q201 is for 10/100 designs) but with a different Ethernet PHY chip described in device-tree.