Re: [edk2] EFI_CONSOLE_CONTROL_PROTOCOL in OvmfPkg / grub2

[Laszlo Ersek]

On 10/01/12 22:16, Andrew Fish wrote:
> 
> On Oct 1, 2012, at 11:08 AM, Laszlo Ersek wrote:

>> Or maybe I mis-attributed the blame to grub_efi_set_text_mode()...

Yes, I think I was wrong about it. "Welcome to GRUB!" is printed after
grub_machine_init() (and hence grub_efi_set_text_mode()) returns. I
recall one occasion when I started the guest right after host boot, and
the guest boot was slow enough that I could read the welcome banner
correctly rendered for a split second. So whatever distorts the screen
comes after the welcome message, and thus it can't be called fom
grub_machine_init().

> I was guessing it was just a bug in grub if
> EFI_CONSOLE_CONTROL_PROTOCOL was not implemented on a platform as the
> screen behavior is different in the two cases:

> 1) EFI_CONSOLE_CONTROL_PROTOCOL in graphics mode

> Writes to the EFI console do not go to the graphics screen , but
> writes to non-graphics consoles still go through.

> 2) No EFI_CONSOLE_CONTROL_PROTOCOL

> All writes go through to the graphics screen at all times.
> 
> The other question is the "glitch" text being drawn to the screen?

It looks like
<http://people.redhat.com/~lersek/Screenshot-fw-ovmf.g-f18xfcealpha.e-rhel63%20Virtual%20Machine.png>.
The text with the highlighted background is "Welcome to GRUB!"

> If
> so then it could be related to EFI_CONSOLE_CONTROL_PROTOCOL not being
> present. The other thing that can cause glitches is mode changes, so
> look for calls to EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() in Grub for
> that.

Yes, I think it's case (2) and we'll probably have to look for the
problem elsewhere.


> I also wonder if the "glitches" look worse on QEMU as the graphics
> speeds could be slower than a real platform?

I have only seen it on qemu. Although I didn't look elsewhere, I think
it doesn't apply to real hardware -- people test grub2-efi on real
hardware regularly, and I think the problem would have been caught /
fixed there already.

Thanks!
Laszlo