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