[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 on our side, that by 'hdisplay/vdisplay', are you referring to values programmed in PIPESRC or 'HACTIVE/VACTIVE' (pipe timings) ? As per our understanding that border info shall be applied on the 'HACTIVE/VACTIVE', i.e. (HACTIVE - Left border - Right Border) x (VACTIVE - Top 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 once User modifies the input size through this property, PIPESRC shall also be 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älä [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; Purushothaman, Vijay A Subject: Re: Request for feedback : [RFC] Added a new 'window size' property 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/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.
- 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.
- 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