public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Goel, Akash" <akash.goel@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: Request for feedback : [RFC] Added a new 'window size' property for connector
Date: Fri, 7 Mar 2014 15:01:22 +0200	[thread overview]
Message-ID: <20140307130122.GJ3852@intel.com> (raw)
In-Reply-To: <8BF5CF93467D8C498F250C96583BC09CC7C24A@BGSMSX103.gar.corp.intel.com>

On Fri, Mar 07, 2014 at 12:45:26PM +0000, Goel, Akash wrote:
> Thanks for your feedback.
> 
> > No, fb_id is passed through setcrtc (or soon through setplane, I hope).
> Actually mentioned 'fb_id' also, because if PIPESRC programming is also being updated (as Panel fitter input), then the 'fb' already attached to 'crtc' may not be aligned with it. So there could be a momentary corruption caused when internal modeset is done by Driver (to change the Panel fitter setting), which will last till the next page flip (or setplane).
> 
> 
> > No, we need both the border and the PIPESRC information. hdisplay/vdisplays isn't enough since the user facing mode structure doesn't have vblank_start/end fields. Hence we can't specify borders.
> > If we don't want to extend the display mode, we should add border properties of some sort. I know some drivers have added something like that to the connectors, but again since the mode is applied to the crtc, ideally these properties
> > should also be on the crtc.
> 
> Sorry but it's not quite clear. This is what is my understanding so far, please kindly correct wherever wrong.
> 
> 1.   We need border info for the output of Panel fitter, which will determine the display window. Using the border info we will manipulate the hblank/vblank start/end fields.
> 2.   Currently the values of 'hdisplay/vdisplay' fields sent in 'drm_mode_modeinfo' structure gets programmed in PIPESRC. So if we are adding border info to the same structure, then we can use the 'hdisplay/vdisplay' fields only for   
>       PIPESRC. But if we are defining a new property, to convey the border info, then we need the PIPESRC information also along with it.
> 
> Please confirm that should we add a new a 'blob' type property for 'crtc' ? 

In my ideal solution the panel fitter output will be hdisplay/vdisplay
+/- the border (depending on which way we define it), and the panel fitter
input size will be defined as a new crtc property.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-03-07 13:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-07  9:08 Request for feedback : [RFC] Added a new 'window size' property for connector Goel, Akash
2014-03-07  9:28 ` Ville Syrjälä
2014-03-07 12:45   ` Goel, Akash
2014-03-07 13:01     ` Ville Syrjälä [this message]
2014-03-07 13:49       ` Goel, Akash
2014-03-07 14:11         ` Ville Syrjälä
2014-03-07 17:12           ` Goel, Akash

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=20140307130122.GJ3852@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=akash.goel@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox