I think that maybe it can be done - I have already started modifying driver for Qt and had some limited success - it is supposed to be using layers now, but I'm generally having issues with the usage of disp driver. In other words it doesn't work yet, but I get a proper layer handle, so good so far. The big problem with all this Allwinner stuff is that ioctls are almost not documented at all and I usually need to go deep into the driver structure to figure out how I should use what.
Forums are also full of unsolved disp issues - I don't think I've seen a single post on how to use GUI layer. Also display driver is very buggy, so it's not really an easy task. I'm also not sure if the display driver can be opened multiple times - my whole idea is based on the fact that it can... What is this about your KMS driver? Not sure I know what the abbreviation stands for. 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.
