Re: [RFC PATCH] ArmPkg/PlatformBmLib: defer GOP console discovery after Driver#### dispatch

["Ard Biesheuvel" <ard.biesheuvel@linaro.org>]

,

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 ...