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

[Fabien DESSENNE]

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.

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