Got it! Full alpha blending works now: 1. Video running in SCALER layer under (720p60 scaled to LCD size), 2. Mali test running over (modified so that background opacity is set to 0.1, while triangle is at 0.5).
Works like a charm. I forgot the most important thing (well, in my case): layer_para_fb.mode = DISP_LAYER_WORK_MODE_NORMAL; For some reason it was working in SCALER mode (probably because workmode for fb0 is set to scaler in my fex file), which is not possible I guess (although both DEFEs can be routed to a single DEBE - maybe it's a disp limitation, or I haven't configured something right). My intention was not to have SCALER for GUI however, only for video... This is the second time my own .fex file is playing on me. Next time I'll really triple check. On Wednesday, April 16, 2014 4:52:32 PM UTC+2, Ivan Kozic wrote: > > 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 <[email protected]> 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 <[email protected] <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/[email protected]/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 [email protected]. For more options, visit https://groups.google.com/d/optout.
