Posts by chewitt

  • HDR on x86 Hardware

    If your distro runs Xorg as the windowing system HDR is not possible (and not likely to change). If it uses Wayland it's possible with the right kernel drivers and mesa for codec, colourspace and colorimetry support, and right now that's more complete with OpenGLES (which is not standard) not OpenGL (standard). And then you'll be challenged by Wayland lacking support for dynamic refresh-rate switching which is essential for a better playback experience. So it's possible, but a conventional desktop distro is probably missing essentials due to favouring stable code over latest code. And even if you pick a rolling and more bleeding edge distro you're probably swimming uphill with a few things to resolve. LE isn't constrained with 'Desktop' requirements so we have it a little easier, but even LE is cannot avoid the reality of Kodi only supporting rather basic HDR things on Linux today. There are PRs on GitHub for some (but not all) missing bits of the puzzle; there are still several unresolved "chicken vs egg" issues between kernel and userspace that need to be addressed. RedHat are sponsoring a Wayland meet-up next month which aims to get enough 'name' developers in the room to agree on a path forwards for the main problems. Hopefully that succeeds, as the discussion has been been rolling on for some time now. Once there is a clear statement of technical direction Kodi developers can plot a course on the missing pieces. Right now Kodi only really supports HDR on Android and Windows; because the underlying OS support HDR and thus we can leverage that. LE is next-best (or least worst) ignoring the existence of some ARM vendor kernels (built for Android) but LE is still dependent on a number of "Work in Progress" pieces that aren't upstream yet, and moving slowly.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from Masutin

    About installing to the internal memory, I know it's discouraged from and deprecated, but would help me, at my risk; no queries in case of failure. Is the solution in finding and running the script?

    The solution is you coding/implementing support for Amlogic's proprietary partition scheme in the upstream kernel. Until that exists there is no way for the kernel or disk tools used in a script to 'see' the Android /system or /data partitions to wipe and reuse them. Even if someone does port the horrid hack from Amlogic sources it will be refused upstream; because it really is a horrid hack.

  • Remote share mount prevents NAS HD from spinning down?

    If you locally mount remote drives the OS is frequently doing something in the background which generates activity and the drives will rarely spin down (and this is not controllable). If you use the SMB/NFS client built into Kodi you might run into client timeout issues (something that can be fine-tuned in advancedsettings.xml) but Kodi shouldn't be accessing the NAS unless scraping or playing and the drives should spin down more frequently. In short; from your description you're doing the former, so it's an expected behaviour.

  • Vorke z6 plus dtb / wifi+bt in kodi / VFD : which dtb ?

    Ethernet looks to be working this time. It has 100Base-T speed, but that could be due to cables or switch ports? - WiFi shows more output this time, but still has errors so we might need to reduce the speed of the SDIO bus.

    Please update to https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar and share "dmesg | paste" URL again.

    Thanks for the Android dts. It confirms a couple of things that I'll need to prepare a proper dts file.

  • Vorke z6 plus dtb / wifi+bt in kodi / VFD : which dtb ?

    Google claims the Vorke Z6 plus is the same as some Tanix box which had board pictures showing QCA9377 as the SDIO module. SDIO WiFi should probe and load automagically regardless of device-tree content, so not sure why it doesn't, but BT is serial UART based and needs the correct content in device-tree to probe and load drivers. VFD also needs content in device-tree and some detective work.

    If it's a Gbit Ethernet box the Q200 device-tree should work (not Q201 which is for 10/100 boxes). I'd guess Ethernet not-working correctly is the reason for adding the USB Ethernet adaptor?

    I'll think about creating something, but start with logs from Q200 dtb please. If you have the original dts or dtb file from Android that would also be useful to have.

    For other boxes; start individual threads else I easily lose track of things.

  • Initial boot of Orange PI3 LTS

    Code
    WP2:~ # find / -name brightness
/sys/devices/platform/leds/leds/wetek-play:wifi-status/brightness
/sys/devices/platform/leds/leds/wetek-play:ethernet-status/brightness
/sys/devices/platform/leds/leds/blue:power/brightness

    Let's say the blue:power LED is the annoying one:

    Code
    echo 0 > /sys/devices/platform/leds/leds/blue:power/brightness

    Should make it turn off.. and we can script this to run after startup:

    Code
    echo "(sleep 10 && echo 0 > /sys/devices/platform/leds/leds/blue:power/brightness)&" > /storage/.config/autostart.sh

    Should result in the LED being turned off 10 seconds after boot starts. You will obviously need to modify the /path/to/brightness for whatever LEDs are on the board. NB: this only works if the LEDs are GPIO controllable; some LEDs are hardwired.

  • Initial boot of Orange PI3 LTS

    You can power the board off from flirc, but not power on as the USB device is not awake/listening once off. It may be possible to configure a power on event from the IR sensor, but that normally depends on the low-level boot firmware and the device being suspended rather than powered off (so the sensor can receive the power-on code). jernej would need to comment on that possibility.