LibreELEC Switch support

I know that the devs had issues with the way I did stuff in lakka tree. I was hoping that a working proof of concept build my help. Please respond with a list of code fixes you would like to see, and I will start porting the changes into libreelec clean without lakka specific stuff.

What works:

Pretty much everything I have tested, excepting updater, as I can't add builds to the update path.

What doesn't work:

There was an issue with nvv4l2 decoder with the South Park addon. This addon no longer works at all, so I am not looking to fix at this time, though I do have some ideas why it didn't work, I have no broken path to test the theory, or potential fixes at this time. If and when the addon starts working again, or I get a report of another addon failing in a similar way, I will look into fixing it.

Here is my latest build: https://nightly.builds.lakka.tv/members/gavin/…420-247d2dc.tar

For full feature support enable_upfs = 1 to hekate in file. This enable permissions in storage dir, which is needed for add-ons that try to set permissions on downloaded background executables. Also needed for systemd units in storage dir. System will run without this option, but you might hit permission issues.

Quote from chewitt

Honestly no idea what you're talking about

LE doesn't mind if Lakka things are discussed occasionally, but LE has zero Switch support (and isn't looking to change that) so it's not really on-topic for here. Perhaps better to discuss in Lakka/Retroarch forums?

This isnt lakka, lakka is based on libreelec tree. Basically libreelec with lakka changes dumped on top. I ported switch stuff to lakka. But since libreelec is also still in the tree, firing the build is literally changing the DISTRO variable. The real question I have is why a perfectly working build candidate for a commonly owned platform isn't something you would want to support? That is the part I don't understand? The work is basically done already, and would help other distro devs that base their work off of your trees to easily add support to their builds as well.

Quote from chewitt

I had a quick look over https://github.com/libretro/Lakka….1/projects/L4T and it still appears to be using a legacy vendor kernel and many device-specific-version packages overriding the higher-version packages in the buildsystem, and there are firmware blobs littering the buildsystem instead of being hosted in packages.

For general guidance:

• Use upstream (or near-upstream) kernels; if hardware is not upstream, do work to change that
• Use upstream package versions; if hardware needs an old package, do work to change that
• If you have patches; upstream the patch else you accumulate technical dept and/or get stuck with old packages
• Never host firmware in the buildsystem; always offload it to a repo and source the package

In OE days and early LE when everything except x86_64 kit required some form of downstream codebase and our active team was 4-5x larger, tolerance for "look mum, it booted" levels of codebase maintainbility were also larger. These days the project team is smaller, and we learned the hard way that downstream stuff is generally a complete turd to sustain in the long term. So current LE champions upstream development and generally only accepts downstream items when there is clear line-of-sight on upstreaming activity and we have confidence in being able to drop them in future kernel/package bumps. This actively limits the hardware that we choose to run on, but we've always been okay with that, and we're constantly looking for things we can prune/drop to keep the codebase lean and oriented in a forwards direction.

Lakka inherently cares more about older hardware and has always had a more hobbyist tolerance for niche devices that need a heap of downstream kernel/firmware/package things to make a device boot and run. As Lakka only needs 2D graphics to work, it's also a lot easier to get things working than LE which needs a much higher level of media support.

IMHO current Switch support (dependent on nVidia who is remains focussed on their BSP codebase more than upstream) is still too far downstream for LE to accept, and support should focus on and be maintained in Lakka.

First, thank you for the response.

The firmware is easily worked around, at the time that was something I did so I didn't have to extract multiple bsp's to get the correct firmware blobs. I was being lazy, and should fix that either way. Meant to do that years ago, and forgot. Lol.

As for mainline, there is work in progress on getting full support in kernel for all switch revisions. No idea when that will see the public light of day.

As for the claim that lakka only uses 2d graphics, it has full openGL,GLES,egl, and vulkan supported. In fact I just spent 2 weeks with Claude working around a driver issue that was causing tearing when using vulkan. And if you look at the almost 200 cores included, you would notice tons of cores that do 3d. When infact Kodi retro player doesn't yet support any 3d rendering api's for cores at all, so it only does 2d

As for the maintenance burden, I get that, but as with the lakka tree, I am the only one that maintains the switch port. In fact it is the only port I maintain there. And for years some of the devs have been pushing me to get mainline out there as well. Unfortunately that could be years in the making, and this is currently working build.

Also, I have discovered some issues in the libreelec settings addon and have patches to fix said issues. Bluez dbus isn't gating anything, and accepting all device changed events. This becomes problematic with batteries(Upower, not included in main builds), and Bluetooth audio(possibly not doable in your builds either), and causes whole UI to lock up.

Quote from chewitt

Fixes for settings add-on bugs are always welcome. We're pretty slow at merging things there as none of us are Python devs, but as long as you're patient we'll be able to find someone to assist.

Honestly, not a python dev either, but Claude has been helping me track down issues in Bluetooth dbus implementation. It doesn't currently run checks on dbus. This can cause lockups with bt audio devices, as pulse audio/pipewire, and upower(which isn't implemented in main build). Not a hard issue to trigger, but also not one that would probably pop up in a standard libreelec build(Bluetooth audio routing is missing, and you patch out battery info reporting in information screen, and don't supply upower). Once Claude and I have everything working properly, I will submit patches, for review, and adjust accordingly. That also reminds me I still need to port the upower updates to bsd backend(have logins version working, bsd is the only other option that uses upower), and push that to upstream Kodi as well.