Jump to content

JMCC

Members
  • Posts

    941
  • Joined

  • Last visited

Everything posted by JMCC

  1. Once installed the script, this should work for mpv: LD_LIBRARY_PATH=/opt/libmali-gbm:$LD_LIBRARY_PATH mpv --hwdec=auto --vo=gpu --gpu-api=opengl --gpu-context=drm <filename>
  2. Since these kind of libraries are not too big, I usually compile them natively on an ARM board. V3s' CPU may be a little too weak, but you can do it on any other armhf board you have, and it won't take more than a few minutes.
  3. Yes, it certainly does. I don't know if the media script will work with this or not, depends whether the defaults of the programs I compiled were to enable or disable v4l2-m2m (I think at least ffmpeg in mpv has it enabled). I won't have access to my board in some days, so I cannot test now.
  4. Well, in that case, I have used a gmx.com account in the past as a SMTP server. I don't think using it for the purpose we are talking about now is against their TOS (I've seen nothing in the agreement that suggests it may be incompatible). The only drawback is that you need to login to the account at least once every six months, in order to keep it alive. I know opening the web interface is enough for this purpose, and it will probably be enough too to configure a mail client pointing at the account, so it retrieves the mail every day. It is not enough with just using the SMTP service to keep the account alive. I know there are people who criticize gmx.com, but my experience was good. Of course, I wasn't sending hundreds of emails per day. If setting up a local postfix relay becomes a possibility, I could do that if necessary and keep an eye on it. It is mostly a set-it-and-forget-it setup.
  5. Thanks for testing. That just confirms my guess, that Rockpro64's kernel is missing the necessary modules for HW accel. My fault, I told users in this post specifically to switch to nightly if it didn't work on stable, to test the changes we were pushing
  6. Did you edit "/etc/default/cpufrequtils"?
  7. I think the best solution would be to set up a postfix SMTP server in the same machine that hosts the forum, if that were possible. It takes less than twenty minutes, like this for example. We have full access to that machine, don't we? [EDIT:] The only drawback is that self-hosted SMTP servers tend to be blocked by spam filters, but if anyone wants to receive forum notifications, they can just whitelist Armbian server. We can even put a notice for this in the user's sign-up page.
  8. Yes, that's how HW video accel is performed with my script.
  9. Good to see that you like experimenting. As I said, if you use as a base anything other than Armbian Bionic Default image, results can be unpredictable. I invite you to use the build script to make a proper image, or wait until it is publicly released, if you want to take advantage of all the possibilities of the script.
  10. Yes, actually "Desktop acceleration" means here "Desktop GPU integration". Ironically, when using the X server, that very often means that the Desktop will be slower and laggier when "accelerated". It even happens on my desktop Intel Core i7 computer . It's a fault of the terribly outdated X protocol; just imagine all Windows 10 graphic stack was running on top of the Windows 3.1 graphic system: that's something similar to what we are doing today in Linux. That is precisely the reason why Wayland appeared. Now it is getting more mature, and is without any doubt the future for Linux desktop in general. And even more in embedded systems, which don't support the full OpenGL API, but only a reduced version (OpenGL for Embedded Systems), designed basically to run Android and similar OSes. On the other hand, Wayland is much more similar to the Android graphics API, which is what those SoC's are designed for. So, in short: X server sucks, even more when it comes down to acceleration, and even more when you want to perform that acceleration with a device that only supports OpenGL-ES (i.e. a Mali GPU). Right now, I'm working on Amlogic X acceleration, and I'm getting more and more convinced that we need to move to Wayland if we want to get serious about accelerated desktop.
  11. Me lost too . What is your board? Symptoms? What does "not work" mean: link drops, no link, no led...? And please provide the logs, that is, the output of "sudo armbianmonitor -u"
  12. Sorry, I didn't understand your question either. Can you rephrase it? [EDIT:] If your question is whether the script will work on a server image, with no Desktop installed, the answer is probably not. You can test, but don't expect to get support for it here.
  13. Aha, I got it. We were missing the firmware. Here is the output of mpv. Notice the line confirming the use of hardware decoding: Here is a ffmpeg output: Though, performance is far from being good yet. Let's see if I can find some time to package everything I have so far into a script, for others to test too. I'm attaching the firmware here. @Igor I'm going to add it to the armbian/firmware repo. meson-firmware.tgz
  14. Hello. I'm still testing, I want to post a howto/script when I have some more results.
  15. I followed your steps and didn't work. I did my tests on an Odroid C2, not sure if that would make a difference. It fails when opening vaapi, and keeps doing SW decoding: I also tried with ffmpeg, and the device is recognized but it does not decode any frame. This is the output: However, I was successful in getting gles to work on X11, using the module from here: https://github.com/superna9999/meson_gx_mali_450. See attached image. It was just good enough for running glmark2-es2, when I tried to run Chromium with egl, it failed with EGL_BAD_ALLOC. [EDIT]: No, it was just a bad flag! Chromium WebGL is also working! See attached pic @Neil Armstrong @TonyMac32 Is there any chance that we patch this mali module into the kernel, so we can test it without the need to compile it separately?
  16. Depends on your board. If it's armhf, you can use Raspbian Stretch repos, otherwise you may need to build. I recommend to build from source in any case, I did it once and didn't take long. https://wiki.x2go.org/doku.php/wiki:repositories:raspbian
  17. Working for me too on my C2. The performance of RTL8188EUS is an order of magnitude faster than legacy kernel, and it doesn't drop connection after a few minutes as before.
  18. I like the big cylindric capacitor that looks like a water tank. Reminds me of the old times...
  19. Good to hear. Also, some comments about wifi. RTL8188CUS (Odroid wifi module 3) has an excellent driver in this kernel. It's much faster and much more stable than in any other kernel I have tried. But support for RTL8188EUS (Comfast WU810N) seems to have been completely dropped, it is not even recognized, while any other Armbian kernel I've used it was recognized although performance wasn't too good. Is this the expected behavior?
  20. That is the problem, then. Well, there are two problems here: 1) RockPro64 uses a different kernel than the other RK3399 boards; and 2) I don't have a RockPro64 to test. So, in answer to your question, I can tell you that my preferred kernel for all other RK3399 boards is default 4.4.167, but it is because I was able to test and patch that kernel with the required features. It seems like that kernel version, on RockPro64, is not working, and there is not much I can do about it. I think we must consider the possibility of moving RockPro64 to standard RK3399, and then all problems would be solved. But we must make sure before that it is possible to do so without breaking other things.
  21. I fixed some u-boot bug, happening in boards with 1GB of RAM, that could not load u-boot. Here is the console log with the failure: Reference to the commit: https://github.com/armbian/build/commit/01571c0a4c6c3e7cdb1fec8c99465d8fc00c8c90
  22. I'm not sure whether they correspond exactly with the number you set, but I can tell they mean a real higher clock speed. I tried with HK's image, and increasing the clock speed through that method causes an increase in hashes/sec with a CPU miner (like ~14.50 hash/s at 1512MHz, vs ~16.50 at 1752Mhz).
  23. That's an improvement over S905X, for sure. But I guess the old settings for higher clock speeds (1.6, 1.75, etc. Ghz) in boot.ini were bound to legacy kernel or uboot, weren't they?
  24. Sorry if the question seems silly, but is there any way to set the higher clock speeds with the mainline kernel?
  25. Thanks for testing. The kodi issue can probably be resolved if you switch to nightly builds through "armbian-config". Now, about acceleration not working, please do the following: Install the OS, and switch to nightly: "sudo armbian-config" Select System->Nightly Run the script Reboot Please post here the output of "ls -l /dev/mali*"
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines