Posts by chewitt

RPi3B+ using LE 9.2.8 will be the "best and final" recommendation. LE 10.x and newer switch to an all-new GBM/V4L2 video pipeline where 3D support simply hasn't ever quite made the priority list for development, and while the initial RPi4 hardware is supported by the initial LE 9.2.8 release, newer iterations of RPi4 hardware need firmware that only exists in newer/current LE releases. It's possible to self-build a doctored 9.2.8 image with newer firmware etc. there's no HOWTO guide for that (although not too hard if you have a tinkering mindset). Considering the limited amount of new 3D content these days and depending on what other media you need to handle; i'd keep a spare 3B+ lying around for 3D duties when you need to play something, while using an RPi4 (or something else that meets needs) as the main player board.

Quote from stevie101

I have tried your image (LibreELEC-AMLMX.arm-10.88.0-box.img)

You've done more than me then

Martin seems to be MIA at the moment so the best I can suggest is self-building using my AMLMX branch but with the Linux package update to use his latest kernel source (Linux 6.3 IIRC) to see if anything changed.

If you navigate to the build folder and do "make menuconfig" it should detect the local .config file which you can then diff/copy to update the one in the project/device linux folder. I normally just mod the defconfig directly and respin the image. Once in a while settings don't stick and I need to do a little digging in kernel Kconfig to understand dependencies, but over time (with gained experience) that occurs less

Random thought .. I wonder if something like this is needed?

arm64: dts: meson: remove CPU opps below 1GHz for G12A boards - Patchwork

In the Amlogic case it was never fully investigated, mostly because a) there were no volunteers, but also b) if the vendor kernel was also deliberately omitting lower opp-points and not hacking a solution in code (as is normal) that often hints a silicon issue.

You're welcome to try the LE "Generic Legacy" which still includes some older nVidia drivers; although an 8600 card from 2007 will be pushing the boundaries of what might be supported now. I've never even heard of Zorin OS, so problems it has with nouveau are definitely someone else's problem to investigate

Sorry.. "lspci -v | paste" and "dmesg | paste" please

Stats show roughly 250 "OrangePi PC" users (including + and 2+ variants) so the gene pool for problems isn't large and I'd wager the majority of users will be running their mediacentre at HD (720p/1080p) not VGA resolutions; and things where display is out of whack often depend upon a specific monitor/TV and (often) its bad/broken EDID data; which is something to check. Also check cables and if possible ports on the TV. Also share Kodi debug and dmesg logs so we can look for errors. Also ignore "missing settings" because that's a quirk of running Kodi GBM and is not the cause of the problem (I'm pretty confident on that). I'll say again that the issue is likely nothing to do with Kodi and more likely to be something in the kernel DRM layer .. and I note that Batocera's lead maintainer is also one of the maintainers for Lakka which (being a fork of our codebase) inherits kernel sources and patches from LE, with (an educated guess) that the same content gets used with Batocera and the same kernel/patches result in the same kernel/DRM problems.

echo "options snd-hda-intel patch=hda-intel-fix.fw,hda-intel-fix.fw,hda-intel-fix.fw,hda-intel-fix.fw" > /storage/.config/modprobe.d/hda-intel-fix.conf
reboot

^ Please see if that works? (beware the line wrap)

Also, please run "lspci | paste" and share the URL

Quote from mglae

Add the kernel parameter to the APPEND line.

And delete /storage/.config/sysctl.d/video-output.conf ..

The major software-stack difference is that Armbian runs Kodi through a Window manager (Desktop Environment) while LE (10/11/12) runs Kodi direct on hardware (no Window manager, no Desktop). The distros are probably running different kernels too; which may be a factor in things. I'm not really sure what the issue is, but I'd make a semi-educated guess it's something to do with the underlying Linux DRM layer than handles rendering/output to HDMI more than an actual Kodi problem.

Thread moved as it appears you're using an Allwinner board.

I'd start with trawling the Radxa forums and refererring to upstream kernel submissions. RK3399 is pretty mature at this point so as long as the device-tree files are in the kernel (or submitted so can patches can be picked to a self-built image) .. things probably work. That's a rather vague answer but Radxa have been breeding/iterating boards a lot in recent times and it reached the point where tracking all the variants and sub-variants results in

Current state of upstream is being tracked here:

mainline-status.md · main · hardware-enablement / Rockchip RK3588 upstream enablement efforts / Notes for Rockchip 3588 · GitLab

Collabora GitLab

gitlab.collabora.com

HDMI exists in downstream kernels but wasn't reworked and submitted upstream yet, and there are media codec bits missing. AV1 was submitted (to asssist completion of a work package for Mediatek SoCs) but other codecs are still missing. As usual there's a reasonable amount of inheritance from earlier generations but always some changes to work though, and because the primary interest on these SoCs in the Linux world is industrial/IoT applications the media stuff is nearly always done last.

TL/DR; previous statements are still valid

Log shared is nNot a debug log .. so not enough info on media and playback to investigate.

I'd suggest starting with a current and vanilla state LE12 nightly (newer kernel/drivers, no config) .. put Kodi in debug mode, then reboot and run "pastekodi" over SSH to generate a log URL to share here.

It would be nice to have a binary add-on that installs the command-line tools and make them accessible. The challenge historically is that flirc deliberately ships only pre-compiled versions of their binaries, and the way those are (not) versioned (and the lack of sources) would require us to break rules around the content we allow in our binary repo (only things compiled from source, and properly versioned). The workaround for that would be for flirc to run their own repo (to their own rules) and we could embed their repo installer in our repo instead, but that needs some new tricks to be learned on the flirc end. It's something I'll chat to Jason about.

Those customer RR builds are nothing to do with the staff team so we don't provide "support" for them. For that you really need to find the creator .. who appears to have disappeared.

The issue is, the 10.80.12 repo is (was) a pre-release repo and once LE11 shipped we updated the repo version to 11.0.0 and eventually some cleanup removed all the pre-release stuff to save disk space. Hacking an 11.80.2 repo onto the system is a wrong move since that's a pre-release repo for LE12 so things might not be too compatible with LE11.

The better solution would be to hack the current 11.0.0 repo in the image; although whether that's fully compatible with the pre-release state of the rest of the image still isn't something we can answer.

The correct solution would be to rebase the RR changeset on current LE11 (not a pre-release version) and build a clean image.