Thank you !
It is very clear now!
On Jan 23, 3: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
-~----------~----~----~----~------~----~------~--~---
