Re: Request for feedback : New Panel-fitter property for connectors

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Feb 26, 2014 at 03:58:27PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 26, 2014 at 01:32:44PM +0000, Goel, Akash wrote:
> > To expose the panel fitter for arbitrary use by User-space, we will expose the manual scaling ratio & Input/Src size info to User, apart from the available scaling modes like Full screen, Centered, Aspect. 
> > Please suggest that how shall we extend the current interface to incorporate these extra info, considering the options we have .
> > DRM_MODE_PROP_ENUM
> > DRM_MODE_PROP_RANGE
> > DRM_MODE_PROP_BITMASK
> > DRM_MODE_PROP_BLOB
> 
> Either we should have two range properties (eg. crtc_width and crtc_height),
> or we could define a new property type that has both in the same value.
> Not sure if it's worth adding another type for this. Although we might
> be able to use such a type to reduce the number of properties a bit for
> planes and such (src and dst coordinages). The issue is that it
> limits the range a bit. Not a real issue for this case, but for plane
> src coordiantes we'd end up limit ourselves to 16.16 again, which may be
> a bit short sighted.
> 
> And please, no scaling ratio property. Just explicit input and output
> sizes are better IMO. The output size should really be part of the mode
> as borders, but I'm not sure we want to be redefining the mode
> structure. I have no problem with the idea, but maybe other people are
> more reluctant. The alternative is to define the border through
> properties as well.
> 
> We'd also need to figure out how to make this stuff cooperate decently
> with the way we deal with panel fixed modes currently. IMO ideally if
> the user specified the pfit stuff explicitly, we should really treat
> the display mode the user passed in as the adjusted_mode, and not just
> blindly overwrite it. This would also make it much easier to use
> cloning when one of the cloned displays has a fixed mode. Currently
> the user has no idea that the mode he passes in isn't what gets
> programmed into the timing generator, so other displays may not be able
> handle the mode even though it seemed perfectly valid from the user's
> perspective. I guess we could just add a new mode type flag to indicate
> the native mode of the display, but only in case where the display has
> a fixed mode (ie. it won't accept any input timings). Then userspace
> would know that if it wants to do cloning, it should check if any of
> the displays has a fixed mode, and use that for the timings.

One thing on top of Ville's comments:

pfit should get moved to the crtc if we want to expose it generally. On
ilk-bdw we have per-pipe scalers, and those might be really useful for
e.g. upscaling video to an external screen. With atomic modeset there
shouldn't be any flicker involved really, if we get it right.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch