Re: [PATCH 0/2] drm/sti: support of interlaced content with Bottom Field

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote:
> 
> 
> On 03/03/2016 12:28 PM, Ville Syrjälä wrote:
> > On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote:
> >> Hi Ville,
> >>
> >> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes
> >> that the userland controls the field presentation on the display output.
> >> This assumes that the userland is aware of the field actually on display
> >> and I think that this information is not provided by the DRM framework.
> >> Moreover the field management is something very close to the HW and I do
> >> not think that this shall be managed at userland level.
> > Userland is the only one that knows how the data is to be presented, so
> > I don't understand your comment. Userland is the one that would set your
> > fb flag too.
> Sure, the flag is under userland control.
> In the two options I am comparing, this flag is set. But in different ways:
> A/ either  the userland sets DRM_MODE_PRESENT_TOP_FIELD to display the 
> top field, then sets DRM_MODE_PRESENT_BOTTOM_FIELD to display the bottom 
> field. (2 PageFlip calls)

No, in case of actual interlaced scanout the these flags would in fact
mean TFF or BFF. You would only use two pageflips for bob deinterlacing.

> B/ either, the userland sets DRM_MODE_FB_BFF for a single frame, and 
> lets the driver display the two fields (1 PageFlip call)

Well, this would rather be N fields, because the scanout being
interlaced it will keep alternating between the two fields until another
flip is performed.

> >> As an alternative approach, the field management can be transparent to
> >> the userland, letting the driver doing the job. This is how the STI
> >> driver works: when handling an interlaced buffer it displays top and
> >> bottom fields at the right time, synchronized with the VSYNC signal
> >> (vsync for top field / vsync for btm field). The usage of the atomic
> >> mode is transparent for this processing.
> > We can do that on most hardware without specific hardware assist. Well,
> > to be precise we can present the first field correctly, but the
> > second/third field will only be presented correctly if the output
> > refresh rate matches the intended refresh rate for the input data.
> > But any hardware assist would have the same problem as well.
> >
> >> Clearly, the two methods are very different.
> > Not from where I'm sitting.
> >
> >> The proposed patch fits with the second one.
> >>
> >> BR
> >> Fabien
> >>
> >> On 02/29/2016 09:41 PM, Ville Syrjälä wrote:
> >>> On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote:
> >>>> Interlaced video can have different scan order:
> >>>> Top Field First or Bottom Field First
> >>>>
> >>>> In case of video with interlaced content, this information should be
> >>>> propagated from the userland to the DRM kernel driver that will process the
> >>>> deinterlacing starting with the top or the bottom field first.
> >>>> That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom Field
> >>>> First) that should be used jointly with the already existing
> >>>> DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field First
> >>>> scan order should be processed.
> >>> The way I envisioned this long ago is that we would specify the
> >>> bff/tff at flip time. In fact we already have the
> >>> DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for
> >>> setplane. When doing bob deinterlacing these would choose the field
> >>> we're going to present, and when doing interlaced scanout these would
> >>> choose tff vs. bff. But that approach does fall short with atomic when
> >>> you want to flip multiple planes at once.
> >>>
> >>> One problem I see with making this part of the FB is that if you already
> >>> missed your original deadline for the first field, and you want to
> >>> actually present the second field instead, you're forced to create
> >>> another fb. So a plane property might be a bit more flexible. And the
> >>> same way as the setplane flags we could then share the properties for
> >>> bob deinterlacing field selection as well. There's no way to do bob
> >>> deinterlacing with fb flags, unless you create a separate fb for each
> >>> field.
> >>>

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel