[PATCH] drm: document TV margin properties

[Ville Syrjälä]

On Tue, Feb 28, 2023 at 12:12:22PM +0200, Pekka Paalanen wrote:
> On Tue, 28 Feb 2023 09:53:47 +0000
> Simon Ser <contact at emersion.fr> wrote:
> 
> > On Tuesday, February 28th, 2023 at 09:46, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 
> > > can these be negative as well, to achieve overscan and not just
> > > underscan? Did I get overscan and underscan right... these are related
> > > to under/overscan, aren't they?
> > > 
> > > Hmm, no, I guess that doesn't make sense, there is no room in the
> > > signal to have negative margins, it would result in clipping the
> > > framebuffer while scaling up. So this can only be used to scale
> > > framebuffer down, add borders, and the TV then scales it back up
> > > again?  
> > 
> > Correct.
> > 
> > > Looks like neither my Intel nor AMD cards support these, I don't see
> > > the properties. More things to the list of KMS properties Weston needs
> > > to explicitly control. Oh, it seems vc4 exclusive for now.  
> > 
> > i915 does support it but for TV connectors only (i915/display/intel_tv.c).

I also have some patches to add it for HDMI and DP on i915.
But those are a bit stalled due to more important stuff
taking up my time.

Some fairly old version here:
https://github.com/vsyrjala/linux.git hdmi_margins_3

> > > Is this instead not scaling anything but simply sending metadata
> > > through the connector?  
> > 
> > No metadata is sent. This is purely equivalent to setting up CRTC_*
> > properties to scale the planes.

My wip HDMI/DP patches do set the AVI inforame "bars" based on
this. I think vc4 is already doing that as well.

> 
> Oh! That would be really good to mention in the doc. Maybe even prefer
> plane props over this? Or is this for analog TV, and plane props for
> digital TV?

Plane properties would be pointless for this. CRTC properties might
make sense. But what is more accurate kinda depends on the hardware
design.

> The above are the important comments. All below is just musings you can
> ignore if you wish.
> 
> > > Or are there underlying requirements that this connector property is
> > > actually affecting the CRTC, which means that it is fundamentally
> > > impossible to use multiple connectors with different values on the same
> > > CRTC? And drivers will reject any attempt, so there is no need to
> > > define what conflicting settings will do?  
> > 
> > I don't think any driver above supports cloning CRTCs for these
> > connector types. i915 sets clonable = false for these connectors.
> > vc4 picks the first connector's TV margins, always.
> 
> Sounds like i915 does it right, and vc4 does not, assuming vc4 does not
> prevent cloning.

For i915 my plan was to reject even HDMI+HDMI/VGA cloning (which
otherwise is allowed) when these properties are set. And that's
because they are connector properties and thus could disagree
between the cloned connectors. If they were CRTC properties
that would work fine.

The main reason i915 rejects cloning with many output types
is that generating the correct clock for each output becomes
difficult/impossible. And on HSW+ cloning is no longer
supported by the hardware at all.

> 
> > 
> > > IOW, does simply the existence of these properties on a connector
> > > guarantee that the connector must be the only one on a CRTC?  
> > 
> > I suppose that there could exist some hardware capable of applying
> > margins post-CRTC? Such driver could support cloning CRTCs and still
> > applying the connector margins correctly.
> 
> Yeah, theoretically. But in the KMS object model, is there the idea
> that connectors do not do image manipulation, they can only convert the
> signal type at most and send metadata?

No such rule.

Some hardware has scalers and all kinds of fancy stuff in the 
encoder essentially. Quite common in old TV encoder chips.
That's pretty much where these properties came from I think.

And eDP/LVDS/etc. also do scaling in the connector in the
current model since that's where the 'scaling mode' property
lives.

-- 
Ville Syrjälä
Intel