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

[Daniel Vetter]

On Fri, Jun 26, 2020 at 10:25:45AM +0100, Daniel Stone wrote:
> Hi,
> 
> On Fri, 26 Jun 2020 at 10:00, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Thu, 25 Jun 2020 12:44:36 +0200 Daniel Vetter <daniel at ffwll.ch> wrote:
> > > Maybe an aside, but the guideline is for autoconfiguration:
> > > - Light up everything that has connector status connected.
> > > - If nothing has that status, try to light up the connectors with
> > > status "unknown".
> > >
> > > This is only really relevant on older platforms, mostly for VGA and
> > > somewhat for dvi outputs.
> > >
> > > Maybe another thing we should put down somewhere in the uapi docs ...
> >
> > As I had no idea what "unknown" means or when it can happen, I assumed
> > that it must mean "the hardware cannot know". If the hardware cannot
> > know, then I certainly will not be trying to enable that, unless
> > explicitly configured to do so. Having a phantom output is worse than
> > having a real output that does not light up, because it's not obvious at
> > first with phantom output that anything is wrong. You may just be
> > wondering where your windows disappear, or where did you mouse cursor
> > go, or why you see a wallpaper but no login dialog, etc.
> 
> How about a refinement of Dan's suggestion, proceeding down this
> logical order and breaking if true:
> - ignore all disconnected outputs
> - if any outputs are connected, ignore all unknown outputs
> - if only one output is unknown, use only that output (with default
> mode if need be)
> - if any outputs are unknown but have EDID present, use only those outputs
> - at this point, we have multiple unknown outputs with no EDID - break
> and demand explicit user configuration

EDID present generally means the status will be "connected". So not much
of a refined.

I'd say if you have multiple unknown, use a cloned config to avoid the
"windows are disappearing" problem. Which is also what fbcon does, and
iirc also -modesetting by default.

But the most important part is to not light up "unknown" outputs if
there's another output with a solid "connected". That avoids the problems
Pekka points out, phantom outputs are bad. Really no need to refine beyond
that, since imo that's a kernel bug.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch