Correction: SurfaceFlinger just leaves a hole (not "whole") in the 2D composited frame (black pixels with alpha = 0) to allow overlay surface to show through the 2D surfaces.
To be clear, this means that the video overlay is behind the 2D overlay. I believe there are provisions for chroma-key if the overlay doesn't support an alpha channel. I shouldn't be posting on a public forum when I am sleep-deprived. On Jan 22, 11:43 pm, Dave Sparks <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
