• Content Count

  • Joined

  • Last visited

1 Follower

About jernej

  • Rank
    Embedded member

Recent Profile Visitors

1587 profile views
  1. jernej

    H2+/H3/H5/A64 Disp2 U-Boot video driver

    I gave you new link few posts back. This work has been done about 2 years ago, so I forgot many details. It seems CONFIG_VIDEO_DE2=y is enough to enable driver, TV plug-in is auto-detected at boot only and only PAL is supported. It seems that that branch also doesn't have simplefb support. I don't know when I will get back to this, since I'm busy with Linux kernel stuff, mostly Cedrus and DE2 driver.
  2. jernej

    H2+/H3/H5/A64 Disp2 U-Boot video driver

    Yes, there is no official support for H3 TV out in mainline Linux on any board. And patch provided in that topic probably needs to be updated, depending on the sources you use.
  3. jernej

    H2+/H3/H5/A64 Disp2 U-Boot video driver

    The reason why that patch is still not merged in U-Boot is that it's hardcoded to PAL. BTW, that U-Boot branch doesn't exist anymore. Use that one instead:
  4. That depends on chip itself and only H6 support 10 bit HEVC.
  5. I'll try to add support for it soon. But it will be in the same boat as others at first. Don't expect to have 10 bit HEVC support at the beginning. BTW, VP9 is separate peripheral so it needs separate driver. Since nobody did reverse engineering yet, it will take a long time to be supported. However, it seems to be Webm project reference VP9 HW decoder, so there is a great chance that other SoCs from other manufacturers have same unit and someone else might write a driver for it.
  6. Yes, but I'm not the original author. That would be another LE developer. But I help him. Yes, if board is supported in U-Boot and Linux kernel, adding support for it is easy, just one line. BPI M2+ is not yet added, but it's trivial to do so. But please don't expect wifi to work out of the box. Patches for that are currently WIP by Chen-Yu.
  7. Why it can't be both? I have commit rights for LE and I'm maintainer of allwinner branch (until it's merged in master). And everything I do is in my spare time. As it is the case for any other LibreELEC developer. And 4.20 will be out around Christmas, so I guess I'll merge all HW decoding related patches to allwinner branch around then. But you can get my WIP stuff from my github. BTW, merged version won't use libva-v4l2-request, but native ffmpeg integration.
  8. jernej

    Bananapi m2p HDMI CEC

    libcec and cec-utils will probably never work with mainline kernel CEC infrastructure. You need cec-ctl from v4l-utils to work with that. BTW, if you have 4.17 kernel or higher, make sure that you have "/dev/cec0" device present, otherwise some kernel features might not be enabled. Additionally, it seems that CEC doesn't work on some H3 boards but it does on others. Probably because this feature was never supported in BSP kernel and board maker couldn't really test it. I really don't know if it works on BPi M2+.
  9. jernej

    AV/HDMI switch and display rotation

    I meant chinese pdfs. SDK releases sometimes have some documentation, but it is almost always in chinese. And before you ask, I don't now where to find it. It is already years when I last saw any kind of H3 SDK documentation. BTW, these last post have everything I remember from head. I don't want to spend any time with 3.4 BSP kernel.
  10. jernej

    AV/HDMI switch and display rotation

    No documentation whatsoever, except maybe in Chinese. I found commands in source code here. I already forgot everything related to those commands, so I suggest you take a look at code linked above.
  11. jernej

    AV/HDMI switch and display rotation

    I guess this functionality doesn't work on H3. I have seen something like that for A64 with Allwinner provided changes to X11 driver which used "transform" HW, which exists primarly on A series SoCs (and maybe few others). But I might be wrong...
  12. Of course, I'm using Paul's Kodi hack for the moment, but it is proof-of-concept quality. Nope, but it shouldn't be hard to do. I'm maintaining patches for 4.18 for LibreELEC. But truthfully, I didn't test it on anything else than LibreELEC + Kodi on H3. If there won't be any surprises, driver will be merged in 4.20 kernel.
  13. Cons: I never worked on ffmpeg source or V4L2, so there is large amount of code and documentation to research. Pros: It is the best way to go on for Kodi. It wouldn't even need any change, while for current approach, it needs a patch, which has to be cared for (I''m not sure if approach taken in that patch would be acceptable for upstream Kodi). I think that other problems could also be avoided like excessive buffering... Please don't take that for granted, I don't know ffmpeg well.
  14. Direct access is a bit strong word. Technically, it means that VAAPI layer would be dropped and same interface as in would be used (V4L2 interface with new additions). If I understand correctly, "untiling" research took a bit more time than anticipated. Please also note that request API patches (base for AW VPU driver) are at v18 (!) written by multiple people outside Bootlin. But now that V4L2 base (request API) and VPU driver base are more or less finished, it should be much easier to add support for other codecs. BTW, you can actually watch movies with current H264 driver. It just doesn't cover all possible variants and from time to time you can see artifacts. Bigger problem is ffmpeg + VAAPI combination for H264, since you often run out of memory (note that VPU can address only 128 MB of memory and currently DT allocate even less). This problem is know and noted on cedrus wiki page. I hope that using more direct approach in ffmpeg this could be solved. Contrary to you, I'm not disappointed, since the work needed to make stable base is enormous. Framework which support such driver (request API) is evolving along AW VPU driver and AW VPU driver will be it's first user.
  15. MPEG2 is with latest version definitely production quality while H264 is not. You must understand that MPEG2 is very simple codec. It seems that focus shifted to H265 because Paul has a contract only until end of August. Fortunately, H264 and H265 share some common features, so work on H265 will definitely help with H264. However, it turns out that ffmpeg + vaapi doesn't work well for some not so well formed MPEG2 files (same issues with Intel vaapi + ffmpeg), while purely SW ffmpeg decoding works well. I kinda started working on direct ffmpeg integration, but I'm not sure if I have enough motivation to actually finish it.