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... On Tuesday, March 25, 2014 3:00:07 PM UTC+1, Luc Verhaegen wrote: > > On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote: > > Hi Luc and thanks for replying, > > > > Not sure I follow - I went deeper into the Qt structure yesterday. > > Basically, Qt uses just a normal linux fb access (opens /dev/fb0 > directly), > > while my current no-GUI application (only used to display video from > CSI) > > is using more "advanced" way - it opens /dev/disp first and then > requests a > > layer from it, eventually opening /dev/fb just to execute > > FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an > > endless loop in the program in which buffers from V4L2 exchange > addresses > > with buffers from display. > > > > To my understanding (I'm a bit fresh with all this), Qt should actually > > also open /dev/disp and request a GUI layer (think it's called YUV layer > in > > the user manual for A20) for it, while my underlying V4L2 library should > do > > the same, but only requesting video layer instead of a GUI layer. This > way, > > underlying lib would do the video and provide controls, while overlay > would > > be in a different layer providing GUI which is linked with the controls. > Is > > this true? > > > > If so, there is no easy way to do it, as I would have to implement a > > different display driver for Qt which would use layers instead of > stupidly > > opening /dev/fb0 (this is quite some work) + update my underlying > library > > to actually use display, again with layering. Just saying - compared to > > Freescale kernel, this is far from walk in the park. As I said before, > > Freescale provides a separate /dev/fb for every layer of the screen, > which > > is much easier to work with. > > > > But as I said, I might be completely wrong - what did you have in mind? > > You should use the hw differently, i am not sure whether disp allows > that though. > > Just wait until i finally deliver on my KMS driver, i still am too > lethargic atm to make proper progress on it, although i have added some > good lcd code in the last week. > > Luc Verhaegen. > -- 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.
