Ok, I need to ask you for some help, as it seems that you've done a lot on Mali. I don't need any code help or similar, just a few sentences will do if you have time :) Currently I have OpenGL accelerated Qt, by using normal linux-sunxi with r3p0 Mali drivers - I've noticed that you did your own kernel with newer drivers, but I was already using this one and it's modded a lot, so I opted to continue using it.
The real problem is transparency of this OpenGL Mali layer, which I can only achieve by playing with Alpha channel of the /dev/fb0 (via display ioctls), which is really not useful in Qt (but it works). Ideally, global Alpha for Mali layer should be disabled with Mali rendering in 32 bits, so that I could control transparency from Qt, not from the display driver. However, when I disable global alpha for Mali layer and turn on transparency in Qt, everything is just black. If global alpha is set to 0x80, no matter what I do with the fb0 framebuffer, I can see the video underneath and the picture is blackish. Video is going over Pipe 1 of DEBE0, while GUI is using Pipe 0 of DEBE0. Admittedly, I am not sure if this balckness is coming from Qt or bad disp/mali config, but I'm not really sure how Mali has access to DEBE and where this is handled, but I think in SW it's done over /dev/fb0. I'm also suspecting that something is odd with this "default" layer, but I've searched the kernel code and could not find anything that really pokes me in the eye. So basically, just a place to look for would do... Or any info really... Thanks in advance On Thursday, April 10, 2014 1:49:31 AM UTC+2, Siarhei Siamashka wrote: > > On Wed, 2 Apr 2014 03:00:15 -0700 (PDT) > Ivan Kozic <jimm...@gmail.com <javascript:>> wrote: > > > On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: > > > > > > On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) > > > Ivan Kozic <jimm...@gmail.com <javascript:>> wrote: > > > > > > > Hi Luc, > > > > > > > > Found out why disp driver has choppy overlay - for me overlay comes > > > through > > > > DMA from memory. Funny thing - disp_malloc is fetching cached > memory, so > > > > choppiness or "trailing" is due to caching framebuffer protected > memory. > > > > Very silly - I found this out by changing caching method of ARM from > > > > WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to > boot up > > > :) > > > > > > > > The matter is solved by adding the following line to disp_mmap() > > > function: > > > > > > > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > > > > > > > Solved. Just wondering how people were using this before... > > > > > > As far as I know, nobody is using these bug ridden memory allocators > > > that Allwinner has implemented in disp and g2d drivers. Except for > > > maybe Allwinner itself in their Android code. > > > > Well, as far as I can see, the community is actively working on fixing > > Sunxi kernel, although it seems that interest in 3.4 kernel is somehow > > descending. > > The sunxi-3.4 kernel is still used for reverse engineering the > undocumented graphics/multimedia hardware accelerators and > prototyping the drivers for them. But I don't think that sunxi-3.4 > will last more than 6-12 months even for this purpose. IMHO the > end of life is very near. > > > Anyway, I thought that someone would use overlay from original disp > driver, > > The disp layers are used by a number of sunxi related projects: > https://github.com/linux-sunxi/libvdpau-sunxi > https://github.com/ssvb/xf86-video-fbturbo > http://linux-sunxi.org/XBMC > http://linux-sunxi.org/VLC > > What I said is that disp and g2d memory allocators are not really > used by anyone. > > The drivers from Allwinner lack any concept of security and are working > with physical addresses. They accept these physical addresses from the > userspace without any validation checks. Because every driver has full > access to any location in physical memory (except for cedar, which can > only address lowest 256MB of RAM), it is really irrelevant who has > allocated/reserved any particular physically contiguous memory buffer. > That's why xf86-video-fbturbo just uses the offscreen part of the > framebuffer at the moment, and can use G2D to do some operations > within it. And that's why libvdpau-sunxi uses the memory area > allocated/reserved by the cedar driver for doing all video decoding > in it and then just passes physical addresses to the disp driver to > use them as overlays. No unnecessary memory copies are done (with or > without DMA they would be just a waste of time and memory bandwidth). > > Anyway, the allocator integrated with the sunxi disp driver is so > broken, that I have no non-swear words to express what I think about it. > > Assuming that you really need to allocate physically contiguous > memory buffers for your purposes in sunxi-3.4, it would be probably > better to forget about the half-baked buggy allocators in disp and g2d. > And just implement a physically contiguous memory allocation in a > separate small driver. So that no functionality is copy/pasted around > with all the bugs and ugliness. Perhaps you could have a look at this > 'sunxi_mem' thing together with Juan and try to make something usable > out of it? > > https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03592.html > > > which is why I posted fixes for it - same goes for CSI. > > Maybe I have missed something. Where can we find the fixes? > > > As I said before, even though everything is dirty and buggy, abstraction > > level is much easier to grasp in contrast with Freescale i.MX series > > kernels, at least for beginner/intermediate in Linux programming... > > The extreme simplicity comes from totally ignoring security. This has > both good and bad sides. > > > And honestly, it seems that A20 is suffering from much less HW bugs than > > i.MX6, at least as far as I can see. > > Well, the kernel drivers got cleaned up a little bit and some bugs got > ironed out. But it is still a mess. Especially in the parts of code, > which are not really used by anyone. As for the HW bugs, I don't think > that we have any public errata documents available for A20. But some > HW related oddities exist. > > -- > Best regards, > Siarhei Siamashka > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
