JMCC

Members
  • Content Count

    568
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Everything posted by JMCC

  1. If you want plain window managers with no other gadget or bar on the screen, there are quite a few of them: Openbox, Fluxbox or JWM are among the most popular. But they won't make a big difference with LXDE or Xfce in terms of usability in low-res, since in these you can just hide the panel/bar and you will have the full screen available too. What will really matter IMO is that you set low DPI, set a small font, and choose a compact widget theme (for GTK and Qt). And minimalistic window decorations, in case you use them (some window managers don't even use window decorations, see here: https://wiki.archlinux.org/index.php/window_manager ).
  2. Well, this Kodi is just an old beta version. It is not intended for real use, just as a demonstration that Rockchip's GBM and RKMPP are working in our kernels. If you want to use Kodi seriously, I recommend you try LibreElec.
  3. Kodi launcher is not working in recent Armbian. Just launch it from console: Ctrl+alt+F1 sudo service lightdm stop kodi-gbm-wrapper
  4. You can download the image, and follow the instructions under the header "How to start", in this page: https://www.armbian.com/orange-pi-3/
  5. Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent. So a big congrats to everyone who took part on it! Great job!
  6. As a side note, I figured out what was causing the problem with desktop acceleration in Buster. It is this security fix that they introduced in their Mesa 18.3.6 package. So we definitely discard Buster as a multimedia desktop, but Focal may still work, we'll see when it is released.
  7. Notice that in my Renegade was dong something very similar (corrupting fs as soon as it booted), and it turned out to be some problem with not enough current on the SD card reader. @TonyMac32 released a fix that solved it by increasing the current in the DT, but after some upgrades the problem reappeared. Strange enough, it worked with the same DT but Firefly's kernel. I guess it had to be some kernel config missing in our kernel, but I haven't checked it in a while.
  8. No, I mean for the future. When focal is released, still leave Bionic for rockchip legacy desktop as an available download in the main page. Only for legacy desktop, not current
  9. Here is an update about multimedia integration: I have been trying to make all the Rockchip-legacy stuff work on Buster, and I am not able to get accelerated X desktop. I cannot find the exact cause, apparently something is making eglInitailize() fail. My guess is it has something to do with mesa libs, but could not debug the exact cause. In Rockchip, they are working in a completely new approach, using exa instead of glamor acceleration. They need to use for that another particular feature of their SoC's, called Rockchip-rga, which in turn needs its special kernel driver and userspace libs (similar to their rk-mpp). So far, it does not seem to be working in the 'stable-4.4-rk3288-linux' branch we are using, and the stable-v2 branch does not compile ATM. I wasn't even able to make it work with their own linaro image. So my proposal is that we keep the download option of Bionic Legacy Desktop for all the rockchips, with the link to the media-script thread, for those who need to use some of the features that are still only available in legacy kernels. ( @Igor would it be possible to keep it for a while? Bionic still has three years of support ). With newer releases (Buster, Focal), we will focus on mainline, and hopefully at some point legacy won't be necessary at all.
  10. When you decompile a dtb file, you will normally not get the same dts that was used for compiling. It will be a dts that will work the same as the original, but it will not keep the ordering, spacing and indentation, and not even the same identical syntax as the original one. You should instead look for your dts in the kernel source tree. Look in /arch/arm(64)/boot/dts. For example, for Tinker Board in the Mainline kernel, it's this one: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts . Which, in turn, includes another source file, namely this one: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dtsi
  11. Ha ha, I don't think there is an "official" stance on RPi. It is true that, in general, the devs and members of the community tend to think that RPi is already well supported and does not need our additional work. Also, from the technical point of view we don't like some of the RPi engineering choices, but it is also true that we support some other boards that also have similar flaws (e.g. microusb powering). I'm not totally against the idea. The main problem I can think is if we started getting tons of support requests and forum posts about things not working on the RPi, while it would actually not be a supported board. @Igor What do you think?
  12. Yes, it is a known issue with glamor, that instead of "accelerating" it slows down certain 2D operations. In the case of Rockchip's modified glamor to work with OpenGL-ES, It is even worse. It is the trade-off for having the possibility of an accelerated canvas for 3D, video playing, browser, etc. However, in the mainline kernel and current X server, they are tweaking glamor to be much more efficient. Hopefully we can see a stable version soon.
  13. I'd say we are 'famous' for making Linux work on every kind of random piece of hardware, and even many vendors trust in Armbian to make the OS for their devices #proudToUseArmbian
  14. Well, they have backported mesa to bionic-updates, up until 19.2 so far. So it is very likely that in the near future they will backport 19.3 too. Maintaining our own package for mesa 19.3 would be a source for trouble, IMO. I propose to disable glamor in /etc/X11/xorg.conf.d/01-armbian-defaults.conf, by adding something like this: Section "Device" Identifier "Default Device" Driver "modesetting" Option "AccelMethod" "none" ### "glamor" to enable 3D acceleration, "none" to disable. EndSection This will do the trick for the time being, and will make it very easy to enable acceleration when the necessary libs are available.
  15. Notice that you can also install Xorg 1.20 on Bionic, using the hwe packages: https://packages.ubuntu.com/bionic-updates/xserver-xorg-core-hwe-18.04 https://packages.ubuntu.com/bionic-updates/xserver-xorg-hwe-18.04
  16. I'll try to make it for Jan 25 with the integration of multimedia support into the build script
  17. Currently RockPi 4b is not supporting media acceleration. It is a kernel issue, we are working on it. Stay tuned...
  18. Hello and welcome. Are you using Armbian for your project? Which board are you using? Please give more details about the hardware and software you are using, that will increase your chances to get a proper answer.
  19. Ok, everything is as expected. Kodi and docker-chromium are experimental features, it is normal that they fail. But the main ones seem to be still working. Let's see when can we integrate them into the main build script.
  20. It should run as your regular user. Can you launch the browser from console (as your regular user), and post here the output?
  21. Besides, you can already install linux on Android phones, using apps such as Linux Deploy.
  22. Also, if you are going to use the board for LUKS encrypted storage, you may want to have good disk IO performance. So you should probably aim for something with USB3 or PCI support. Rock64 seems like a good option to me, if you want something affordable.
  23. In addition to H3, other 32 bit boards already have HW crypto support in Armbian, as Odroid XU4 for example. But these older crypto implementations are slower than more recent arm64 boards (ref1 ref2)
  24. You're right, now I remembered there are some arm64 SoC's that don't have crypto extensions because the manufacturer didn't pay the license. For example, Amlogic S905 (though S905X has the extensions). So we can also discard Odroid C2 and Nanopi K2.
  25. Well, if I'm not wrong, any arm64 board will have crypto extensions, since these are part of the ARMv8 specification. So anything 64-bit will do the job. A RK3399 will be very fast.