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

[Fabien DESSENNE <fabien.dessenne@st.com>]

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)
B/ either, the userland sets DRM_MODE_FB_BFF for a single frame, and 
lets the driver display the two fields (1 PageFlip call)
>> 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.
>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel