From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1890AC433E0 for ; Thu, 25 Jun 2020 07:57:03 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E032820709 for ; Thu, 25 Jun 2020 07:57:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="aiBnYwy4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E032820709 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DC3026E442; Thu, 25 Jun 2020 07:57:01 +0000 (UTC) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0E1EF6E25F for ; Thu, 25 Jun 2020 07:57:00 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id l2so3435847wmf.0 for ; Thu, 25 Jun 2020 00:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=8OIMwuanJl4HmZcEF3LMkNCJV0PX3FzELwr5THzq6dA=; b=aiBnYwy4hD8HoFX/zs2bjVsacnwmxL8hjgY1/+zJKzbGeEmDqdBQJBDqnuIOdaThI+ 2/ft28jzKbGQtM9Nat549HzXpNKetYWCD0/0Lo1gsNWSpnaWa5+f74ExOQ4KZPVgkV1C pRW93Ys0rX7qqc37xsXZqI3dUVBjpB4mbi/kc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=8OIMwuanJl4HmZcEF3LMkNCJV0PX3FzELwr5THzq6dA=; b=hgwTLDa3D6bDwx0jIhqzsF/SoN3bR9msJbfqgkyBfCR3ZixYi1j9cgML3BCI/42VT7 gvYM3A8Bc+gSs4LbNo4C6j4l/LjSRhlHfyuPHgUJJWihEVvQqTwFyOt7IZLMNAlCoIcT ADCBeBshtI1u9pv0KanW2dSVLFtZQqHIQf3J2rMmlJlaQJCuhKHokz8AiVXUJs6MwvOE YkTlnd0Mlzn736CkjOOX0UhRcD2u4YOPGsnb7NNpEdIG1ngPgtgpD3H8a0RBNF60TrkT rPJd5/WPjorPSY0UxTfY0nV9zfDKJpmpABpMbca+oTVrbrkpkeMVBtptxpiBHAktzVc8 /oEw== X-Gm-Message-State: AOAM531XjwuwbpQgDKtHu/AK2l3SHnSegpPc8MDxVe5FTIcABGTGbOTn ppmiTVuVqJ0ndfHUpc70iDPtTw== X-Google-Smtp-Source: ABdhPJwDwsu9Z33N3jB2aVJvsbx+4vaPhtuSnXVPwqO98ZPO+P5JVr9/Jnc6K+k7Btj9aG/rSVy8ng== X-Received: by 2002:a1c:d5:: with SMTP id 204mr1544012wma.174.1593071818586; Thu, 25 Jun 2020 00:56:58 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id o29sm22741989wra.5.2020.06.25.00.56.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 00:56:57 -0700 (PDT) Date: Thu, 25 Jun 2020 09:56:55 +0200 From: Daniel Vetter To: Alex Deucher Subject: Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state Message-ID: <20200625075655.GC3278063@phenom.ffwll.local> References: <20200526011505.31884-1-laurent.pinchart+renesas@ideasonboard.com> <20200526011505.31884-28-laurent.pinchart+renesas@ideasonboard.com> <20200621084000.GM74146@ravnborg.org> <20200624011209.GU5870@pendragon.ideasonboard.com> <20200624072304.GT20149@phenom.ffwll.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.6.0-1-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jernej Skrabec , Laurent Pinchart , Thomas Zimmermann , Neil Armstrong , Jonas Karlman , Kieran Bingham , Maling list - DRI developers , "open list:DRM DRIVERS FOR RENESAS" , Andrzej Hajda , Laurent Pinchart , Sam Ravnborg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote: > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote: > > > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher wr= ote: > > > > > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote: > > > > > > > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote: > > > > > Hi Sam, > > > > > > > > > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote: > > > > > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrot= e: > > > > > > > The DRM CRTC helpers add default modes to connectors in the c= onnected > > > > > > > state if no mode can be retrieved from the connector. This be= haviour is > > > > > > > useful for VGA or DVI outputs that have no connected DDC bus.= However, > > > > > > > in such cases, the status of the output usually can't be retr= ieved and > > > > > > > is reported as connector_status_unknown. > > > > > > > > > > > > > > Extend the addition of default modes to connectors in an unkn= own state > > > > > > > to support outputs that can retrieve neither the modes nor the > > > > > > > connection status. > > > > > > > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > > > > > > From your description sounds like an OK approach. > > > > > > But this is not something I feel too familiar with. > > > > > > Acked-by: Sam Ravnborg > > > > > > > > > > Thanks for the ack. I'd like to have Daniel's (CC'ed) feedback on= this > > > > > too. > > > > > > > > Makes sense, and at least pre-coffee me can't immediately think of a > > > > scenario where we're going to regret this. _unknown status is prett= y much > > > > limited to old VGA and similar things where load detect somehow isn= 't well > > > > supported by the hw. > > > > > > > > Reviewed-by: Daniel Vetter > > > > > > > > > > > > > > > > --- > > > > > > > drivers/gpu/drm/drm_probe_helper.c | 3 ++- > > > > > > > include/drm/drm_modeset_helper_vtables.h | 8 +++++++- > > > > > > > 2 files changed, 9 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu= /drm/drm_probe_helper.c > > > > > > > index f5d141e0400f..9055d9573c90 100644 > > > > > > > --- a/drivers/gpu/drm/drm_probe_helper.c > > > > > > > +++ b/drivers/gpu/drm/drm_probe_helper.c > > > > > > > @@ -491,7 +491,8 @@ int drm_helper_probe_single_connector_mod= es(struct drm_connector *connector, > > > > > > > if (count =3D=3D 0 && connector->status =3D=3D connector_st= atus_connected) > > > > > > > count =3D drm_add_override_edid_modes(connector); > > > > > > > > > > > > > > - if (count =3D=3D 0 && connector->status =3D=3D connector_st= atus_connected) > > > > > > > + if (count =3D=3D 0 && (connector->status =3D=3D connector_s= tatus_connected || > > > > > > > + connector->status =3D=3D connector_statu= s_unknown)) > > > > > > > count =3D drm_add_modes_noedid(connector, 1024, 768= ); > > > > > > > count +=3D drm_helper_probe_add_cmdline_mode(connector); > > > > > > > if (count =3D=3D 0) > > > > > > > diff --git a/include/drm/drm_modeset_helper_vtables.h b/inclu= de/drm/drm_modeset_helper_vtables.h > > > > > > > index 421a30f08463..afe55e2e93d2 100644 > > > > > > > --- a/include/drm/drm_modeset_helper_vtables.h > > > > > > > +++ b/include/drm/drm_modeset_helper_vtables.h > > > > > > > @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs { > > > > > > > * The usual way to implement this is to cache the EDID ret= rieved in the > > > > > > > * probe callback somewhere in the driver-private connector= structure. > > > > > > > * In this function drivers then parse the modes in the EDI= D and add > > > > > > > - * them by calling drm_add_edid_modes(). But connectors tha= t driver a > > > > > > > + * them by calling drm_add_edid_modes(). But connectors tha= t drive a > > > > > > > * fixed panel can also manually add specific modes using > > > > > > > * drm_mode_probed_add(). Drivers which manually add modes = should also > > > > > > > * make sure that the &drm_connector.display_info, > > > > > > > * &drm_connector.width_mm and &drm_connector.height_mm fie= lds are > > > > > > > * filled in. > > > > > > > * > > > > > > > + * Note that the caller function will automatically add sta= ndard VESA > > > > > > > + * DMT modes up to 1024x768 if the .get_modes() helper oper= ation returns > > > > > > > + * no mode and if the connector status is connector_status_= connected or > > > > > > > + * connector_status_unknown. There is no need to call > > > > > > > + * drm_add_edid_modes() manually in that case. > > > > > > > > Hm calling drm_add_edid_modes if you have no edid is a bit a funny = idea > > > > ... Personally I'd just leave out the last sentence, I think that o= nly > > > > confuses readers. Or I'm not grasphing what you're trying to tell h= ere. > > > > > > IIRC, some drivers used and desktop environments expected unknown > > > rather than off for LVDS/eDP panels when the lid was shut or if the > > > mux was switched to another device in the case of hybrid laptops. > > > > We seem to have totally ditched that in > > > > commit 05c72e77ccda89ff624108b1b59a0fc43843f343 > > Author: Ville Syrj=E4l=E4 > > Date: Tue Jul 17 20:42:14 2018 +0300 > > > > drm/i915: Nuke the LVDS lid notifier > > > > No screaming yet. > > > > But I'm also a bit confused, for a panel there's generally an edid > > around, or a fixed (list of) modes. That's enough to stop this > > fallback from running, so should be all fine. > = > No, you are right; you will have the EDID so this shouldn't be an > issue. I was mis-remembering the original issue. We originally > always reported connected for LVDS in radeon if the panel was present, > but then we got flack because some userspace expected unknown in > certain cases (e.g., lid or muxed displays). Either way the EDID info > is still there. Yeah I think i915 started that habit, but I guess people realized it's unreliable enough that they should have their own lid handler in the desktop enviromnent doing whatever they want to do on lid close. Should we perhaps document that somewhere, that panels are always marked as connected? Not even sure where to put that in the docs ... Maybe adding a few of the usual suspects from the compositor side, Simon, Pekka? -Daniel > = > Alex > = > = > > -Daniell > > > > > > > > Alex > > > > > > > > > > > > > > r-b with or without this change since imo super tiny nit. > > > > > > > > Cheers, Daniel > > > > > > > > > > > + * > > > > > > > * Virtual drivers that just want some standard VESA mode w= ith a given > > > > > > > * resolution can call drm_add_modes_noedid(), and mark the= preferred > > > > > > > * one using drm_set_preferred_mode(). > > > > > > > > > > -- > > > > > Regards, > > > > > > > > > > Laurent Pinchart > > > > > > > > -- > > > > 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 > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- = 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