[PATCH v3] drm: document how user-space should use link-status

[Pekka Paalanen]

> >
> > I'm not 100% sure the paragraph about not resetting link-status or not
> > using ALLOW_MODESET is accurate. Just like the previous version, this
> > is just an attempt at documenting the current kernel behaviour.
> >
> >  drivers/gpu/drm/drm_connector.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index f2b20fd66319..1df036b3353b 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -994,6 +994,26 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *      after modeset, the kernel driver may set this to "BAD" and issue a
> >   *      hotplug uevent. Drivers should update this value using
> >   *      drm_connector_set_link_status_property().
> > + *
> > + *      When user-space receives the hotplug uevent and detects a "BAD"
> > + *      link-status, the sink doesn't receive pixels anymore (e.g. the screen
> > + *      becomes completely black). The list of available modes may have
> > + *      changed. User-space is expected to pick a new mode if the current one
> > + *      has disappeared and perform a new modeset with link-status set to
> > + *      "GOOD" to re-enable the connector.
> > + *
> > + *      If multiple connectors share the same CRTC and one of them gets a "BAD"
> > + *      link-status, the other are unaffected (ie. the sinks still continue to
> > + *      receive pixels).
> > + *
> > + *      When user-space performs an atomic commit on a connector with a "BAD"
> > + *      link-status without resetting the property to "GOOD", the sink may
> > + *      still not receive pixels. When user-space performs an atomic commit
> > + *      which resets the link-status property to "GOOD" without the
> > + *      ALLOW_MODESET flag set, it might fail because a modeset is required.
> > + *
> > + *      User-space can only change link-status to "GOOD", changing it to "BAD"
> > + *      is a no-op.  
> 
> Above reads well and is accurate I think. I think we should add
> another paragraph about the backwards compatibility hack in SETCRTC
> ioctl:
> 
> "For backwards compatibility with non-atomic userspace the kernel
> tries to automatically set the link-status back to "GOOD" in the
> SETCRTC IOCTL. This might fail if the mode is no longer valid, similar
> to how it might fail if a different screen has been connected in the
> interim."
> 
> With that or similar this has my r-b.

Sounds good to me too. A-b stands.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200605/7d63c19f/attachment-0001.sig>