I probably haven't done a good job of explaining the distinction between the push buffer interface (using ISurface->postBuffer calls) and the overlay interface.
For push buffer interface, SurfaceFlinger handles the job of compositing the frame data presented in the postBuffer() call. For overlay interface, the hardware driver is responsible for scaling, rotation, etc. SurfaceFlinger just leaves a whole in the 2D composited frame (black pixels with alpha = 0) to allow overlay surface to show through the 2D surfaces. Does that help clarify? On Jan 22, 9:35 pm, hanchao3c <hancha...@gmail.com> wrote: > Thank you very much! > > Do you mean if using pmem(or fb), It will bypass the overlay > interface ? > > According to me implement a hardware overlay interface base on general > fb driver is OK. > /hardware/libhardware/include/hardware/overlay.h > > Now many processor have several display plane ， such as S3C6400 , > Omap , IMX.... > For the 2nd display plane , the interface between kernel space and > user space can be fb driver or v4l2 output driver. > Even it is fb driver , It also can give some special IOCTL to do some > function such as rotating, mirror , scaling . > > On Jan 23, 8:07 am, Dave Sparks <davidspa...@android.com> wrote: > > > We plan to support 2 hardware abstractions for video pipeline display: > > pmem and overlay. > > > It seems to me that #2 and #3 are the same thing in terms of hardware > > abstraction. The only difference between them is whether there is > > hardware support for blitting, rotating, scaling, color-conversion, > > etc. In the Android model, this is an abstraction inside the > > SurfaceFlinger and has no bearing on the video pipeline. > > > Of course, you always have a choice to do your own implementation that > > uses a completely different paradigm. We're hoping to make this easier > > soon with better abstraction in the OpenCore sinks and sources. > > > On Jan 21, 5:48 pm, hanchao3c <hancha...@gmail.com> wrote: > > > > Hi Spark. > > > It seems current overlay interface can implemented by using these > > > driver > > > 1. v4l2 output > > > 2. pmem > > > 3. general fb. > > > > According to yourself , which do you prefer ? > > > > On Jan 22, 3:37 am, Dave Sparks <davidspa...@android.com> wrote: > > > > > Yes, the intention with the overlay interface is to be able to support > > > > V4L2 and other overlay hardware. > > > > > On Jan 21, 1:02 am, hanchao3c <hancha...@gmail.com> wrote: > > > > > > The hardware interface is continue changeing in cupcake branch. > > > > > > The hardware overlay interface has some changes now . > > > > > > libhardware/include/hardware/overlay.h > > > > > > Sample Code : > > > > > hardware/libhardware/modules/overlay/overlay.cpp > > > > > > # The main change list: > > > > > 1. overlay_device are separated as overlay_control_device and > > > > > overlay_data_device > > > > > 2. Data path : remove the swapBuffers , getOffset and getMemory > > > > > Add the dequeueBuffer and overlay_buffer_t ! > > > > > > The old interface is designed for using for pmem, which is like a fb > > > > > driver. > > > > > > The new interface is more nature for using v4l2 output driver. > > > > > > Do it mean v4l2 output driver will be the common item for Android ? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to android-framework@googlegroups.com To unsubscribe from this group, send email to android-framework+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
