From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [RFC] drm/i915/bxt: Add pipe_src size property
Date: Mon, 4 Jan 2016 19:06:15 +0200 [thread overview]
Message-ID: <20160104170615.GK4437@intel.com> (raw)
In-Reply-To: <568A4687.2060308@linux.intel.com>
On Mon, Jan 04, 2016 at 11:16:39AM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 23-12-15 om 12:05 schreef Nabendu Maiti:
> > This patch is adding pipesource size as property as intel property.User
> > application is allowed to change the pipe source size in runtime on BXT/SKL.
> > Added the property as inteli crtc property.
> >
> > Comments and suggestions are requested for whether we can keep the
> > property as intel crtc property or move to drm level.
> >
> This property would get lost on a modeset. But why do you need a pipe_src property?
It's needed if we want to use the panel fitter with non-eDP/LVDS/DSI
displays.
Last time this came up I decided that we want to expose this via a new
"fixed_mode" property. Ie. userspace can choose the actual display
timings by setting the "fixed_mode" property with a specific mode, and
then the normal mode property will basically just control just the pipe
src size just like it already does for eDP/LVDS/DSI where we already have
the fixed_mode internally (just not exposed to usersapce). If the
fixed_mode is not specified, things will work just as they do right
now. Obviously for eDP/LVDS/DSI we will reject any request to
change/unset the fixed mode.
The benefit of that approach is that things will work exactly the same
way as before unless the user explicitly sets the fixed_mode, and once
it's set thigns will work exactly the same way as they have worked so
far for eDP/LVDS/DSI. Also it keeps the policy of choosing the fixed
mode strictly is userspace for external displays.
And as a bonus we will also expose the eDP/LVDS/DSI fixed_mode to
userspace giving userspace more information on what the actual panel
timings are. Currently userspace has to more or less guess that one
of the modes the connector claims to support has the actual panel
timings.
So far I've not heard any opposing opinions to this plan.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-01-04 17:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-23 11:05 [RFC] drm/i915/bxt: Add pipe_src size property Nabendu Maiti
2016-01-04 10:16 ` Maarten Lankhorst
2016-01-04 17:06 ` Ville Syrjälä [this message]
2016-01-05 14:50 ` Daniel Vetter
2016-01-05 15:18 ` Ville Syrjälä
2016-01-06 7:57 ` Daniel Vetter
2016-01-07 16:56 ` Ville Syrjälä
2016-01-07 16:58 ` Daniel Vetter
2016-01-07 17:11 ` Ville Syrjälä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160104170615.GK4437@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.