Jump to content

jernej

Members
  • Posts

    1144
  • Joined

  • Last visited

Everything posted by jernej

  1. No, that's the only script I wrote. Once things start to work, I lose interest And I'm not fond of python, either.
  2. @danboidif you prefer, we can continue our discussion here. Note, mesa has nothing to do with HDMI plug detection. GPU is distinct core from display engine (that's why you have two dri cards present). I would say it's X11 issue, but then, I have no experience with it on H6. Regarding LED driver - you might make it work with above repo, but then there is easier way, at least if you have some python programming knowledge. I recently added a node for LED display in DT and it will debut with kernel 5.17: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi#L32-L38 Once you have that in DT, together with enabled i2c-gpio and i2c-dev drivers, you can play with LED display as much as you want. For example, with python script using python-periphery library: from periphery import I2C i2c = I2C("/dev/i2c-0") # adjust path as needed msgs = [I2C.Message([0x03], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x24, msgs) # enable display msgs = [I2C.Message([0xff, 0x67, 0x63, 0x63, 0x47], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x33, msgs) # set LEDs i2c.close() Note, that ignore NAK flag is important. FD650 LED driver is not exactly your standard I2C device.
  3. Sure, just check git history of LibreELEC. Generally, each kernel version is supported at some point in nightly images, except when we're preparing on release. So only 5.11 and 5.12 (maybe 5.13?) were skipped. But as I said, there are always bugs regarding codecs and fixes appear only for current kernel version.
  4. IIRC only MPEG2 worked with 4.20. just dig into git history. Note that HEVC bugs are being squashed even now, so anything from that era is (almost) useless. H264 bugs were common till last year... P.S.: I don't care if you're trying to waste your time with this. I certainly wont. I'll only talk from memory, nothing more.
  5. Kernel 4.19 was one of the first which has anything of request API framework IIRC. Task of porting mainlined patches there will be even harder. You can use WIP patches from Bootlin and accompanying libs, but then expect that many videos won't work, especially interlaced H264. Also gstreamer or patched ffmpeg won't be compatible with that API. That's even more futile IMO and don't expect any help from me.
  6. You'll have to also port headers and maybe more. This is generally not something I'd spend time on. It should be easier to update Linux package on openwrt.
  7. hm... that's unexpected. I assumed XR819 comes only with lower specs TX6 (2G version).
  8. H3 and H5 have same encoder, so H3 encoder should also work on H5, but I didn't test.
  9. There is no 5.14 kernel available in Armbian, I talked about minimum version. In general, codecs are improved with (almost) every release, so latest version is best. I only see images with kernel 5.13 on download page, which should in theory work. You can build your own Armbian image with kernel 5.15 (edge).
  10. You can still use services like imgur. I'm still not sure if TX6 variant with 2 GB RAM got renamed to TX6 mini or are these two different products. I only own TX6 with 4 GB RAM, which has RTL8822BS wifi+bt combo.
  11. 5.10 is ancient for video decoding purposes. Codecs started stabilizing after 5.11. With 5.14 you'll have stable and fully working MPEG2, VP8 and H264. If you need low effort solution, build latest gstreamer 1.20 RC with gst-plugins-bad with one of the latest kernels. With proper pipeline, it works. If you need out of the box solution, use LibreELEC distro.
  12. There are 3 possibilities regarding wifi on TX6: - XR819 - wifi only - TX6 mini - RTL8822BS - presumably older TX6 - RTL8822CS - presumably newer TX6
  13. FYI, I ported wifi driver to mainline (top two commits): https://github.com/jernejsk/linux-1/commits/h616-full To say that code is convoluted is a big understatement.
  14. If by that you mean using USB dongle then no. However, if you put your box in FEL mode, you can load U-Boot via USB using another machine. But that's meant more for developers or unbricking and it's not friendly at all for everyday use.
  15. In theory, yes. As long as it has DDR3 RAM (no other RAM type is supported currently). Not to my knowledge.
  16. Nothing out of the box, but someone forward ported BSP driver to mainline and used that with encoding software that was developed back then. However, if you do that, you would lose mainline Cedrus driver (you can't have two drivers loaded for same core). I didn't try it myself, so I suggest you search this forum. IIRC it was discussed on this forum somewhere.
  17. jernej

    Mainline VPU

    GPU rendering is usually preferred in X11 environment. I don't think DRM rendering is implemented in most players under X11. Another common reason would be to use various fancy shaders for post-processing, for features that are not yet supported in driver or not at all in HW.
  18. jernej

    Mainline VPU

    @usual userno idea then. Best to wait on RK devs to update patches, but that will take some time... @iamdrqIt looks you're using 10-bit video sample. It's always good idea to try 8-bit first.
  19. jernej

    Mainline VPU

    Ah, yes, that should work with upstream VP9 API. I'm not sure what could broke with kernel update. There are few HEVC patches that were upstreamed. Maybe order of the fields changed? You can try simple experiment. Copy hevc-ctrl.h from patched kernel sources to ffmpeg sources (replace existing file) and rebuild ffmpeg. If it fails to build, you know some, probably minor, updates are needed. If it goes through, it might just work.
  20. jernej

    Mainline VPU

    Note that final VP9 API, which landed in media repo, is slightly different than before and new ffmpeg patches will be needed. We only have WIP variant for new VP9 API. It works, but breaks SW VP9 decoding. We have some time untill it lands in stable kernel...
  21. If you want video decoding acceleration to work on Kodi with Allwinner SoCs, you need gbm version of Kodi (e.g. without desktop running) and patched version of ffmpeg (I don't think that's provided on Armbian).
  22. Did anyone actually bother to port AW859A driver to mainline? I certainly didn't.
  23. jernej

    Mainline VPU

    I don't use any desktop environment (X11 or Wayland) on SBCs, so I can't tell you what works and what not. However, I can tell you that v4l2 request drivers decode video frames to dma-buf, which can be directly imported into DRM or OpenGL ES (mesa exposes functions to do that, but afaik it convert colour space with GPU, still much quicker than CPU). Later option should work everywhere where OpenGL ES is supported, so under X11 and Wayland too. At first glance, it seems that mpv doesn't have this implemented, but I'm not sure. Kodi has both rendering methods implemented, but only when using GBM variant (nobody bothered to enabled that for other environments).
  24. Sorry, I don't know. I don't use X11 nor displays via SPI.
  25. FYI, if anyone is interested in advancing Armbian support for H616, I just fixed reboot issue on mainline kernel for OrangePi Zero2. In fact, I started collecting H616 patches in hope to create LibreELEC image. Patches can be found here: https://github.com/jernejsk/linux-1/commits/h616-full Note: U-Boot needs this hack: https://github.com/jernejsk/u-boot/commit/d420184997f302f546bb0862b1774cca6b43fb9a Without it, Linux will hang at loading Panfrost driver.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines