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

[Daniel Vetter]

On Tue, Jun 02, 2020 at 10:38:46AM +0300, Pekka Paalanen wrote:
> On Mon, 01 Jun 2020 14:48:58 +0000
> Simon Ser <contact at emersion.fr> wrote:
> 
> > Describe what a "BAD" link-status means for user-space and how it should
> > handle it. The logic described has been implemented in igt [1].
> > 
> > [1]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0920521946a575bd55f00fbe
> > 
> > Signed-off-by: Simon Ser <contact at emersion.fr>
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > Cc: Manasi Navare <manasi.d.navare at intel.com>
> > Cc: Pekka Paalanen <ppaalanen at gmail.com>
> > ---
> >  drivers/gpu/drm/drm_connector.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index f2b20fd66319..08ba84f9787a 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -994,6 +994,12 @@ 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 connector is no longer enabled. The list of available

"no longer enabled" is kinda wrong, you can keep doing pageflip. It's just
that the pixels aren't getting to the screen anymore.

"enabled" wrt an output has a different meaning in kms, the internal
drm_crtc_state->enabled state is very much still set. Including what that
all means for the uapi.

Also I think we need some words here on what automatically happens when
you do an atomic commit with the connector with the bad link status
(auto-reset to good, which might make the atomic modeset fail). On irc we
had some discussions that we should only do this if ALLOW_MODESET is set,
but that's atm not the case.
-Daniel

> > + *      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.
> >   * non_desktop:
> >   * 	Indicates the output should be ignored for purposes of displaying a
> >   * 	standard desktop environment or console. This is most likely because
> 
> Hi,
> 
> makes sense to me. Can it happen that there will be no modes left in
> the list?
> 
> What if userspace is driving two connectors from the same CRTC, and only
> one connector gets link-status bad, what does it mean? Is the other
> connector still running as normal, as if the failed connector didn't
> even exist?
> 
> That is mostly a question about what happens if userspace does not fix
> up the link-status=bad connector and does not detach it from the CRTC,
> but keeps on flipping or modesetting as if the failure never happened.
> I guess I could ask it about both a CRTC that has another connector
> still good, and a CRTC where the failed connector was the only one.
> 
> Can I trust that if the other connector is in any way affected, it too
> will get link-status bad?
> 
> 
> Thanks,
> pq



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch