JMCC

When does that happen, when using GLES or GBM as display driver? (that is, the "regular" mpv launcher or "mpv-gbm")

This means it is not using the GL4ES wrapper, but the Mesa software emulation. First of all, check that OpenGL-ES is working, by running "glmark2-es2" or "es2gears". You should get a message saying it is using the Mali driver, and not the VMware emulation.

As a matter of fact, OpenGL 1.3 can be emulated through GL4ES from any GLES2 compliant board, but even if the current state of the Lima drivers were good enough for that to work , performance in a Mali 450 would be rubbish.

As in so many other cases, the board I'd recommend for this task is Odroid XU4, specially since it is selling for $50 right now. You already have fully working GPU drivers for a recent 4.14 kernel, and even a distro focused on gaming (see this video from @NicoD)

I haven't tried, but if it is not already set to a different value in your config file, I guess it will also work.

There are currently no tablets supported by Armbian, so don't expect any to work out-of-the-box. If you are up to tinkering with things such as u-boot, wifi drivers, etc., in order to make it work yourself, then just look for some tablet with a SoC supported by Armbian, or with WIP images (RK3288 or RK3399 come to my mind as possible candidates).

You can control this by setting INSTALL_HEADERS="no" BUILD_KSRC="no" in config-default.conf About the other issue you describe, I'm not sure to be understanding you correctly. Are you saying that you get different kernel version when building complete images and when building only kernel packages?

If you want to power a external drive relaibly, I would not use any power source that provides less than 3 amps, not only with HC1 but with any board. About power consumption, it will be higher compared to less powerful boards as the Cubie2, but it will stay under 1 amp most of the time, except when you run very demanding tasks.

Totally worth the $50 it costs. As a matter of fact, that would be my first recommendation for your use case.

Are you using Default or Mainline kernel?

When do you get that error? What are you trying to do? What is the command line you are using? Can you play videos with the "Rockchip Gstreamer Player" GUI?

Just to be clear: are you asking how to use lm-sensors on an Ubuntu PC, or in an ARM board supported by Armbian?

Yes, and with no paid premium features. As a matter of fact, it also has an open-source Android app, something that you had to pay for in both Plex and Emby, even when the latter was open source for the server side.

Hello, I take note of the bug, and will have it present for future version of our packages. In the meantime, you can either uninstall libwayland-dev or libmali-rk-dev, which seem to be the conflicting packages.

As you know, I have been using an alternative to Plex, Emby, that has native armhf and arm64 support since a long time ago, besides supporting XU4 hardware transcoding with excellent results. Now Emby went closed-source, and a fork has been created that is under very active development (even more than Emby used to be when it was open source). The project's name is Jellyfin; I haven't tried it out yet, but I want to. It also offers armhf packages: https://jellyfin.github.io/

Apparently, you added that external apt source (wiimu) to your sources.list. If you are not aware of doing such a thing, maybe you followed some tutorial where they added that source, or run some bash script that did it. So the solution would be to look for that repo in /etc/apt/sources.list, or /etc/apt/sources.list.d and delete it.

I am getting excellent results with an Odroid HC1. I use it as an OpenVPN server at home, and with my laptop as roadwarrior I get about 80-90 Mbps over my 100 Mbps connection. And also, since now it is on sale, you can get a HC1/MC1 Solo/XU4Q for about $50 at Ameridroid. Other than that, anything with crypto extensions and good single-thread performance would do good, like some RK3399 for example (though it will be more expensive). Avoid boards with many slow cores but no big ones, since OpenVPN is single-threaded.

Probably with Wayland, but I am not aware of anyone who has made that work yet. You have another option: use a Kodi YouTube addon, or use MPV-GBM like this: sudo apt install youtube-dl mpv-gbm "http://youtube.com/etc..." Of course, you only need to install youtube-dl the first time. Are you sure you are using MPV-GBM, and not the regular MPV? You must right-click on the video file and select "MPV (GBM)", or type "mpv-gbm <filename>" from the command line. That is not using HW acceleration. You need to use the "Rockchip Gst Player" launcher, or type the same command line used in the "Rockchip Gst Player" desktop launcher (I can't remember it now, just open the .desktop file and copy it).

With this setup, Chromium will play up to 1080p, probably some 1440p, but definitely not 4k (2160p). What is the command line you are using to launch the player? I assume you are using command line and not the desktop launcher, since I see logs. Have you tried to play that same video with MPV-GBM or Kodi?

Okay, thanks for the tests. According to this, Firefox doesn't support native GLES on Linux, while Chromium does. So our only possibility for acceleration in FF was the GL4ES wrapper, but it seems not to work. However, I remember when I made the script Chromium performed better than now. I'm going to investigate, to find out whether it is caused by some kernel change, or by the recent versions of Chromium. I have some ideas about what it can be.

According to this, Firefox is using CPU-emulated OpenGL, which may be the cause for those crashes you are experiencing. I recommend you to try two things, in order to improve performance and stability: Install the GL4ES wrapper through the script, and launch firefox with the command "glrun firefox" Or simply disable GPU acceleration (like this)

Sorry, I can only help you if you use Armbian, I don't have enough knowledge about the other OS's.

In fact, the 32-bit version of Chromium has h264ify installed by default, if you notice. I was hoping that version could be the one to go for all kind of streaming, but that is not happening until we figure out the stability problems. As a matter of fact, in this case both h264 and vp9 are decoded with the CPU, since Chromium does not support Rockchip's own RKMPP interface for HW decoding. But h264 is lighter on resources than vp9, hence the fact that it runs smoother. Firefox didn't use GPU acceleration in Linux on the past by default, I'm not sure whether the situation has changed. In any case, it would require not only to be enabled by default, but also to support OpenGL-ES. You can check it by typing in the address bar "about:support", and scrolling down to find the GPU section. About Chromium, you can confirm it is using GPU acceleration by entering the address "chrome://gpu". It does work with the script. However, since the SoC has such a weak GPU, using the "acceleration" sometimes means losing performance over mere CPU rendering. That is different with RK3399, which has a much more powerful GPU.

Don't use the "Chromium (32 bit)" launcher, it is just an experiment and ATM needs more work. Use the regular "Chromium" launcher.

Yes, but you probably are experiencing the bug that desktop icons disappear, aren't you? That happens randomly when you enable compositing under Glamor. Plus, you may also notice that scrolling in text windows is terribly slow and abrupt with Glamor enabled. If you use the "plain" MPV launcher, it will not use VPU acceleration for decoding, only GPU acceleration for display. But you can have VPU HW decoding, plus KMS display (much faster than GPU) if you use the "Rockchip Gst Player", or the "MPV (GBM)" launcher (right-click on the video file in the file browser, and select "Open with..."; then you need to press "q" to exit the video). Thanks for the testing.