> >
> > 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
pgphraw5ogSW7.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
