Just posting to say that it can be done with the Disp driver. Basically it is a bit difficult to figure out how to properly use ioctls to do it, but in the end it is not so difficult to actually do it. However, I'm still facing issues :) Right now I have a video overlayed with a Qt window, and even alpha blending is working properly (pipes need to be setup correctly for alpha blender to work), but due to memory allocation issues from kernel, my Qt overlay is very bad, since it looks like either framebuffer is read bad, or written to bad, as when you move the mouse you get something similar to trails, like ghost pixel groups. Quite ugly actually, but I think it's due to memory allocation (same situation with kmalloc) - once I've managed to remove it, but due to all the commenting and still not having a working version control, I forgot what :( There is a tiny mess with this reserved memory in the disp driver - I will check it on Monday and post back if I find the issue.
Anyway, while it's possible to use it properly, as you can see everything is quite buggy, and really unconventional because of these ioctls. I also took a look at your KMS driver presentation - it looks quite cool and it seems that you've given quite some effort to it. In fact, the main goal for this driver should have been a much better structure, as it seems that like for CSI, it is only copied from sun4i and a bit patched, which made the whole thing bloated and very error-prone - there are so many stupid bugs in this driver and I can almost make that most of them came from copy-pasting the old code... 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
