On Tue, Jun 02, 2020 at 10:38:46AM +0300, Pekka Paalanen wrote: > On Mon, 01 Jun 2020 14:48:58 +0000 > Simon Ser <cont...@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 <cont...@emersion.fr> > > Cc: Daniel Vetter <dan...@ffwll.ch> > > Cc: Manasi Navare <manasi.d.nav...@intel.com> > > Cc: Pekka Paalanen <ppaala...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
