Re: [edk2] EFI_CONSOLE_CONTROL_PROTOCOL in OvmfPkg / grub2

[Andrew Fish]

On Oct 1, 2012, at 11:08 AM, Laszlo Ersek wrote:

> Hello Andrew,
> 
> On 10/01/12 17:19, Andrew Fish wrote:
> 
>> It is OK for Grub to check for the EFI_CONSOLE_CONTROL_PROTOCOL and
>> set the system into a text mode if that is required. For example Macs
>> support console control and boot with it in graphics (only) mode. So
>> it seems like the bug is in handling systems that don't support
>> EFI_CONSOLE_CONTROL_PROTOCOL, and that path needs to get cleaned up.
>> Hopefully the OVMF will make it much easier to work on grub EFI
>> support.
> 
> That's the strange thing; if grub_efi_locate_protocol() fails to find
> EFI_CONSOLE_CONTROL_PROTOCOL in grub_efi_set_text_mode(), it simply
> returns. It looks as if the protocol were located (which is surprising
> because it's not part of the OVMF build) and then SetMode() did the
> wrong thing.
> 
> Or maybe I mis-attributed the blame to grub_efi_set_text_mode()...
> 

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

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


Thanks & good luck,

Andrew

> Thank you!
> Laszlo