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=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 ECAAAC433E0 for ; Thu, 25 Jun 2020 10:32:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C569A20773 for ; Thu, 25 Jun 2020 10:32:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RXyRcSxX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403911AbgFYKcM (ORCPT ); Thu, 25 Jun 2020 06:32:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403816AbgFYKcL (ORCPT ); Thu, 25 Jun 2020 06:32:11 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55C33C061573 for ; Thu, 25 Jun 2020 03:32:10 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id d7so2902459lfi.12 for ; Thu, 25 Jun 2020 03:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=+Z6VNGt9z3xv0ZcVCfN7KPrYK3I7z8tuTUC2LU7MuF4=; b=RXyRcSxXuPF0EN+oGBho+nA6RmiP/TIvJZbOCNGa/Pa7RdfQNstOLoZDWB1BmzHynq BFHYRY7AOTYfjgClkW2Z4W3k0fMYlOEebXv4bZ/LxjnHt8imUttQTr3T9/Gfx0cfpzBl mZWRCJJKWe9WWZLVsiAlERjL3I0x/LMp1XoEsCf9bVsmXZiCBur0uYpHfd0Az4b6Lqmo 1VMHtC5zDpQfUJQ3bO1w4JUnaQ2L3lIxI/F8Fb99kpkYtFOJuZuuYQxOj5X3ZyFYm+9/ ldX7QmtGY45vARXaFI3rhysjzxKKSSutALyDTTVOrhgkQEltbNZnomuDE3pNBSx/U1y4 9DXQ== 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:in-reply-to :references:mime-version; bh=+Z6VNGt9z3xv0ZcVCfN7KPrYK3I7z8tuTUC2LU7MuF4=; b=MxJNaHtoofY1T+B+2bMlcw5sk6BgvlZkq62ZyQJ3yn2J8dTlZZrxr6liRZCIbtmIC4 RC0hGuJFV7dO9QMVnjRX5/NiL1PBRb89SJjKNVAaN8wDfC+fqH3Ee4eweMH5FZG0h7m1 22gdqbyXsTnNkhquBjPJoIBOfwk/OXbLbi/a/cPiOjWX4n6HupCNBd548dIzptIsy84H ttgGxpAYvY29jb4gO/GLCiHj7bERV/3VAF+DfkGdiFjve0+cukOxnd9wGGTjoDJ06koX z2JpHmXJjLrD6apuWfTATpNgd/qNnZGeRuiWed15R8yEmgwfQc511fKPQ3VF4VwySGwv r1fQ== X-Gm-Message-State: AOAM532u9VrZeg7T1pkDusSNrk1YBH0IgQC8Nejs/mMb92Goj1up89Kb Tc0tLM303Q+RH3wFRGE8eLw= X-Google-Smtp-Source: ABdhPJyKZOsOjWNeBiikD6RKFubBSP9qJ2tsD2t8Kpuh6IcOdpGF0c3dFBGHVkEh0fSAaJtKNQymRg== X-Received: by 2002:a05:6512:3226:: with SMTP id f6mr18042900lfe.180.1593081128599; Thu, 25 Jun 2020 03:32:08 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id v3sm677030ljc.96.2020.06.25.03.32.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 03:32:08 -0700 (PDT) Date: Thu, 25 Jun 2020 13:31:57 +0300 From: Pekka Paalanen To: Daniel Vetter Cc: Alex Deucher , Simon Ser , Laurent Pinchart , Jernej Skrabec , Laurent Pinchart , Jonas Karlman , Neil Armstrong , Kieran Bingham , Maling list - DRI developers , "open list:DRM DRIVERS FOR RENESAS" , Andrzej Hajda , Thomas Zimmermann , Sam Ravnborg Subject: Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state Message-ID: <20200625133157.0e749602@eldfell> In-Reply-To: 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> <20200625075655.GC3278063@phenom.ffwll.local> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/GHvRnnZvcYp.p3ts9in0XWh"; protocol="application/pgp-signature" Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org --Sig_/GHvRnnZvcYp.p3ts9in0XWh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 25 Jun 2020 09:57:44 +0200 Daniel Vetter wrote: > On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote: > > > > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote: =20 > > > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote= : =20 > > > > > > > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher wrote: =20 > > > > > > > > > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter w= rote: =20 > > > > > > > > > > > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrot= e: =20 > > > > > > > Hi Sam, > > > > > > > > > > > > > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:= =20 > > > > > > > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart = wrote: =20 > > > > > > > > > The DRM CRTC helpers add default modes to connectors in t= he connected > > > > > > > > > state if no mode can be retrieved from the connector. Thi= s behaviour 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 = retrieved and > > > > > > > > > is reported as connector_status_unknown. > > > > > > > > > > > > > > > > > > Extend the addition of default modes to connectors in an = unknown state > > > > > > > > > to support outputs that can retrieve neither the modes no= r the > > > > > > > > > connection status. > > > > > > > > > > > > > > > > > > Signed-off-by: Laurent Pinchart =20 > > > > > > > > > > > > > > > > From your description sounds like an OK approach. > > > > > > > > But this is not something I feel too familiar with. > > > > > > > > Acked-by: Sam Ravnborg =20 > > > > > > > > > > > > > > Thanks for the ack. I'd like to have Daniel's (CC'ed) feedbac= k on this > > > > > > > too. =20 > > > > > > > > > > > > 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 p= retty much > > > > > > limited to old VGA and similar things where load detect somehow= isn't well > > > > > > supported by the hw. > > > > > > > > > > > > Reviewed-by: Daniel Vetter > > > > > > =20 > > > > > > > =20 > > > > > > > > > --- > > > > > > > > > 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= _modes(struct drm_connector *connector, > > > > > > > > > if (count =3D=3D 0 && connector->status =3D=3D connecto= r_status_connected) > > > > > > > > > count =3D drm_add_override_edid_modes(connector= ); > > > > > > > > > > > > > > > > > > - if (count =3D=3D 0 && connector->status =3D=3D connecto= r_status_connected) > > > > > > > > > + if (count =3D=3D 0 && (connector->status =3D=3D connect= or_status_connected || > > > > > > > > > + connector->status =3D=3D connector_s= tatus_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/i= nclude/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= retrieved in the > > > > > > > > > * probe callback somewhere in the driver-private conne= ctor structure. > > > > > > > > > * In this function drivers then parse the modes in the= EDID and add > > > > > > > > > - * them by calling drm_add_edid_modes(). But connectors= that driver a > > > > > > > > > + * them by calling drm_add_edid_modes(). But connectors= that drive a > > > > > > > > > * fixed panel can also manually add specific modes usi= ng > > > > > > > > > * drm_mode_probed_add(). Drivers which manually add mo= des should also > > > > > > > > > * make sure that the &drm_connector.display_info, > > > > > > > > > * &drm_connector.width_mm and &drm_connector.height_mm= fields are > > > > > > > > > * filled in. > > > > > > > > > * > > > > > > > > > + * Note that the caller function will automatically add= standard VESA > > > > > > > > > + * DMT modes up to 1024x768 if the .get_modes() helper = operation returns > > > > > > > > > + * no mode and if the connector status is connector_sta= tus_connected or > > > > > > > > > + * connector_status_unknown. There is no need to call > > > > > > > > > + * drm_add_edid_modes() manually in that case. =20 > > > > > > > > > > > > Hm calling drm_add_edid_modes if you have no edid is a bit a fu= nny idea > > > > > > ... Personally I'd just leave out the last sentence, I think th= at only > > > > > > confuses readers. Or I'm not grasphing what you're trying to te= ll here. =20 > > > > > > > > > > IIRC, some drivers used and desktop environments expected unknown > > > > > rather than off for LVDS/eDP panels when the lid was shut or if t= he > > > > > mux was switched to another device in the case of hybrid laptops.= =20 > > > > > > > > We seem to have totally ditched that in > > > > > > > > commit 05c72e77ccda89ff624108b1b59a0fc43843f343 > > > > Author: Ville Syrj=C3=A4l=C3=A4 > > > > 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. =20 > > > > > > 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. =20 > > > > 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, Simo= n, > > Pekka? =20 >=20 > Actually adding Simon and Pekka this time around ... I don't know what anyone else does, but Weston (is not a DE) does not look at any lid switch, and assumes that if connector status is not DRM_MODE_CONNECTED, then it is disconnected. So, if a driver switched to "Unknown" status, it would be taken as disconnected. I never knew what "Unknown" was relevant for. In weston.ini you can also force a connector on, so users could drive it regardless. However, I would also say that Weston is not supposed to react to any lid action exactly because it does not watch the lid switch. Personally I would expect a built-in screen to stay on even if lid closed. Panels that are always connected showing up as always connected, sounds good to me. Thanks, pq --Sig_/GHvRnnZvcYp.p3ts9in0XWh Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAl70fR0ACgkQI1/ltBGq qqfGNg/8CtPsg3U7yyKbu3BTB88AaPc4oEEWAWlAI/ZCOXznnXDCgR7qL6JIRUdp 82IzZfi28Qt+PzRlGlQlqvubk72C9xE801a4x2SPldfQ3TsjfyPw9Y7ZfBEgZmup JDsZo1PdQvBQb+tffTygqR4u+Df1XFfiWcBnHTDlVaKDh/6YPT+ruC0wqTlwT94X y6IxPftPyT4DFIldmr5MphcDUkPC9S5zatVY5n3/IwhzEjWNThvTC2eZCcmS/DGb +sGkmQcUj4KH5qhoPkTJZBsLmauuTSvwEN1PpRMZHCd1ZcFjxfI9LREkkpV1sMp3 UTmLORx6c+9s6lkAD8wGzPz1u1y7yPHpkuMx9KksFdcmLW0L1lYppr3aXUN5YjQ4 XrmD+iw3PBvR/d2mWyOveHcccnXEGdJPPdLWiqXS9bb6WSXbLuKEy2En8In/naza BSoBGEJXamXm0L0uRF1TOo4wMoqYUEO3F60Xbu+QAB74p8Pe1TPS/JqnJiWlnqep r3626Dv0qQ1hzhzxDV1pnsZ8wEAC8ctI9AaO2/Vu8PfpBJwi+nTWPcFyNpFYRbRz j+jTIFaBT3xzCeOcxYsm2rWrSE2ipAIBY0yg8YQPTdbHYZh2NPKOKBF4W1C++2Za qYKsDDYfYPObbm0mQB/64ds9lVF4iTzTw5xtqZlL3jfj3HnUr6A= =xrVP -----END PGP SIGNATURE----- --Sig_/GHvRnnZvcYp.p3ts9in0XWh--