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

[Ville Syrjälä]

On Thu, Mar 03, 2016 at 03:40:56PM +0100, Fabien DESSENNE wrote:
> 
> On 03/03/2016 02:33 PM, Ville Syrjälä wrote:
> > 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.
> 
> My natural and initial understanding of PRESENT_TOP_FIELD  is "present 
> top field *only*".
> Since these flags are not verbosely documented (and not used in any 
> driver?), I did not catch that it may also mean "present top field *first*"
> 
> So considering this statement, I have a better understanding of what you 
> mean and it looks like there are no real difference between the two 
> compared options. At least for the interlaced scanout case.
> 
> >   You would only use two pageflips for bob deinterlacing.
> For the bob deinterlacing case (progressive scanout) it is a bit 
> different. But well, no so different.
> 
> 
> So focusing back to the initial difference which is about what the flag 
> marks (SetPlane vs fb):
> DRM_MODE_FB_BFF is a fb flag. The fb can be used in SetPlane, PageFlip 
> or SetCrtc calls.
> Since DRM_MODE_PRESENT_TOP_FIELD is a drm_mode_set_plane flag I do not 
> see how we can specify the top/bottom field order in a PageFlip call.

It's all a bit moot since these are legacy APIs and we shouldn't
probably worry about them too much. All that really matters IMO is
atomic. For atomic we need either a few fb flags which could
work for interlaced scanout allowing you to specify tff/bff/any,
but as stated this would then force you to create a second fb if you
missed your deadline for the first field and want to present the second
field instead. But maybe people don't care about deadlines that much?

For the bob deinterlacing we would definitely need some new plane
property. I'm not sure how we'd handle cases where the hardware has some
more fancy adaptive deinterlacing mechanism that can use
weave/bob/something else as needed. I guess it could work with the same
kind of property where the flip to the second field could essentially
become a nop in case the hardware chose to use weave/etc. when the first
field got presented. The other option is providing both fields with the
same flip, but then we'd need to add some kind of target framecount/deadline
for presenting the second field.

> 
> >> 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