Ok, I figured most of it out from the Mali drivers. Still no solution so far however.
Mali is using regular framebuffer by taking fb_start and fb_size vars from the kernel. However, no matter what I do I still cannot make this fb layer transparent - I'm probably missing out something obvious here due to me being still fresh in all this. What I've tried (no Mali, just trying to make fb layer transparent): - Init video layer and run video on it (pipe 1, alpha at 0xff, scaler layer), - Move the video layer to the top, - Get the FB layer handle to play with (open /dev/fb0 and use FBIOGET_LAYER_HDL_0 to get the layer handle), - Use DISP_CMD_LAYER_GET_PARA to get the layer parameters, - Just in case - set fb layer pipe to 0, mode to interleaved, format to ARGB8888, seq to ARGB, alpha_en and alpha_val to 0, - Use DISP_CMD_LAYER_SET_PARA to set the new layer parameters (DO NOT TOUCH .fb.addr[x]), - Write 0x00 or 0x80 to the file handle of /dev/fb0 - HxWx4 times, - Close /dev/fb0, - Move the fb layer to the top. Video is still underneath and I cannot see it, unless I move the Video layer up above FB layer. No alpha blending whatsoever. My framebuffer_fb0_num is set to 4 currently, dunno if that makes any issues. If someone knows why is fb layer behaving this way, please share. As I said - to me it seems that I'm missing out on something quite dumb here. If I make a new layer and reserve a chunk of memory for it (through disp_malloc), it works as expected, but this fb layer is very weird. Also I have disabled FBCON in kernel, thinking it might be that, but it isn't... 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.
