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

[Mate Kukri]

Is 'terminal_output console' in your grub.cfg because you have
modified /etc/default/grub because you _want_ text mode console? If
you do want graphics mode (which is the default) then the config is
generated wrong and that is a bug. If you manually changed to text
mode I would have liked at least a mention of that.

Unfortunately it seems, this device when manually set to text mode,
will not render text without the console control protocol call (even
despite it not using UGA Draw). This behavior was not missed because I
am some reckless destroyer (as the unfortunate tone of your last email
suggests), but because it is completely non-standard, and not present
in the firmware of any non-Apple consumer device manufactured in the
last 20 years.  I unfortunately do not have a hardware museum at home
to discover that Apple unfortunately carried this relic forward to the
Retina era. I dropped it under the impression that only early UGA Draw
Intel Macs require it, but looks like that was mistaken.

Regardless, this device should still be entirely functional in the
default graphics mode configuration, and yes the small font is a
limitation on every device with a HiDPI screen (including the ones I
have), it is not a specific bug.

I would be tempted to re-instate just the console control protocol
(UGA Draw still remaining dropped), to support the edge case of
slightly newer Apple devices combined with text mode noting that it is
non-standard and old, but that Apple carried it forward way too far.

Regards,
Mate Kukri

P.S. Open source maintainers need to have the ability to drop
deprecated features they do not have the ability to test, calling that
"formalism" and sending emails of such unfortunate tone to a bug
tracker is not going to change that, but it will result in fewer
people wanting to maintain open source software.

On Sat, Sep 5, 2026 at 9:28 PM Mikhail Ryazanov
<mikhail.ryazanov at jila.colorado.edu> wrote:
>
> I was expecting more interest and participation in finding the real
> problem, but unfortunately had to dig this myself. Here are some
> important updates.
>
> I've downloaded the version 2.14-1 from snapshot.debian.org and
> confirmed that it works fine. Further tests also confirmed my previous
> suspicion that the problem is not in the efi_uga removal (actually, my
> system uses GOP, and it works), but nevertheless seems to be associated
> with the same patch.
>
> Namely in 2.14-3, the command "terminal_output console" brings the
> system to a state when GRUB thinks that it works in the text mode, but
> the display is actually not switched to the text mode, so all GRUB
> output goes nowhere, leaving the screen stuck (in my case, blank because
> "terminal_output console" was in grub.cfg before any output). Blindly
> typing "terminal_output gfxterm" makes GRUB usable (supposedly, if
> necessary video modules were loaded).
>
> So, removing "console" from the GRUB configuration made 2.14-3 usable,
> although quite poorly, as that MacBook has a high-resolution screen
> ("Retina"), on which the default GRUB font is very tiny (line height <
> 2 mm). "videoinfo" shows that only the native resolution is supported,
> so changing "gfxmode" does not help. The only solution that I've found
> was to load a larger font (finding a reasonable font file that will work
> with grub-mkfont was another quest). However, GRUB_FONT in
> /etc/default/grub is not documented and apparently does not work
> properly, so I had to edit grub.cfg manually and will need to do so
> every time...
>
> Interestingly, "efitextmode" still works in 2.14-3, showing available
> text modes and allows selecting among them. But because their
> initialization has been removed from grub_prepare_for_text_output(),
> nothing really works.
>
> I've also tested that "terminal_output console" works in 2.12-9 even on
> the newest PC (made this year), so my opinion is that the decision to
> "drop support for ... Console Control" was a mistake. However, if you
> prefer formalism ("Console Control protocol was an implementation detail
> of the deprecated Intel EDK") over real-world usability, please then
> remove it _completely_ and document this breaking change accordingly,
> because the current behavior is very confusing and frustrating (from the
> user perspective; and keeps the code in a highly inconsistent state,
> from the developer side).
>