JMCC

  • Posts

    887
  • Joined

  • Last visited

6 Followers

Recent Profile Visitors

11276 profile views
  1. This one, and the link in the post
  2. Are you sure? Maybe you should read again and follow the link
  3. JMCC

    Mainline VPU

    Here. And read the posts above about Kodi
  4. That seems very interesting. I already built patched Kodi packages for Debian Bullseye (available for download here), but they were not too useful without the kernel-side patches. If you can add those patches to Armbian mainline, we could give it a try.
  5. You can use Armbian build script. In your case, you would only need the device tree for your custom device. Either ask the other company for the .dts, or if that is not possible you can decompile the .dtb from the OS they gave you
  6. I don't know if TeamViewer has a ARM binary for download. If not, I suggest using x2go-server , you can install it from the Debian/Ubuntu repos via apt
  7. Hey, that looks very good!
  8. My guess is that command line forces the use of opengl output, which uses the GPU for displaying frames. GPU needs to copy the frames to and from the memory, and since mem bandwidth is not enough to cope with a 4K stream, hence the stutters. The only way to play 4K is bypassing the GPU and making the VPU block communicate directly with the display block. MPV can only do that with fullscreen KMS managed through GBM. So you will lose the GUI, and you will need to control the player with the keyboard. Try this line: mpv --gpu-context=drm video.mkv
  9. Then it can be easily solved by adding a field like "Provides: linux-image-legacy-rockchip64" to the Debian control file of that kernel.
  10. But then it means that the system has already installed some other kernel, other than rk3399 or rockchip64, am I understanding well?
  11. But, if the package is giving an error when installing, then it means that the system does not have the rk3399 nor rockchip64 kernel package, but a different one. Am I understanding well?
  12. If Kodi works, then it means the underlying RKMPP is working, and the problem is somewhere in mpv. That is a basic first step when troubleshooting something: narrow down the problem. Again, if you don't want help, it's okay, but please don't spam here.
  13. Well, my position is the same as before. I can summarize it in two points: I don't like the idea of adding a new kernel to the already oversaturated mess of RK BSP. We had two (RK3399 and rockchip64), and we were trying to find ways to merge them. It has been a long issue with @piter75, @TonyMac32, @chwe, myself and others trying to find ways of getting rid of this duality, which we haven't gotten yet. But introducing a third one makes the issue even worse. The dependency is necessary for a proper debian packaging. If a package requires another package in order to work (as it is the case), then it must be reflected in the Debian dependencies. The problem with any additional kernel that you may use either in standard Armbian or Armbian-TV, can be easily solved just by adding a field "Provides: linux-rockchip64-legacy" to your custom kernel package.