jernej Posted June 9, 2016 Share Posted June 9, 2016 Would be anyone interested helping me collecting or making kernel fixes for H3? I already collect some fixes here: https://github.com/jernejsk/linux Question remains what to do with out of tree drivers like mali and wireless. I will probably add those which can be found in most SBCs. Igor, what is the plan with mali driver? Would be r4p0 acceptable? Userspace libraries can be found here. Link to comment Share on other sites More sharing options...
tkaiser Posted June 12, 2016 Share Posted June 12, 2016 Zero feedback so far isn't that much so at least a minor comment: I really like the idea and by looking through the commits I feel you're doing it absolutely right and I also think we all (read as: not just Armbian and your OpenELEC fork but all the others trying to use legacy kernel with H3) will switch rather sooner than later to this fork/branch. But at least I lost somehow interest in legacy kernel in the meantime since for my use cases only THS stuff in mainline kernel is missing (Ethernet works already okish and if performance with GbE further improves even better). Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 12, 2016 Share Posted June 12, 2016 I don't see any downsides for having a maintained repository for H3 legacy kernel. I can help with testing built-in wireless or anything device specific on different Orange H3 boards if it is needed. Igor, what is the plan with mali driver? Would be r4p0 acceptable? Userspace libraries can be found here. Desktop part of Armbian is not actively maintained right now, so I guess anything that works is acceptable. 1 Link to comment Share on other sites More sharing options...
jernej Posted June 12, 2016 Author Share Posted June 12, 2016 Thanks for at least some encouragement While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure. 3 Link to comment Share on other sites More sharing options...
RagnerBG Posted June 13, 2016 Share Posted June 13, 2016 If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on I am sure a lot of people are waiting for this and will be grateful. Armbian is great platform, but with H3 specifically, there are a lot of issues with multimedia part and this should be the main target of this boards. That's why i currently using my router A20 board for multimedia, as it have less issues, which is weird. For example - mpv player works very well and as part of smplayer, even better, but subtitles support through pixman (because of missing g2d) have some annoying overlapping issue, while in your OpenElec they are fine. I don't know how you do it there. And system sounds, like in browsers, have some major bug. Unfortunately i can be of no help in this collecting job, but i just want to say - thank you and take a part in encouragement thing . Link to comment Share on other sites More sharing options...
rellla Posted June 13, 2016 Share Posted June 13, 2016 RagnerBG: the pixman issue should be worked around with the last commit in my dev tree. There is/was some minor issue, that should be easy to fix. I still have to look into it.... Kodi does the gui with gles afaik. Not with cpu via pixman. jernej: do you stay in contact with mosterta regarding libvdpau-sunxi and kodi? Maybe we should all come together in #cedrus some time ... What is the license / eula of the linked mali libs? I did not follow the link so far ... Regards rellla 1 Link to comment Share on other sites More sharing options...
jernej Posted June 13, 2016 Author Share Posted June 13, 2016 (edited) rellla, I think you are right about subtitle rendering. pixman issue should not affect Kodi. I'm not yet in the contact with mosterta, but I guess it would be beneficial. There are some parts in the code, which seems to render image once through vdpau and once through gles... But this is off topic here. H3 kernel has some issues with sound, which should be resolved first, I guess. The problem with userspace mali r4p0 blobs is that they don't have clear usage license. Whitewind has them on github without any info where they came from. I and some others suspect that Steven/Xunlong provided them on forum or through e-mail, but that has to be confirmed. @Igor, can you ask Steven about those mali drivers? Forum thread is extremely long... Edited June 13, 2016 by jernej Link to comment Share on other sites More sharing options...
rellla Posted June 13, 2016 Share Posted June 13, 2016 jernej, to get back to topic, i did apply successfully mostertas UMP patch to the h3 kernel, which is useful to use CMA as UMP backend as noticed here http://linux-sunxi.org/User:Rellla/Armbian A minor fix is needed to get it working. I do not have a patch ready, but can provide one if you want... Regards rellla Link to comment Share on other sites More sharing options...
jernej Posted June 13, 2016 Author Share Posted June 13, 2016 I will port it, no problem. Currently it doesn't apply cleanly due to a newer driver used, but there isn't much to fix. Just out of curiosity - wouldn't be better to use libvdpau-sunxi presentation framework for rendering? Mali was not designed for rendering/scaling/compositing video, especially for 4K, while Display Engine 2.0 (H3 video driver) used in libvdpau-sunxi is designed exactly for that. Link to comment Share on other sites More sharing options...
rellla Posted June 14, 2016 Share Posted June 14, 2016 wouldn't be better to use libvdpau-sunxi presentation framework for rendering? Mali was not designed for rendering/scaling/compositing video, especially for 4K, while Display Engine 2.0 (H3 video driver) used in libvdpau-sunxi is designed exactly for that. Yes. Mali is just the 3D engine. But afaik you can at least display the frame with an EGL window (native or X based). For rendering it should be possible to use the vdpau presentation queue API or use the display ioctls directly in the app... Depends... In case of Kodi, i'm a friend of adapting libvdpau-sunxi to imitate the nvidia/gl interoperation as near as possible to the spec. Just using neither nvidia nor gl but sunxi and gles It is and will always be a hack, because vdpau is not intended to work on ARM at all. But If we can achieve this, the adaptions within e.g. kodi should be not that big. I have some minor success with nv_gles_interop and VDR (www.tvdr.de) already. But now we really get offtopic Regards rellla Link to comment Share on other sites More sharing options...
jernej Posted June 14, 2016 Author Share Posted June 14, 2016 Let's continue that conversation in Kodi topic. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted July 5, 2016 Share Posted July 5, 2016 @jernej So what's the current state of your kernel repository? Are there things left to do or we can use this as default in Armbian? Link to comment Share on other sites More sharing options...
Da Alchemist Posted July 6, 2016 Share Posted July 6, 2016 Perhaps it is possible to integrate this repo to the Armbian Build Script, so more people could test the Kernel. Regards Link to comment Share on other sites More sharing options...
jernej Posted July 6, 2016 Author Share Posted July 6, 2016 @jernej So what's the current state of your kernel repository? Are there things left to do or we can use this as default in Armbian? I'm using it for OpenELEC with it, but currently I don't have much time to invest into it. After two weeks or so I will be back in H3 development. A lot of patches can be dropped if switch is made, but currently the main issue would be need to use r4p0 mali driver in userspace, olders would not work. I also heard that Maxime Ripard has r6p0 driver, which is not yet public. Maybe we could wait for it as it may fix Chrome HW rendering (not really sure about that, but I heard that at least r4p1 is needed for that, maybe tkaiser knows more). Link to comment Share on other sites More sharing options...
Da Alchemist Posted July 6, 2016 Share Posted July 6, 2016 I also heard that Maxime Ripard has r6p0 driver, which is not yet public. Is this the r6p0 driver? Mali Link to comment Share on other sites More sharing options...
rellla Posted July 6, 2016 Share Posted July 6, 2016 This is the kernel part, which is publically available. Problem is the userspace binary library. You need one with a proper license to legally use it.... rellla Link to comment Share on other sites More sharing options...
jernej Posted July 6, 2016 Author Share Posted July 6, 2016 Is this the r6p0 driver? Mali Yes, but only kernel part, which was opensourced long time ago. You also need matching userspace component, libMali.so at same version to make things work. Actually, you can look at kernel space driver just as a helper and userspace library as brains. IIRC ARM page has 64 bit libMali.so r6p0, but not 32 bit. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted July 10, 2016 Share Posted July 10, 2016 Question remains what to do with out of tree drivers like mali and wireless. I will probably add those which can be found in most SBCs. Igor, what is the plan with mali driver? Would be r4p0 acceptable? Userspace libraries can be found here. Another question remains - is this r4p0 libMali.so redistributable? If not, how hard it would be to revert this kernel to older Mali driver? Link to comment Share on other sites More sharing options...
jernej Posted July 10, 2016 Author Share Posted July 10, 2016 Another question remains - is this r4p0 libMali.so redistributable? If not, how hard it would be to revert this kernel to older Mali driver? Well, I really don't know, because thread on OrangePi forum is too long to check. But if you go in this direction, I would worry more for GPL violations in kernel code. As it currently stand, H3 BSP kernel code is not really redistributable, because it contains at least three binary blobs which are statically linked with kernel. One situation is solvable (AR100 FW), but other two are not if you don't want to loose functionality (HDCP code and libisp, which is responsible for camera). OK, HDCP can be removed without much worries. There might also be other blobs. There is certainly one more for ethernet, but it seems to be redundant as code is available. Another issue are files without clear license. Some are missing terms completely and others have only copyrights asserted. This means that you probably can't make completely legal image with H3 BSP kernel. Another thing about mali - if I understand everything correctly, ARM had weird coditions for libMali redistributions until recently and r6p0 will be one of the first releases which can be redistributed without issues. Check this: https://lists.x.org/archives/xorg-devel/2016-June/050294.html Link to comment Share on other sites More sharing options...
Recommended Posts