Posts by chewitt

Quote from Dr. Seltsam

The wiki article does not describe how to configure IR remote wakeup.

The IR wake code is hardcoded in the BL301 component of the boot firmware. ISTR that CE uses a custom version of BL301 source with some closed-source companion code to support external configuration. At some point I'll get around to investigating and then replicating something similar but a) done with open sources and mainline u-boot, b) upstreamed so everyone can benefit. I have a rather long to-do list at the moment though.

Quote from Da Flex

OK, so why does that "wakeup" file exist, if at all?

Because Google AI is crap and suggested modifying the device-tree to add wakeup-source; and thus the kernel now blindly exposes support for something that the hardware does not support being controlled from the kernel (it is hardcoded in BL301).

I linked the LE wiki article with instructions for creating a custom keymap in post #192. LE does not run the Amlogic vendor kernel that CE/Odroid wikis are written for. If you continue to use the wrong instructions ..

And you cannot change permissions on /sys and /proc folders that are owned/managed by the kernel. That's basic Linux sysadmin knowledge. Again, whatever instructions you are following are not for the mainline kernel.

Quote from grahamh

chewitt Is this portable to RK3288?

No hope whatsoever. RK3288 is about a decade too old in terms of CPU/GPU performance.

Quote from siriusbox

Since the exact same behaviour occurs with two different remotes, two different Bluetooth chipsets and two different LibreELEC builds, I suspect this might be a software compatibility issue rather than a hardware fault.

It's probably a Bluetooth LE (Low Energy) device and thus drops into deep sleep mode to save battery. I see the same with a couple of BT remotes that I have. Investigating how to avoid "press button to wake remote, wait, press again for the action" has been on my rainy-day project list for a couple of years, but it doesn't rain much where I live..

Quote from the_jaguar

btw, does this work on a Pi4 too or does it require a Pi5?

It's untested but IMHO unlikely to work on RPi4 as its GPU has about 50% the grunt of an RPi5 which is already on the marginal end of support, and DV depends on GPU performance.

The IR remote that Hardkernel sells is supported out-of-box on Odroid boards and we use Hardkernel's BL301 sources for the boot firmware so that remote should also support IR wake. Any other remote will need to be configured with the scan codes:

https://wiki.libreelec.tv/configuration/ir-remotes#configuration-advanced

NB: LE does not currently support programming the IR wake codes into boot firmware, but at some point we should probably look at adding that capability into mainline u-boot so the feature is available to all devices.

The only thing that can dynamically change is an add-on. Look at the add-on update history.

Quote from HiassofT

chewitt I guess this patch should better be dropped and intel devs need to fix the issue properly

I don't think this would cause problems. The patch caps the DRM connector at 10-bit output to prevent it ending up in 12-bit which results in bandwidth issues when HBR audio is present. For DV output we are tunnelling in 8-bit RGB and avoid the problem. I don't see DV issues with a Generic build based on current development running on an N150 box.

That patch is a hack though, so a candidate for improvement as userspace vs. kernel colour support evolves.

The only committed changes in our 12.2 branch since 12.2.1 (last November) have been add-ons and (ironically) timezone and root cert updates, but without any significant changes to warrant pushing another formal release out, there hasn't been one, and for the same reason we stopped LE12.2 nightlies a while ago too, so development has focussed on LE13.

We should/could maybe look at publishing root certs and timezone changes as add-ons to prolong the lifespan of the base images for longer without the need for a full image update. That's probably a rainy day project though..

Add-ons might/would be my blind guess.

Quote from johnny depp

isn’t it the case with the Raspberry Pi 4 that the jack socket has to be enabled in the “config.txt” file first!?

Correct

Quote from Dr. Seltsam

or it was introduced by patches and addons from Zabrimus

This, as there haven't been any issues with input.

Quote from ashi

Looking forward to an upstream merge

It will happen. The current driver I'm using is an ugly port of even uglier vendor driver code and replacing it with something clean that can go upstream has always been the objective.

Quote from ht2tweak

starting to re-use it, navigate around doesn't get it out of that dim mode to normal...

FWIW, I don't see this with any of the nightly images that I run on x86-64/Amlogic/RPi/Rockchip hardware; albeit using the black screensaver instead of dim, but I don't think that would matter since both function in essentially the same way.

Quote from rdorsch

PR11904 is likely related.

It hasn't been merged (still fighting 10-bit output on RK3328) so that's not the cause.

Note: If you are running these rather experimental images we have no great interest in the ticket. Switch to a Generic nightly to reproduce the problem first.

It's not possible to update the zone files without self-compiling an image. It's easier to update to a current LE13 nightly:

https://test.libreelec.tv/13.0/RPi/RPi4/

I've been running (own built) nightlies for the last 18-months and there's nothing unstable about them. The only reason we didn't already ship a K22 beta is me fighting unrelated Rockchip kernel patches.

Depends on what kind of bug report you are submitting. If you have triaged the issue and have a strong idea on the problem open a ticket on GitHub with all the information. Otherwise (and esp. if the issue was diagnosed with AI tools, start a thread in here first to avoid the noise.