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. >>>>> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
