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