jernej

Members
  • Content count

    678
  • Joined

  • Last visited


Reputation Activity

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Like
    jernej got a reaction from Igor in v5.51 (desktop on top of cli, xu4 next upgrade, ...)   
    @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.
  11. 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).
  12. 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).
  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 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.
  15. 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.
  16. 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.
  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 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. Like
    jernej got a reaction from valant in Cheap HDMI monitor -1   
    @valant
     
    Yeah, I mean that, but if I understand you correctly, you need just a basic (static?) setup, without any bells and whistels. Then you should probably check U-Boot implementation located here. It is much more basic and it can be reduced even further if you remove audio related stuff. If you want to support only one predefined resolution, then you could also remove all DDC/EDID related stuff. Both changes will probably leave you with only half of the code. I think this is really bare minimum for DW HDMI.
     
    i.MX6 documentation should suffice for such setup. You can even find original pre-release version of DW HDMI documentation on some Chinese forum (I don't know which), but as I said, i.MX6 doc is enough for probably everything you need.
  25. Like
    jernej got a reaction from valant in Cheap HDMI monitor -1   
    @valant
    I can give you some help since I'm working on Allwinner DW-HDMI implementation, but what you asking is totally platform dependant. At least on Allwinner, LCD controller (called TCON) is just something which outputs raw data on parallel or LVDS interface. If you want anything else (TV, HDMI, MIPI-DSI) you must chose pipeline which has encoder right behind LCD controller. So it looks something like:
     
    LCD:
    Display Engine (HW composer) -> TCON (LCD controller) -> LCD panel
     
    HDMI:
    Display Engine -> TCON -> HDMI
     
    I took a quick look at your BSP code and it seems that you have same situation. That means that LCD controller needs to be enabled and properly set up in order to use HDMI.
     
    If you are writing driver for mainline kernel or U-Boot, you are fortunate that most heavy lifting is already done for DW HDMI. You just use library provided inside. If your SoC uses Synopsys PHY, you just need to provide few numbers extracted from BSP driver and some boilerplate code. Unfortunatelly, you have to write full DRM driver for, I'm not sure how there is called, Display Engine and/or (only?) LCD controller.