From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: Request for feedback : [RFC] Added a new 'window size' property for connector Date: Fri, 7 Mar 2014 16:11:15 +0200 Message-ID: <20140307141115.GM3852@intel.com> References: <8BF5CF93467D8C498F250C96583BC09CC7C1D8@BGSMSX103.gar.corp.intel.com> <20140307092802.GG3852@intel.com> <8BF5CF93467D8C498F250C96583BC09CC7C24A@BGSMSX103.gar.corp.intel.com> <20140307130122.GJ3852@intel.com> <8BF5CF93467D8C498F250C96583BC09CC7C2B8@BGSMSX103.gar.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <8BF5CF93467D8C498F250C96583BC09CC7C2B8@BGSMSX103.gar.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: "Goel, Akash" Cc: "intel-gfx@lists.freedesktop.org" , dri-devel@lists.freedesktop.org, "Barstow, Jason" List-Id: intel-gfx@lists.freedesktop.org [ccing dri-devel so other people can see what we're cooking...] On Fri, Mar 07, 2014 at 01:49:18PM +0000, Goel, Akash wrote: > > 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. > = > Please could you kindly clarify, so as to avoid any ambiguity/confusion o= n our side, that by 'hdisplay/vdisplay', are you referring to values progra= mmed in PIPESRC or 'HACTIVE/VACTIVE' (pipe timings) ? > As per our understanding that border info shall be applied on the 'HACTIV= E/VACTIVE', i.e. (HACTIVE - Left border - Right Border) x (VACTIVE - To= p Border - Bottom border) will be the output rectangle on screen. I mean what's there in the mode structure. So if we define the border as something that reduces hactive/vactice, we'd program the pfit output size as hactive-left_border-right_border x vactive-top_border-bottom_border. > = > Please also confirm for the border info, you prefer a new property or an = update of the 'drm_mode_modeinfo' structure ? = We can't change the already existing structure, so if we want to update it we'd need drm_mode_modeinfo2 or something and a new set ioctls. My sense of aestethics would prefer that, but from a practical point of view properties seem like the easier choice. > If the panel fitter input size is defined as a new crtc property, then on= ce User modifies the input size through this property, PIPESRC shall also b= e updated with it at that time. But actually change in PIPESRC programming = alone, could also require a reprogramming of the Panel fitter in some cases. Yeah. Before the atomic modeset API is introduced, userspace might want to first disable the crtc, then change the properties, and then set a new mode. That would make it appear atomic and it can avoid problems where the intermediate state isn't exactly valid. > = > Best Regards > Akash > = > -----Original Message----- > From: Ville Syrj=E4l=E4 [mailto:ville.syrjala@linux.intel.com] = > Sent: Friday, March 07, 2014 6:31 PM > To: Goel, Akash > Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; G, Pallavi; Purushotha= man, Vijay A > Subject: Re: Request for feedback : [RFC] Added a new 'window size' prope= rty for connector > = > 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/vdi= splays isn't enough since the user facing mode structure doesn't have vblan= k_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 lik= e 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 det= ermine the display window. Using the border info we will manipulate the hbl= ank/vblank start/end fields. > > 2. Currently the values of 'hdisplay/vdisplay' fields sent in 'drm_mo= de_modeinfo' structure gets programmed in PIPESRC. So if we are adding bord= er info to the same structure, then we can use the 'hdisplay/vdisplay' fiel= ds only for = > > PIPESRC. But if we are defining a new property, to convey the bor= der info, then we need the PIPESRC information also along with it. > > = > > Please confirm that should we add a new a 'blob' type property for 'crt= c' ? = > = > 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=E4l=E4 > Intel OTC -- = Ville Syrj=E4l=E4 Intel OTC