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

[Fabien DESSENNE]

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.

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.

Clearly, the two methods are very different.
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.
>