On 29.05.2019 09:39, Belisko Marek wrote: > Hi Dimitris, > > On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos <dimt...@gmail.com> > wrote: >> Hi Marek, >> >> that's correct. I have a branch though which I've started to experiment and >> add support for Mali. I didn't finished because I've tried to do this by >> myself from the scratch and soon I've hit a wall. Nevertheless, I've done >> the same for the rk3399 for nanopi-neo4 and during this process I've learned >> a lot on how to do it with some help from other people from the open source >> scene. The graphics stack was too complicated for me in the beginning. > You can maybe look to meta-sunxi there is sunxi-mali driver + > libraries which will add support for that. When I've set that package > to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation > gtk3+ and others. I've spend 2 hours looking and trying yesterday but > without any success. Also pls look at this communication: > https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we > can use opensource drivers + libs later). Thanks. What are you trying to achieve? Which kernel version are you using? Isn't the mali recipe in meta-sunxi quite dated already? Can it work with mainline kernel correctly?
I would suggest to try the recent blobs as described in this post: https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/ As I've written previously, I have been using the Wayland / Qt with good performance on H3 using the mainline kernel. Is it something you are looking for? You can take a look at my dirty branch - maybe this will be any help: https://github.com/3mdeb/meta-sunxi/tree/weston-with-kms/recipes-graphics/mali Unfortunately, I had stopped working on that and presently do not have much time to clean up / get back to it. I can provide some support and / or get back to it if it seems valuable and there is some interest. >> Therefore now that I feel much more confident with it I'm going to re-try >> and finish with my branch. Armbian does have support, so I'll try to stick >> to the Armbian backend for maintenance reasons. >> >> I hope that this will be rather easy, because the dri driver should already >> be there, so the only thing I believe is needed is the blobs and to create >> symlinks for the various so libs to that blob. >> >> Anyway, I'll try to do that also. In the meantime I will also wait a bit to >> see if that merge between those two layers is possible and doable, which >> will help to short the time and effort to do that. >> >> Regards, >> Dimitris > BR, > > marek >> Belisko Marek <marek.beli...@gmail.com> schrieb am Mi., 29. Mai 2019, 08:37: >>> Hi Dimitris, >>> >>> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos <dimt...@gmail.com> >>> wrote: >>>> Hi Enrico, >>>> >>>> I'm totally positive to any possibility for such integration. Personally, >>>> that was the first thing I've tried to do before I start this layer, but >>>> I've failed as it got really complex and the overhead was too much after >>>> some point (at least for me). If you have look it's actually a mix of >>>> meta-sunxi and armbian, but I had to remove or change many stuff to fit >>>> the armbian in the layer. >>>> >>>> If you have time to have a look to my layer and you think that such kind >>>> of integration is possible and can be done in a more easy way, then from >>>> my side I'm all in. >>>> I believe that re-using the armbian patches is easier as it makes >>>> maintenance much easier, there are more supported SBCs and also there is >>>> much more testing involved in armbian and frequent updates fix those bugs. >>> I did check your layer and it seems that you're not using sunxi-mali >>> for opengl HW acceleration only mesa so SW rendering? Thanks. >>>> Please consider it and I can help as much as I can and my time allows for >>>> that integration. >>>> >>>> Regards, >>>> Dimitris >>>> >>>> >>> Marek >>>> On Tue, May 28, 2019 at 12:56 PM Enrico <ebut...@users.sourceforge.net> >>>> wrote: >>>>> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos <dimt...@gmail.com> >>>>> wrote: >>>>>>> I was thinking about this also, too. The only reason is that in >>>>>>> meta-sunxi they do a great job and they keep their layer clean, which >>>>>>> is great I think. The other layers are just based on the armbian >>>>>>> distro, which is a lot different, but for me it was much easier to >>>>>>> integrate their patches, patching scripts and bootloader scripts to a >>>>>>> Yocto layer. That way the only thing I do is that from time to time I >>>>>>> just integrate their new patches and that's it. There's no development >>>>>>> in the layer is just re-use of the armbian work and a wrapper around >>>>>>> it. Therefore, it's hard, even no doable to put those different >>>>>>> architectures together. But definitely that decision also bothered me a >>>>>>> lot before I create the layer and I also don't like time to be spend on >>>>>>> the same thing from different people. Nevertheless, from my point of >>>>>>> view I couldn't find a way to put those things together. I've tried but >>>>>>> I couldn't do it. >>>>>>> >>>>>>> Therefore, it was easier for me to do it the way I've done it. And >>>>>>> after all, although it doesn't seem right, at the same time this is the >>>>>>> beauty of the open source. I think the layers are just incompatible in >>>>>>> the way that they are do things. Also it's not bad to have alternatives. >>>>>>> >>>>>>> Sunxi is a great community and I believe many of the armbian patches >>>>>>> are coming from there. Others not. Of course, having them all together >>>>>>> would be nice. But I don't think that it's possible because of the >>>>>>> different approach. >>>>> It would be great to integrate all those different layers in >>>>> meta-sunxi,the main problem is that usually they come with their own >>>>> bootloader/kernel/etc.... so you have to *maintain* all these >>>>> different configurations. >>>>> Infact in the past i refused to do such things because i didn't have >>>>> the time to maintain all those different versions, it was just easier >>>>> to support what was already in mainline uboot/kernel. >>>>> >>>>> But of course if someone wants to do it then it's welcome, the worst >>>>> thing that can happen is that once an arch gets unmaintained it will >>>>> be removed. >>>>> >>>>> One thing that can be done anyway is to have those external layers >>>>> linked in the readme, so at least people will know they exist. >>>>> >>>>> Enrico -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
