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. You would only use two pageflips for bob deinterlacing. > 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. > >>> -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
