jernej

Members
  • Content Count

    681
  • Joined

  • Last visited


Reputation Activity

  1. Like
    jernej got a reaction from Tido in Kickstarter: Allwinner VPU support in the official Linux kernel   
    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.
  2. Like
    jernej got a reaction from Tido in Kickstarter: Allwinner VPU support in the official Linux kernel   
    Direct access is a bit strong word. Technically, it means that VAAPI layer would be dropped and same interface as in https://github.com/bootlin/libva-v4l2-request 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.
  3. Like
    jernej got a reaction from Tido in Kickstarter: Allwinner VPU support in the official Linux kernel   
    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.
  4. Like
    jernej got a reaction from Tido in 1280X1024 resolution Orange Pi   
    @HANAX please tell me which is your kernel version. If it is based on mainline, there is no need to specify anything. However, just few days ago issue has been found which causes that some resolution don't work. I already prepared some patches to fix that issue.
  5. Like
    jernej got a reaction from PaddleStroke in AV/HDMI switch and display rotation   
    That can work only if /dev/mem (or kmem?) access is permissive, i.e. it is allowed to access device memory regions from userspace. Additionally, daemon has to be run as root (maybe you can drop priviliges later?).
     
    That being said, it can work. HDMI PHY status register is 32 bit wide, located at 0x01ef0038 and as you can see from above snippet, you have to check bit 19.
  6. Like
    jernej got a reaction from PaddleStroke in AV/HDMI switch and display rotation   
    Probably, but it is not HW accelerated on H3.
     
    About other things, something can be done, IF you rebuild kernel with CONFIG_SWITCH or CONFIG_ANDROID_SWITCH enabled. That way you will get few files, which will have different content, based on TV or HDMI hot plug detection status. Not sure where those files will be located, but it will be probably somewhere in /sys or /proc. Code for that is located here:
    https://github.com/armbian/linux/blob/sun8i/drivers/video/sunxi/disp2/hdmi/drv_hdmi.c#L491-L510
    https://github.com/armbian/linux/blob/sun8i/drivers/video/sunxi/disp2/tv/drv_tv.c#L31-L82
     
    In script.bin you would need enabled both, hdmi and tv, or else you won't get status notification. Final step would be writing simple daemon, which will monitor aforementioned files and react on content change accordingly. There is simple way how to enable/disable TV/HDMI display from userspace on running system, but you would need root access. Since you already need to recompile the kernel, you should patch this part of code to have access rights 0666, so root rights are not needed The procedure how to turn on/off hdmi/tv can be found here Just instead "disp" use "disp0" and "disp1" respectively. There is another procedure if this doesn't work.
     
    I'm not sure if work described above is worth the hassle, but your strategy may work.
  7. Like
    jernej got a reaction from chwe in NanoPi K1 Plus + Armbian   
    I just tested 1080p on my development linux branch which consist of linux-next at next-20180515 tag and R40 HDMI patches and it works fine (startx gives normal xfce desktop). However, rootfs is pretty old (year or so old Armbian), so it might not be representative.
     
    I don't have 4K screen...
     
    Coincidentaly, I just received a notification 5 minutes back, that WIP A64 HDMI patches breaks HDMI on H3. Please note that those patches miss some important things and please don't consider them if you don't want complaints from users (it works in some cases). I know what needs to be fixed, but since Jagan started on that, I will just provide reviews.
  8. Like
    jernej got a reaction from valant in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    I don't know actual implementation details, but defining "bootargs" variable with "booti" command works, since I'm using that during development... I think I heard that bootm doesn't work with aarch64 kernels and I didn't even try it.
  9. Like
    jernej got a reaction from valant in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    Same as with other Cortex-A53 AW SoCs, it starts in aarch32 mode. I doubt they changed BROM functionality much.
     
    If you are using mainline U-Boot, that shouldn't bother you, since SPL switches to aarch64.
  10. Like
    jernej got a reaction from chwe in mali node missing from dtb's on H5?   
    Here you have H5 mali DT node patch. Kernel side driver can be found on @Icenowy github page here. However, the biggest question is where to find appropriate userspace drivers if you care about licensing stuff. For private builds you can take them from anywhere you can find them, but it won't be redistributable. Don't forget that mali kernel driver version has to match to userspace version.
     
    About how to add your own patches to build system - you can find some documentation here.
  11. Like
    jernej got a reaction from willmore in Armbian for OrangePi PC2, AllWinner H5   
    Fortunately, VPU driver is around 95% usable also for newer SoCs.
     
    I have a feeling that H6 support will become useful a bit quicker.
  12. Like
    jernej got a reaction from Igor in Next major upgrade v5.60   
    @Igor zador is correct. Patches can be dropped only when 4.17 is released, so in about 2 months. However, there are many DRM changes in 4.16 so it may be better to backport patches from 4.17, but there are many, including in clocks subsystem. Maybe I can find time to look into that later this week.
  13. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).
  14. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).
  15. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).
  16. Like
    jernej got a reaction from MX_Master in OpenRISC core (AR100) for the real-time tasks   
    AFAIK, mainline kernel runs in unsecure mode, where you can't write to secured registers like R_CPUCFG.
  17. Like
    jernej got a reaction from pfeerick in Kickstarter: Allwinner VPU support in the official Linux kernel   
    While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.
  18. Like
    jernej got a reaction from pfeerick in Kickstarter: Allwinner VPU support in the official Linux kernel   
    While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.
  19. Like
    jernej got a reaction from pfeerick in Kickstarter: Allwinner VPU support in the official Linux kernel   
    While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.
  20. Like
    jernej got a reaction from MX_Master in OpenRISC core (AR100) for the real-time tasks   
    No, you have to either change u-boot code or edit boot script and add memory write command (mw.l), which writes right value to register.
  21. Like
    jernej got a reaction from MX_Master in OpenRISC core (AR100) for the real-time tasks   
    Yeah, that's tzpc. I forgot to mention, bsp kernel runs in privileged mode and mainline in unpriviledged mode. That's why you see a difference in behaviour.
  22. Like
    jernej got a reaction from chwe in 1366x768 HDMI Orange Pi PC Plus?   
    You mean predefined resolutions for old BSP kernel 3.4? Mainline kernel should in theory support all resolutions, albeit in practice some may not work correctly.
     
    How did you test that?
     
    If you go with mainline image, it should work. But then, mainline images for H3 are considered WIP and thus not directly supported, e.g. you are on your own with issues. If you go with old BSP 3.4 kernel, you have to patch the kernel to add your resolution. Procedure was already explained on this forum.
  23. Like
    jernej got a reaction from MX_Master in OpenRISC core (AR100) for the real-time tasks   
    Here is attempt to make mainline driver for AR100: https://github.com/mripard/linux/commits/sunxi/wip/ar100 But as branch name says, it's wip and not necessarly working. I didn't try it, I just though it might interest you.
  24. Like
    jernej got a reaction from zador.blood.stained in Banana Pi: Mainline kernel with hw video acceleration / decoding   
    I'm not sure if I completely understand the issue, but recently I came across this LE PR: https://github.com/LibreELEC/LibreELEC.tv/pull/2382
     
    Long story short, kernel from 4.9 onwards has latency issues on USB, which could cause visible artifacts when using DVB dongles. It is not clear what is correct solution, but in this thread some possible workarounds are proposed: https://www.spinics.net/lists/linux-usb/msg163892.html
     
    I think that most promising workaround can be found in LE PR mentioned at the beginning.
     
    Let me know if this is what you're after.
  25. Like
    jernej got a reaction from zador.blood.stained in Banana Pi: Mainline kernel with hw video acceleration / decoding   
    I'm not sure if I completely understand the issue, but recently I came across this LE PR: https://github.com/LibreELEC/LibreELEC.tv/pull/2382
     
    Long story short, kernel from 4.9 onwards has latency issues on USB, which could cause visible artifacts when using DVB dongles. It is not clear what is correct solution, but in this thread some possible workarounds are proposed: https://www.spinics.net/lists/linux-usb/msg163892.html
     
    I think that most promising workaround can be found in LE PR mentioned at the beginning.
     
    Let me know if this is what you're after.