[PATCH 27/27] drm: Add default modes for connectors in unknown state

Thu Jun 25 10:31:57 UTC 2020

On Thu, 25 Jun 2020 09:57:44 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:  
> > > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter <daniel at ffwll.ch> wrote:  
> > > >
> > > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher <alexdeucher at gmail.com> wrote:  
> > > > >
> > > > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter <daniel at ffwll.ch> 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 wrote:  
> > > > > > > > > The DRM CRTC helpers add default modes to connectors in the connected
> > > > > > > > > state if no mode can be retrieved from the connector. This 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 nor the
> > > > > > > > > connection status.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>  
> > > > > > > >
> > > > > > > > From your description sounds like an OK approach.
> > > > > > > > But this is not something I feel too familiar with.
> > > > > > > > Acked-by: Sam Ravnborg <sam at ravnborg.org>  
> > > > > > >
> > > > > > > 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 pretty much
> > > > > > limited to old VGA and similar things where load detect somehow isn't well
> > > > > > supported by the hw.
> > > > > >
> > > > > > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > > > >  
> > > > > > >  
> > > > > > > > > ---
> > > > > > > > >  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 == 0 && connector->status == connector_status_connected)
> > > > > > > > >           count = drm_add_override_edid_modes(connector);
> > > > > > > > >
> > > > > > > > > - if (count == 0 && connector->status == connector_status_connected)
> > > > > > > > > + if (count == 0 && (connector->status == connector_status_connected ||
> > > > > > > > > +                    connector->status == connector_status_unknown))
> > > > > > > > >           count = drm_add_modes_noedid(connector, 1024, 768);
> > > > > > > > >   count += drm_helper_probe_add_cmdline_mode(connector);
> > > > > > > > >   if (count == 0)
> > > > > > > > > diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/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 connector 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 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 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_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 only
> > > > > > confuses readers. Or I'm not grasphing what you're trying to tell here.  
> > > > >
> > > > > 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älä <ville.syrjala at linux.intel.com>
> > > > 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?  
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200625/2dca4c96/attachment.sig>