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