On Thu, Jun 5, 2014 at 12:49 AM, Anand Sinha <anand.sinha85@xxxxxxxxx> wrote: > Hi Rob, > > Thanks for the answer.so as per the definitions I understand the below > points. > a) frame buffer here signifies the scan out buffer which encompasses > complete display. originally, before planes, the frame buffer covered the complete display. With the advent of planes, now you have crtc scanning fb's (covering complete display) as well as plane(s) scanning out fb's (not necessarily covering the complete display). The more recent introduction of primary planes (ie. now a crtc doesn't directly scan out, only planes do.. with some backwards compat stuff to redirect stuff that used to be in the crtc to the primary plane), even the primary layer does not have to cover the complete display (if hw supports that) > b)when I see the definition of plane in the doc book it says " planes are > associated with a frame buffer to crop a portion of the image source and > optionally scale it to destination size". I assume this is not the same > frame buffer as point a. well, there is no restriction.. you could of course scanout the same fb on both a plane and crtc/primary-plane. The way to summarise it: framebuffer: a piece of memory plus some metadata.. typically a GEM buffer for that piece of memory. But a GEM buffer does not typically have a width/height/pixelformat/etc. That extra metadata are properties of the fb. using legacy APIs, you can configure a crtc to scanout an fb to cover the entire display. Using the newer more flexible plane APIs, you have more control. But you may still have a hw restriction that the primary plane layer must cover full screen. BR, -R > c)planes are overlayed or blended over the scanout buffer. > > Regards, > Anand > > On 23-May-2014 7:25 PM, "Rob Clark" <robdclark@xxxxxxxxx> wrote: >> >> See: >> >> >> http://people.freedesktop.org/~danvet/drm/drm-mode-setting.html#idp57325824 >> >> although the docbook probably should be updated (now that we have >> primary-planes) to read something more like: "...that provide a source >> of pixels to scanout to a plane" >> >> (since a plane is basically the part of display controller block that >> reads in the pixel data from the fb) >> >> >> >> On Thu, May 22, 2014 at 6:30 PM, Anand Sinha <anand.sinha85@xxxxxxxxx> >> wrote: >> > Hello, >> > >> > Can someone help me understand the basic difference between a plane and >> > a >> > frame buffer. >> > >> > Regards, >> > Anand >> > >> > >> > _______________________________________________ >> > dri-devel mailing list >> > dri-devel@xxxxxxxxxxxxxxxxxxxxx >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
