Bug#1146562: Please return efi_uga.mod to x86_64-efi grub

[Mikhail Ryazanov]

Mate, you apparently forgot to CC your last reply to the bugs.debian.org 
address, so I'm leaving the full quote here (see my reply below it):

On 2026-09-08 03:01, Mate Kukri wrote:
> All text modes work fine on the non-Apple UEFI computers I have tested
> on, ranging from 2010 to brand new.
> On those, GRUB sets the mode using the EFI text output protocol
> without the non-standard "console control protocol" and it works fine.
> (This is how reading the firmware standard and edk2 code would make
> you expect it to behave).
> 
> It seems like on the Apple device in question, beyond setting the
> specific text mode via the EFI text output protocol, an _additional_
> call to this console control protocol is required to switch it from
> graphics to text output (which is not something the firmware standard
> requires). This is not required by EDKII code or the plain text of the
> firmware standard.
> This still needs to be confirmed, as 2019 firmware is suspiciously too
> new to require this (I have known about this being required
> on 2006 era EDK), there could be a different bug in play.
> 
> At this point I do not believe text mode is broken by this change on
> non-Apple Hardware, but I would be happy to be proven wrong.

I did test 2.14-3 on my non-Apple PC, and "terminal_output console" does 
work there (although see below). So yes, it seems that this is 
specifically an Apple issue.

To confirm, I've downloaded the source package 
("grub2_2.14-3.debian.tar.xz" and "grub2_2.14.orig.tar.xz") and built it 
locally (required minor tweaking for gcc-16). It reproduced the behavior 
that I've observed with the binary package.

Then I've partially reverted the parts related to console in 
"efi-Drop-support-for-UGA-Draw-and-Console-Control-protoco.patch", 
rebuilt and tested again. This made "terminal_output console" working on 
MacBook again (without breaking it on non-Apple PC), which proves that 
those parts are indeed needed at least for that particular MacBook 
model. They are quite small, and I don't think that keeping them in GRUB 
will harm, so please return them to 2.14 and Debian and to 2.16 upstream.

During all these tests, I've also noticed some other bugs not directly 
related to the patch in question (they are present in both 2.14-1 and 
2.14-3), but presumably indicating some problems with GRUB terminal 
initialization, so I'll mention them here because maybe that call to the 
Console Control protocol on Apple is not really needed but just 
circumvents some missing steps.

1. After switching the GRUB terminal from "console" to "gfxterm" and 
back to "console", the cursor becomes invisible. On both MacBook and 
non-Apple PC.

On MacBook, GRUB can actually be started in the "gfxterm" mode, then 
"terminal_output console" works fine (shows visible cursor) the first 
time, but subsequent switching hides the cursor in the "console" mode.

On non-Apple PC, the only possibility to see the cursor in the "console" 
mode is to start GRUB in that mode.

However, the "gfxterm" mode always has a visible cursor, so I suspect 
that there is something wrong in setting the cursor for "console".

2. Running "videotest" from the "gfxterm" mode leaves the system 
visually unresponsive.

On non-Apple PC, running "videotest" from the "console" mode works fine 
(pressing any key return to the terminal and prints some information 
about colors). Running from the "gfxterm" mode requires pressing any key 
and then blindly executing "terminal_output console" to see anything.

On MacBook, even running from the "console" mode does not return 
properly, requiring blindly switching the terminal_output mode in any case.

Executing "clear" does not help. Executing "terminal_output" with the 
current mode also does not help (probably just skips the 
initialization). So it seems that "videotest" cannot restore the 
video/terminal mode properly, and manually changing the terminal_output 
mode is required.

(It also would be nice if "videotest" would show "Press any key to 
continue". Because currently it is unclear whether it is supposed to 
"hang" and require rebooting or is just buggy.)