Hi Pekka On Tue, 28 Feb 2023 at 10:12, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > On Tue, 28 Feb 2023 09:53:47 +0000 > Simon Ser <contact@xxxxxxxxxxx> wrote: > > > On Tuesday, February 28th, 2023 at 09:46, Pekka Paalanen <ppaalanen@xxxxxxxxx> 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. I've started a discussion with Simon with regard overscan handling [1]. There would be nothing stopping Weston ignoring the DRM properties if Weston/userspace provides a way to reduce the destintation rectangle on the display device. Using that would also be renderer agnostic. [1] https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3597 > > 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. Correct. Particularly on TVs instead of monitors, it's not uncommon to find the HDMI output gets overscanned. > > > 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. The cloneable flag is in struct intel_encoder, not core. vc4 doesn't support cloning of a single CRTC to multiple connectors at all, and I believe sets up the possible_crtc bitmasks correctly to denote that. Dave > > > > > 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
