Re: [PATCH] drm: document TV margin properties

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]

On Tue, 28 Feb 2023 09:53:47 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Tuesday, February 28th, 2023 at 09:46, Pekka Paalanen <ppaalanen@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).
> gud also supports it.
> 
> > Where does this text appear in the HTML kernel docs? I tried to look at
> > drm_connector.c but I cannot find the spot where this patch applies.  
> 
> Here:
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#analog-tv-specific-connector-properties

Analog TV properties? So this does not apply to e.g. HDMI?

I believe HDMI TVs do have the problems that margins could mitigate.

> > Is this actually a connector property? How does that work, should this
> > not be a CRTC property?  
> 
> Yeah, it's a connector property for some reason.
> 
> > 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.

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?


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.

> 
> > 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?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]