All of lore.kernel.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 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.