From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65])
 by mx.groups.io with SMTP id smtpd.web12.8122.1579100315667580899
 for <devel@edk2.groups.io>;
 Wed, 15 Jan 2020 06:58:36 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@linaro.org header.s=google header.b=UhhoL8BR;
 spf=pass (domain: linaro.org, ip: 209.85.221.65, mailfrom: ard.biesheuvel@linaro.org)
Received: by mail-wr1-f65.google.com with SMTP id q6so15988252wro.9
        for <devel@edk2.groups.io>; Wed, 15 Jan 2020 06:58:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=RQy5WqeP/3Qy4yUIQrMy8IL74b+h7sDfIka/BimorWg=;
        b=UhhoL8BRParAlvR+VWGX43TM7PfQ/9IE2keyIuvC4zekX36vnWHIC19xZC8BfhnC/Z
         MXvKks2QfmGofx2Z0QWa3z3cAVpbXTN0ktWf2PixLezdzEjjwz3HX5UGCuP7VBf9ZLLg
         L9NSjZBShrCAmOdi4dAgMFKr/4GTt7KjkdgiXFZF7IH7emPSYY5gFMtEF9Poj471ktZG
         9Fe7hzbZZoQkyfh7y+BO3SXnar65thFBbNYAVtfcvxq9Bs5LSDApT7ncGnUJcuXIfAdv
         BHo6IqSvj20RPaxKOeB7XoYKiMmxCxR0FvjxEs7NvEsBCvPOE78ttkh4YVyCUNyfOgzG
         PA1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=RQy5WqeP/3Qy4yUIQrMy8IL74b+h7sDfIka/BimorWg=;
        b=cegt3OgPUB6ERke5Z264wI53rBYG7fw0PiGwWvnjALjmN+R82V46b6mljaie0gIjD2
         6+fJNtX6XDR/nBK3JjXYbxCjPBfGvXcl+sHyHH9YFwhACAxSDEgeRU6zYIVFKXm3T+eE
         DkUHtuEX3CAmBAkGwhkAnYdME2sVtj9cnbh/18PL6VYmtDai5xykzWYYMsnPZ2g8l5Pb
         RcYyjRQilLWKKQOi0V5JFYoLTH2xhncGCMFNX/iL6AV36S5yWX9N395agutKWpzQ2wVA
         dKbUstRO92T23O8RaL795pDPURa85TnA2vta8DAsxSQAD3PLp0Tt0YG/FPEhI8uFT+19
         C4yw==
X-Gm-Message-State: APjAAAVwZ0wh5zLlUY7bzrvAuQ6QVjnEA1rHr0gYaN2zLY3BBAeDYJLK
	praHJzv1EY1kOlZ4DzjMTxgANXo30nMEmTkpLJpAUw==
X-Google-Smtp-Source: APXvYqyDAQYIU9MbBNoL1FRSn/W+IdGWGbtORik6rUouKDWQtovaEKOIDPx47zvPou9Sudneg7/4cO4vDD1zaPKxRrE=
X-Received: by 2002:a5d:6652:: with SMTP id f18mr14947443wrw.246.1579100314132;
 Wed, 15 Jan 2020 06:58:34 -0800 (PST)
MIME-Version: 1.0
References: <20200115102217.3027-1-ard.biesheuvel@linaro.org>
 <23a9be06-791f-517a-ccd4-fd36c93af8b0@redhat.com> <CAKv+Gu-9mge0UXh6-OdJ_iw1Yf1F57ayDy_6q03SRU9nzzVzWA@mail.gmail.com>
 <c4d2beef-7e4a-aec9-65b2-aa3f5b746ab4@redhat.com>
In-Reply-To: <c4d2beef-7e4a-aec9-65b2-aa3f5b746ab4@redhat.com>
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
Date: Wed, 15 Jan 2020 15:58:22 +0100
Message-ID: <CAKv+Gu_ZnJ0SKmXXMPeMEvTK56XnF07ej4o1_MaM48_PJvsEmA@mail.gmail.com>
Subject: Re: [RFC PATCH] ArmPkg/PlatformBmLib: defer GOP console discovery after Driver#### dispatch
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>, Leif Lindholm <leif.lindholm@linaro.org>, 
	"Ni, Ray" <ray.ni@intel.com>, Andrew Fish <afish@apple.com>
Content-Type: text/plain; charset="UTF-8"

,

On Wed, 15 Jan 2020 at 15:52, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 01/15/20 14:02, Ard Biesheuvel wrote:
> > On Wed, 15 Jan 2020 at 13:50, Laszlo Ersek <lersek@redhat.com> wrote:
>
> >> (3) So how about the following approach:
> >>
> >> (3a) factor the following sequence:
> >>
> >>   FilterAndProcess (&gEfiPciIoProtocolGuid, IsPciDisplay, Connect);
> >>   FilterAndProcess (&gEfiGraphicsOutputProtocolGuid, NULL, AddOutput);
> >>
> >> out to a helper function,
> >>
> >> (3b) call the extracted sequence in *both* its current place, *and* at
> >> the top of PlatformBootManagerAfterConsole() (instead of
> >> EfiBootManagerConnectVideoController())?
> >>
> >> ?
> >>
> >> I expect this should give you *some* consoles in BeforeConsole() (on
> >> such PCI and non-PCI graphics controllers whose drivers are in the
> >> platform firmware), just to be safe; and *all* the rest would be picked
> >> up in AfterConsole().
> >>
> >
> > I wonder whether there is a point to doing it twice, regardless of
> > whether we are talking about PCI or non-PCI. I experimented with just
> > moving those calls to AfterConsole(), and I get basically the same
> > behavior as with this patch.
>
> Looking at BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c],
> admittedly quite little happens between the calls to
> PlatformBootManagerBeforeConsole() and PlatformBootManagerAfterConsole().
>
> What if a UEFI driver, loaded from a Driver#### option, prints a message
> to the UEFI console, in its entry point function? Do we want such
> messages to appear on platform framebuffers?
>
> ... Hmmm, I felt that the Driver Writer's Guide spoke some words on
> this, and indeed. In 3.15.3 "Connecting consoles", the Note at the end
> includes the following sentence:
>
>     UEFI Drivers should never directly access console devices except for
>     the few UEFI driver related services that explicitly allow user
>     interaction. In most cases, UEFI drivers use HII infrastructure to
>     present information to users.
>
> I don't know what those "few UEFI driver related services" are supposed
> to be "that explicitly allow user interaction". So with the (somewhat
> incomplete) information I seem to have, I must agree that simply moving
> those two function calls should be safe enough.
>

I suppose the main occurrence between BeforeConsole() and
AfterConsole() is the invocation of
EfiBootManagerConnectAllDefaultConsoles(), which updates the system
table with the new values of ConIn, ConOut etc. It looks like that
/should/ matter, but in my testing, connecting the GOP driver after
that still yields a working graphical console, so I'm not sure I
understand what's going on here ...