* Re: Request for feedback : New Panel-fitter property for connectors
2014-02-26 13:58 ` Request for feedback : New Panel-fitter property for connectors Ville Syrjälä
@ 2014-02-27 9:58 ` Goel, Akash
2014-03-04 9:46 ` Daniel Vetter
1 sibling, 0 replies; 3+ messages in thread
From: Goel, Akash @ 2014-02-27 9:58 UTC (permalink / raw)
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
> 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.
In VLV, we have to program PANEL fitter control register in terms of Auto/Manual/LetterBox/PillarBox modes, along with explicit scaling ratios, if Manual mode is used.
Whereas for HSW, we program the PF register in terms of the display window size & its location.
So the new interface should be such that this difference is handled seamlessly on Driver side and also it has to be used in conjunction with 'scaling_mode' property.
Can we expose the property where User can specify the Display Window size & its location, & based on that Driver will decide with which mode to program the Panel fitter. The SRC dimensions can be read from the PIPE_SRC register programmed earlier in the Mode set. This will fit directly into the HSW case, but for VLV a conversion will be needed.
The 'scaling_mode' property provides 3 Panel fitter modes.
1. Full Screen : Since the SRC image is to be shown on full screen , we may not need any other input from User for this mode.
2. Aspect Ratio : Here User wants to preserve the Aspect ratio of SRC, but here Driver currently on its own decides that whether the Letterboxing or Pillar boxing is required. Here probably there is a scope of input from User side,
where it can specify both the horizontal & vertical borders in Display window.
3. Centered : Here User wants to show up the SRC image in the middle of the screen, here also same input of horizontal & vertical borders in Display window could be accepted from User.
Best Regards
Akash
-----Original Message-----
From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
Sent: Wednesday, February 26, 2014 7:28 PM
To: Goel, Akash
Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; G, Pallavi; Kannan, Vandana; dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for connectors
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.
>
> Best Regards
> Akash
>
> -----Original Message-----
> From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> Sent: Thursday, February 20, 2014 1:41 PM
> To: Ville Syrjälä
> Cc: Goel, Akash; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter
> property for connectors
>
> On Wed, Feb 19, 2014 at 01:02:57PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 19, 2014 at 09:33:11AM +0000, Goel, Akash wrote:
> > > Thanks for your inputs.
> > >
> > > Actually for our use cases, the 'scaling_mode' property currently being used for 'lvds' & 'dp', cannot be used as it is.
> > >
> > > For our use cases, we need to provide a fine level control to User, so as to be able to choose the LetterBox/Pillar-box modes & also the Manual mode with horizontal & vertical scaling ratios.
>
> You can extend the current interface to add the extra modes (letter, pillarbox, and later the manual toggle).
>
> > > Please provide suggestions, that how we can extend/reuse the 'scaling_mode' property here.
> >
> > My plan is to somehow expose the panel fitter input and output sizes
> > explicitly at some point. The output size could be expose by adding
> > borders to the display mode structure (or some border properties if
> > we don't want to change the user visible mode struct). And the input
> > size could also be done via properties.
>
> Agreed, this is how we have talked about exposing the panel fitter for arbitrary use by userspace (such as overscan compensation).
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Request for feedback : New Panel-fitter property for connectors
2014-02-26 13:58 ` Request for feedback : New Panel-fitter property for connectors Ville Syrjälä
2014-02-27 9:58 ` Goel, Akash
@ 2014-03-04 9:46 ` Daniel Vetter
1 sibling, 0 replies; 3+ messages in thread
From: Daniel Vetter @ 2014-03-04 9:46 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Goel, Akash, intel-gfx@lists.freedesktop.org, dri-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread