, On Wed, 15 Jan 2020 at 15:52, Laszlo Ersek <ler...@redhat.com> wrote: > > On 01/15/20 14:02, Ard Biesheuvel wrote: > > On Wed, 15 Jan 2020 at 13:50, Laszlo Ersek <ler...@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 ... -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53278): https://edk2.groups.io/g/devel/message/53278 Mute This Topic: https://groups.io/mt/69714171/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
