| Message ID | 8BF5CF93467D8C498F250C96583BC09CC6F1E3@BGSMSX103.gar.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Feb 19, 2014 at 06:13:53AM +0000, Goel, Akash wrote: > > Hello, > > We are planning to expose a new panel fitter property for the connectors. > We have some use cases like a full screen video playback, where we can flip the frame buffer of any size irrespective of the pipe timings and enable the panel fitter to do scaling instead of using the GPU. > Other use case is the Clone mode, where we can use the composed output of the LFP on the external display, with panel fitter enabled, to avoid GPU composition. > > Please provide inputs/comments on the same. > > Best regards > Akash > > -----Original Message----- > From: Goel, Akash > Sent: Tuesday, February 18, 2014 4:12 PM > To: intel-gfx@lists.freedesktop.org > Cc: Goel, Akash; G, Pallavi > Subject: [PATCH] drm/i915: Added a new Panel-fitter property for connectors > > From: Akash Goel <akash.goel@intel.com> > > Added a Panel-fitter enable/disable property support for the connectors. You are missing why you cannot reuse the connector property "scaling". -Chris
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. Please provide suggestions, that how we can extend/reuse the 'scaling_mode' property here. Best regards Akash -----Original Message----- From: Chris Wilson [mailto:chris@chris-wilson.co.uk] Sent: Wednesday, February 19, 2014 1:58 PM To: Goel, Akash Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for connectors On Wed, Feb 19, 2014 at 06:13:53AM +0000, Goel, Akash wrote: > > Hello, > > We are planning to expose a new panel fitter property for the connectors. > We have some use cases like a full screen video playback, where we can flip the frame buffer of any size irrespective of the pipe timings and enable the panel fitter to do scaling instead of using the GPU. > Other use case is the Clone mode, where we can use the composed output of the LFP on the external display, with panel fitter enabled, to avoid GPU composition. > > Please provide inputs/comments on the same. > > Best regards > Akash > > -----Original Message----- > From: Goel, Akash > Sent: Tuesday, February 18, 2014 4:12 PM > To: intel-gfx@lists.freedesktop.org > Cc: Goel, Akash; G, Pallavi > Subject: [PATCH] drm/i915: Added a new Panel-fitter property for connectors > > From: Akash Goel <akash.goel@intel.com> > > Added a Panel-fitter enable/disable property support for the connectors. You are missing why you cannot reuse the connector property "scaling". -Chris
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. > > 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. > > Best regards > Akash > > -----Original Message----- > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > Sent: Wednesday, February 19, 2014 1:58 PM > To: Goel, Akash > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for connectors > > On Wed, Feb 19, 2014 at 06:13:53AM +0000, Goel, Akash wrote: > > > > Hello, > > > > We are planning to expose a new panel fitter property for the connectors. > > We have some use cases like a full screen video playback, where we can flip the frame buffer of any size irrespective of the pipe timings and enable the panel fitter to do scaling instead of using the GPU. > > Other use case is the Clone mode, where we can use the composed output of the LFP on the external display, with panel fitter enabled, to avoid GPU composition. > > > > Please provide inputs/comments on the same. > > > > Best regards > > Akash > > > > -----Original Message----- > > From: Goel, Akash > > Sent: Tuesday, February 18, 2014 4:12 PM > > To: intel-gfx@lists.freedesktop.org > > Cc: Goel, Akash; G, Pallavi > > Subject: [PATCH] drm/i915: Added a new Panel-fitter property for connectors > > > > From: Akash Goel <akash.goel@intel.com> > > > > Added a Panel-fitter enable/disable property support for the connectors. > > You are missing why you cannot reuse the connector property "scaling". > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
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 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
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.
You can simply add new enum values to the property. In the unlikely
event that not all hardware can support the new values, you can extend
drm_mode_create_scaling_mode_property (and possibly the
drm_property_create_enum) to take a supported mask parameter, as Ville
did for plane rotations.
-Chris
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
> 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
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
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 8c64831..a07f6cd 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1560,6 +1560,7 @@ typedef struct drm_i915_private { struct drm_property *broadcast_rgb_property; struct drm_property *force_audio_property; + struct drm_property *force_pfit_property; uint32_t hw_context_size; struct list_head context_list; @@ -1613,6 +1614,13 @@ enum hdmi_force_audio { HDMI_AUDIO_ON, /* force turn on HDMI audio */ }; +enum panel_fitter { + PFIT_OFF, + AUTOSCALE, + PILLARBOX, + LETTERBOX, +}; + #define I915_GTT_OFFSET_NONE ((u32)-1) struct drm_i915_gem_object_ops { diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a4ffc02..db6ea3e 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -819,6 +819,7 @@ int intel_connector_update_modes(struct drm_connector *connector, int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter); void intel_attach_force_audio_property(struct drm_connector *connector); void intel_attach_broadcast_rgb_property(struct drm_connector *connector); +void intel_attach_force_pfit_property(struct drm_connector *connector); /* intel_overlay.c */ diff --git a/drivers/gpu/drm/i915/intel_modes.c b/drivers/gpu/drm/i915/intel_modes.c index 0e860f3..967e080 100644 --- a/drivers/gpu/drm/i915/intel_modes.c +++ b/drivers/gpu/drm/i915/intel_modes.c @@ -28,6 +28,7 @@ #include <linux/fb.h> #include <drm/drm_edid.h> #include <drm/drmP.h> +#include <drm/drm_crtc.h> #include "intel_drv.h" #include "i915_drv.h" @@ -126,3 +127,33 @@ intel_attach_broadcast_rgb_property(struct drm_connector *connector) drm_object_attach_property(&connector->base, prop, 0); } + +static const struct drm_prop_enum_list pfit_names[] = { + { PFIT_OFF, "pfit off" }, + { AUTO_SCALE, "Auto scale" }, + { PILLAR_BOX, "PillarBox" }, + { LETTER_BOX, "LetterBox" }, +}; + +void +intel_attach_force_pfit_property(struct drm_connector *connector) { + struct drm_device *dev = connector->dev; + struct drm_i915_private *dev_priv = dev->dev_private; + struct drm_property *prop; + struct drm_mode_object *obj = &connector->base; + + prop = dev_priv->force_pfit_property; + if (prop == NULL) { + prop = drm_property_create_enum(dev, 0, + "pfit", + pfit_names, + ARRAY_SIZE(pfit_names)); + if (prop == NULL) + return; + + dev_priv->force_pfit_property = prop; + } + + drm_object_attach_property(obj, prop, 0); } -- 1.8.5.2 _______________________________________________