ir-keytable needs to be listening on the right protocol to see anything and some remotes have odd vendor invented stuff for power-on events; for the same reason you might not be able to teach a remote that only understands specific protocols and doesn't just capture/record whatever signal is transmitted to it. I'm about to start playing around with the current official HK remote to ensure it works on mainline kernel images using mainline u-boot, but that's not an endorsement and might not be a quick solution.
Posts by chewitt
-
-
The connection manager (connman) stores static connection details against the MAC address, and if you investigate you'll probably discover that the kernel is assigning a random MAC address on each reboot, so there is no matching profile and it defaults to DHCP again. The cause is the hardware manufacturer being too cheap to spend some $$ getting a block of unique MAC addresses for their hardware. To advise a workaround we'll need to know what hardware you have?
-
Users often and wrongly believe pass-through is some magic "hardware doesn't touch the bitstream" method, but in reality the hardware has to support the stream format to correctly detect and handle it as a pass-through stream. Raspberry Pi doesn't support any HD formats.
-
Good point

Add "textmode" to kernel boot params in uEnv.ini and connect a USB keyboard. You'll boot to a console where you can run commands. After running them, remove textmode again, then reboot.
-
chewitt, now, when using the mainline kernel, everything is the same at the linux packages level between Allwinner and Amlogic. With one exception, the m2m cedrus and meson implementation are not compatible. Is there some standardization / merge in progress on that matter?
The video pipelines for Amlogic, Raspberry Pi and Exynos have stateful decoders while Allwinner and Rockchip have stateless decoders. It's not possible to combine them into a single m2m implementation as stateful/stateless work in fundamentally different ways, although we are working to minimise the differences and have ffmpeg mask the implementations so there's still a single/common interface with Kodi. As there's no prior art for anything it's a "two steps forwards, one step backwards" kind of process, and there's still a ton of code to write, but the direction is still forwards, and each month ever more bits of the big jigsaw puzzle are falling into alignment.
-
You'll get the DTS core of HD formats on Raspberry Pi, but that's all.
-
Yes, within the limits of the audio formats that Raspberry Pi supports.
-
How you burn the image (USB/SD Creator or Etcher) has nothing to do with how the image runs. If it boots, it boots.
Try running "systemctl stop [email protected] && systemctl disable [email protected]" and reboot.
-
The audio drivers for G12 hardware are not fully upstreamed yet, and since it's Easter week and lots of people downed tools for a while that's not likely to change for a bit. As has been clearly written (but not read) in previous posts, only USB audio devices will work on G12 things right now.
-
There are no Kodi add-ons or open source applications (apart from suites like LibreOffice) that play pps files.
-
autostart.sh is run at the start of the userspace boot process and if you want things to happen in the background you will need to (background)& the commands. If your script fails un-gracefully it can block the boot process.
-
Kodi does not support playing PowerPoint files. Powerpoint can export the slides as a movie that Kodi can play.
-
Support for installing to VIM emmc will be added to the mainline kernel AMLGX image. It's not there yet, but soon.
-
There's a bug in Kodi that should be resolved in the 18.2 update.
-
The DesignWare HDMI driver used in Amlogic (and Allwinner/Rockchip) devices still needs to evolve 10-bit video support, and the Intel developers still need to get their HDR and colorimetry patches merged into the upstream kernel (still work in progress). In the last week or so we've started to poke the Kodi side of that work using Intel hardware where the dependences in a more mature state, but this is really a green-field area for all Linux hardware, so there are no prior examples to crib things from and we are literally making up the rules (and code) as we go. In the mid/long-term I have absolutely no concerns about LE (and Kodi) having A1+ support for HDR .. and hopefully in the near future I can write a blog post to explain what's going on in the background and why we're rather confident about that

-
As long as the LE release that you had installed on the 3B also supports 3B+ then you can just swap the card. If not, update to latest first and then swap and all should be fine.
-
tools/docker in our git repo, but our distro image/buildsystem environment isn't going to help you develop for our OS. I wish I could help more, but I am not a python developer.
-
wpa_supplicant exists but networks are configured through connman, and both are achieving the same result as the modprobe command. I'm not sure "EU" is a correct value since wireless regulations are normally country specific, hence DE/FR/UK etc. are used.