[PATCH] efi: Set text-mode console resolution to maximum supported

[PATCH] efi: Set text-mode console resolution to maximum supported

[Glenn Washburn]

On some buggy EFI firmwares, GRUB is started with the console resolution
set to the maximum but the output console EFI object has the mode set as
0, which is the minimum supported mode of 80x25 characters. This causes
strange behavior at the GRUB shell where output can fill the screen, but
the prompt is at line 80 in the middle of the screen.

When initializing the EFI console, find the largest console resolution
supported by area and set that as the current output mode. This works around
the buggy firmware and provides a GRUB shell that displays correctly.

Signed-off-by: Glenn Washburn <development@efficientek.com>
---
 grub-core/term/efi/console.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/grub-core/term/efi/console.c b/grub-core/term/efi/console.c
index a3622e4fe..06da5548f 100644
--- a/grub-core/term/efi/console.c
+++ b/grub-core/term/efi/console.c
@@ -141,6 +141,10 @@ grub_console_setcursor (struct grub_term_output *term __attribute__ ((unused)),
 static grub_err_t
 grub_prepare_for_text_output (struct grub_term_output *term)
 {
+  grub_efi_simple_text_output_interface_t *o;
+  grub_efi_uintn_t columns, columns_max, rows, rows_max;
+  grub_efi_int32_t i, mode_max;
+
   if (grub_efi_is_finished)
     return GRUB_ERR_BAD_DEVICE;
 
@@ -155,6 +159,16 @@ grub_prepare_for_text_output (struct grub_term_output *term)
       return GRUB_ERR_BAD_DEVICE;
     }
 
+  /* Set text-mode resolution to maximum supported */
+  o = grub_efi_system_table->con_out;
+  for (i=0, columns_max=0, rows_max=0, mode_max=0; i < o->mode->max_mode; i++)
+    if (GRUB_EFI_SUCCESS == efi_call_4 (o->query_mode, o, o->mode->mode,
+                                       &columns, &rows)
+       && (columns_max * rows_max) < (columns * rows))
+      mode_max = i;
+
+  efi_call_2 (o->set_mode, o, mode_max);
+
   if (cursor_mode != GRUB_CURSOR_MODE_UNDEFINED)
     grub_console_setcursor (term, cursor_mode);
   if (text_colorstate != GRUB_TERM_COLOR_UNDEFINED)
-- 
2.34.1

Re: [PATCH] efi: Set text-mode console resolution to maximum supported

[Gerd Hoffmann]

  Hi,

> On some buggy EFI firmwares, GRUB is started with the console resolution
> set to the maximum but the output console EFI object has the mode set as
> 0, which is the minimum supported mode of 80x25 characters. This causes
> strange behavior at the GRUB shell where output can fill the screen, but
> the prompt is at line 80 in the middle of the screen.

This behavior might not be ideal, but it's clearly within the specs and
not buggy.  What firmware do you talk about btw?

> +  /* Set text-mode resolution to maximum supported */
> +  o = grub_efi_system_table->con_out;
> +  for (i=0, columns_max=0, rows_max=0, mode_max=0; i < o->mode->max_mode; i++)
> +    if (GRUB_EFI_SUCCESS == efi_call_4 (o->query_mode, o, o->mode->mode,
> +                                       &columns, &rows)
> +       && (columns_max * rows_max) < (columns * rows))
> +      mode_max = i;
> +
> +  efi_call_2 (o->set_mode, o, mode_max);

This is buggy.  It find the last entry in the mode list.  Which works by
pure luck because that happens to be the entry you want have in case the
list is sorted.

take care,
  Gerd

Re: [PATCH] efi: Set text-mode console resolution to maximum supported

[Glenn Washburn]

Hi Gerd,

Thanks for taking a look at the patch.

On Fri, 6 May 2022 12:39:52 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > On some buggy EFI firmwares, GRUB is started with the console resolution
> > set to the maximum but the output console EFI object has the mode set as
> > 0, which is the minimum supported mode of 80x25 characters. This causes
> > strange behavior at the GRUB shell where output can fill the screen, but
> > the prompt is at line 80 in the middle of the screen.
> 
> This behavior might not be ideal, but it's clearly within the specs and
> not buggy.  What firmware do you talk about btw?

I have only a cursory understanding of the spec and fairly new to EFI.
Could you elaborate on which spec(s) and where this behavior is
described? 

Trying to make sense of your assertion, my inexperienced reading of
some relevant (but perhaps not all relevant) portions of the spec lead
me to conclude that this behavior may not violate the spec because the
spec isn't very clear on this. For instance, looking at the UEFI 2.9
version of the spec in section 12.4 on page 454 in table 12-4 "EFI
Cursor Location/Advance Rules" there is reference to "bottom of the
display". What is the display? Does being in a particular "mode" of
cols x rows dimensions encompass all the pixels of the physical screen?
If it doesn't, is the display all the pixels or just the ones being
used for the columns x rows character output of a particular mode?
Suppose that the display is just the pixels used by the particular
mode, then this firmware violates the spec by allowing LF characters to
advance the cursor past the end of the "display" and allow writing of
GRUB generated output there. On the other hand, if the "display" is all
pixels on the screen and the text mode may be a sub-rectangle of that,
then OutputString allows writing outside of the columns x rows of a
given mode, ie for the purposes of the cursor advance rules the firmware
is considering the whole screen as the display but SetCursorPosition()
is limited to a top-left section of the screen. So what would be the
point of having that behavior? Just to limit SetCursorPosition() to a
subset of the screen? May be you can enlighten me on the wisdom of
the spec here (are there some types of hardware displays where this is
useful?).

Another place the spec isn't clear is in section 2.4 at the end of page
450, it says "If the output device is not in a valid text mode at the
time of the EFI_BOOT_SERVICES.HandleProtocol() call, the device is to
indicate that its CurrentMode is –1". But nowhere in the spec is
"CurrentMode" defined and a search of the PDF shows that as the only
instance of that string. If I were a betting person, I'd put my money
on "CurrentMode" being the "Mode" member of the struct defined above, or
ConsoleOut->Mode->Mode. It seems to me this is a bug/ambiguity in the
spec.

Looking at the last paragraph on 450 and assuming my guess above as to
the meaning of "CurrentMode", which I could be wrong about, I considered
that the paragraph could be used to justify this behavior. However,
ConsoleOut->Mode->Mode == 0, not -1. So the console should be in 80x25
mode (which is kinda is). Its not clear to me that this is relevant
either because GRUB only ever calls EFI_BOOT_SERVICES.HandleProtocol()
on ia64 (not my architecture). So how does GRUB know whether ConsoleOut
is in a valid mode or not? Do we need to call HandleProtocol() on the
ConsoleOutHandle to trigger this? I would think not since ConOut is
support to already be a handle to this interface.

To be more verbose as to the issue I'm seeing, the computer boots to
GRUB with the display resolution at native, 1920x1080, but only uses
what appears to be the top left 800x600 pixels for the 80x25 text mode
_initially_. So running "lsmod", for instance, uses the full height of
the screen when outputing text and the screen starts scrolling at the
bottom of the screen. But when it finished the GRUB shell prompt is
about midway down from the top and typing overwrites some of lsmod
output. Then further output gets mangled with the previous output.
Going to a grub menu interface clears the screen, so I end up having to
exit the shell and re-enter it to get a non-mangled display. A video of
this would be worth million words.

If I set the mode to some other mode and then back to mode 0, which is
the mode its claims to start up in, then there appears to be a screen
resolution change to 640x480 with accompanying giant font with the
screen centered now instead of in the top left corner of the display.
I've yet to figure out a way to get the display back into the weird,
spec-compliant, mode that it starts out in. So if this is some
desirable mode, why can't I get back in to it? And why does it only
happen for default boot entries?

In my case, my firmware behavior seems like a clear bug, I have a hard
time believing that HP firmware devs would chose this behavior. Whether
it violates the spec or not is a separate issue (there can be bugs that
do not violate the spec). I've only seen this undesirable behavior only
manifest when booting a default boot entry. When I choose via the
firmware boot selection screen an EFI app to run and run the same GRUB
EFI app that exhibits the issue when run from default boot selection,
this does not manifest. I get the same behavior for the EDK2 EFI shell
app when it is used as the default boot app. Whether its called a bug
or spec-compliant mis-feature, the important point is that this is
undesirable behavior for GRUB users.

I considered that this may have to do with ConsoleOut and StandardError
being in different modes. It seems like this might be caused by
StandardError being in the maximum mode and ConsoleOut being in the
minimum mode, but it turns out that EFI_BOOT_SERVICES.StdErr is NULL.
This seems to violate the descriptions of StandardErrorHandle
and StdErr in section 4.3, page 95. Changing the mode of ConsoleOut and
not StandardError does nothing but improve the display out.

I'm also curious if anyone has seen issues with the largest area text
mode mode. Is there a problem with doing that this patch intends?
Ultimately, I think it would be nice to have a key sequence that
raises and lowers the mode so that if the largest mode is not usable
for some reason, the user has a blind way out. I've created another
patch to add a command called efitextmode, which is very similar to the
EFI Shell's "mode" command. But that doesn't solve the issue just
mentioned.

The firmware I'm looking at is from Hewlett-Packard for a Zbook G2 15.

> > +  /* Set text-mode resolution to maximum supported */
> > +  o = grub_efi_system_table->con_out;
> > +  for (i=0, columns_max=0, rows_max=0, mode_max=0; i < o->mode->max_mode; i++)
> > +    if (GRUB_EFI_SUCCESS == efi_call_4 (o->query_mode, o, o->mode->mode,
> > +                                       &columns, &rows)
> > +       && (columns_max * rows_max) < (columns * rows))
> > +      mode_max = i;
> > +
> > +  efi_call_2 (o->set_mode, o, mode_max);
> 
> This is buggy.  It find the last entry in the mode list.  Which works by
> pure luck because that happens to be the entry you want have in case the
> list is sorted.

Yep, thanks, there's a reason that coding while driving is illegal in
many localities.

Glenn

Re: [PATCH] efi: Set text-mode console resolution to maximum supported

[Gerd Hoffmann]

On Fri, May 06, 2022 at 07:59:15PM -0500, Glenn Washburn wrote:
> Hi Gerd,
> 
> Thanks for taking a look at the patch.
> 
> On Fri, 6 May 2022 12:39:52 +0200
> Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> >   Hi,
> > 
> > > On some buggy EFI firmwares, GRUB is started with the console resolution
> > > set to the maximum but the output console EFI object has the mode set as
> > > 0, which is the minimum supported mode of 80x25 characters. This causes
> > > strange behavior at the GRUB shell where output can fill the screen, but
> > > the prompt is at line 80 in the middle of the screen.
> > 
> > This behavior might not be ideal, but it's clearly within the specs and
> > not buggy.  What firmware do you talk about btw?
> 
> I have only a cursory understanding of the spec and fairly new to EFI.
> Could you elaborate on which spec(s) and where this behavior is
> described? 

Well, 80x25 is the only text mode which must be supported by the
firmware.  Supporting larger modes is optional.

I think the firmware is also free to choose the default text mode,
and the implementations I've seen so far seem to be conservative
and use 80x25 or 80x50 by default even in case the screen is larger.

> Trying to make sense of your assertion, my inexperienced reading of
> some relevant (but perhaps not all relevant) portions of the spec lead
> me to conclude that this behavior may not violate the spec because the
> spec isn't very clear on this. For instance, looking at the UEFI 2.9
> version of the spec in section 12.4 on page 454 in table 12-4 "EFI
> Cursor Location/Advance Rules" there is reference to "bottom of the
> display". What is the display? Does being in a particular "mode" of
> cols x rows dimensions encompass all the pixels of the physical screen?
> If it doesn't, is the display all the pixels or just the ones being
> used for the columns x rows character output of a particular mode?

Typically text mode uses a windows centered on the GOP.  That is at
least what standared edk2 is doing and also the behavior you can see
when using ovmf in qemu.

> To be more verbose as to the issue I'm seeing, the computer boots to
> GRUB with the display resolution at native, 1920x1080, but only uses
> what appears to be the top left 800x600 pixels for the 80x25 text mode
> _initially_. So running "lsmod", for instance, uses the full height of
> the screen when outputing text and the screen starts scrolling at the
> bottom of the screen. But when it finished the GRUB shell prompt is
> about midway down from the top and typing overwrites some of lsmod
> output.

That sounds buggy indeed.  I've never seen such behavior on a graphical
screen.  It sounds like the behavior I see when using efi shell on a
serial console with the xterm having more lines than efi text mode.

> I'm also curious if anyone has seen issues with the largest area text
> mode mode. Is there a problem with doing that this patch intends?

Hmm, good question.  Can't see problems offfhand, but you never know
what corner cases people run into.

> Ultimately, I think it would be nice to have a key sequence that
> raises and lowers the mode so that if the largest mode is not usable
> for some reason, the user has a blind way out. I've created another
> patch to add a command called efitextmode, which is very similar to the
> EFI Shell's "mode" command. But that doesn't solve the issue just
> mentioned.

Adding a command for that sounds like a better option, it's much easier
for users to deal with it should this cause any problems because you
only need to change the config file, not recompile the bootloader.

The command could also accept 'min' and 'max' as argument (in addition
to specific modes).

take care,
  Gerd

Re: [PATCH] efi: Set text-mode console resolution to maximum supported

[Glenn Washburn]

On Tue, 10 May 2022 13:57:08 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Fri, May 06, 2022 at 07:59:15PM -0500, Glenn Washburn wrote:
> > Hi Gerd,
> > 
> > Thanks for taking a look at the patch.
> > 
> > On Fri, 6 May 2022 12:39:52 +0200
> > Gerd Hoffmann <kraxel@redhat.com> wrote:
> > 
> > >   Hi,
> > > 
> > > > On some buggy EFI firmwares, GRUB is started with the console resolution
> > > > set to the maximum but the output console EFI object has the mode set as
> > > > 0, which is the minimum supported mode of 80x25 characters. This causes
> > > > strange behavior at the GRUB shell where output can fill the screen, but
> > > > the prompt is at line 80 in the middle of the screen.
> > > 
> > > This behavior might not be ideal, but it's clearly within the specs and
> > > not buggy.  What firmware do you talk about btw?
> > 
> > I have only a cursory understanding of the spec and fairly new to EFI.
> > Could you elaborate on which spec(s) and where this behavior is
> > described? 
> 
> Well, 80x25 is the only text mode which must be supported by the
> firmware.  Supporting larger modes is optional.
> 
> I think the firmware is also free to choose the default text mode,
> and the implementations I've seen so far seem to be conservative
> and use 80x25 or 80x50 by default even in case the screen is larger.

That kind of surprises me. When in mode 80x25 or 80x50 is the display
not at its native resolution? For instance, when I put mine into 80x25,
the display is clearly not at its native resolution, and not even the
full physical screen is used, unlike at native resolution. The display
is in a box centered on the physical display and the character glyphs
are much larger and visibly more pixelated. In your experience, are
other firmwares at 80x25 using native resolution or like mine some lower
resolution? My surprise is that firmware authors would want the default
display to look like that (maybe they don't care because its not
considered user-facing). 

Another interesting thing I just found out is that the text is
displayed much faster in 80x25 mode. I have 4 available modes 80x25,
120x36, 128x40, and 240x80 (or there abouts, going off memory). To test
the speed, I'm cating a largish file, and doing a wall clock time. It
seems that speed scales proportionally to the mode area size, maybe
quadratically. So the max mode is much longer than the min mode, like
5-6 times longer. This despite the min mode writing more lines because
of line wrapping. When running with debug=all there are times I've had
to just reboot. So it seems I can't have the best of both worlds, a
large display and fast text output.

> > Trying to make sense of your assertion, my inexperienced reading of
> > some relevant (but perhaps not all relevant) portions of the spec lead
> > me to conclude that this behavior may not violate the spec because the
> > spec isn't very clear on this. For instance, looking at the UEFI 2.9
> > version of the spec in section 12.4 on page 454 in table 12-4 "EFI
> > Cursor Location/Advance Rules" there is reference to "bottom of the
> > display". What is the display? Does being in a particular "mode" of
> > cols x rows dimensions encompass all the pixels of the physical screen?
> > If it doesn't, is the display all the pixels or just the ones being
> > used for the columns x rows character output of a particular mode?
> 
> Typically text mode uses a windows centered on the GOP.  That is at
> least what standared edk2 is doing and also the behavior you can see
> when using ovmf in qemu.

I'm not sure I understand this. I assume by GOP you're referring to
UEFI's Graphics Output Protocol. But we're not using that here. Unless
you're saying that the GOP is used internally by the firmware for
some text modes.

> > To be more verbose as to the issue I'm seeing, the computer boots to
> > GRUB with the display resolution at native, 1920x1080, but only uses
> > what appears to be the top left 800x600 pixels for the 80x25 text mode
> > _initially_. So running "lsmod", for instance, uses the full height of
> > the screen when outputing text and the screen starts scrolling at the
> > bottom of the screen. But when it finished the GRUB shell prompt is
> > about midway down from the top and typing overwrites some of lsmod
> > output.
> 
> That sounds buggy indeed.  I've never seen such behavior on a graphical
> screen.  It sounds like the behavior I see when using efi shell on a
> serial console with the xterm having more lines than efi text mode.

Yes, I can imagine that being similar. I wonder if this can be detected
by setting the cursor position to the last row and first column,
calling OutputString() with the string "\n", then checking the current
cursor position in mode to see if its greater than the max line number
for this mode. If that works, keep writing "\n" until the current
cursor line number stops changing, then search for a mode with that
number of rows and set to that mode. I'm not sure I care to do the work
of writing and testing that though. So this might be a theoretical
exercise for the time being.

> > I'm also curious if anyone has seen issues with the largest area text
> > mode mode. Is there a problem with doing that this patch intends?
> 
> Hmm, good question.  Can't see problems offfhand, but you never know
> what corner cases people run into.
> 
> > Ultimately, I think it would be nice to have a key sequence that
> > raises and lowers the mode so that if the largest mode is not usable
> > for some reason, the user has a blind way out. I've created another
> > patch to add a command called efitextmode, which is very similar to the
> > EFI Shell's "mode" command. But that doesn't solve the issue just
> > mentioned.
> 
> Adding a command for that sounds like a better option, it's much easier
> for users to deal with it should this cause any problems because you
> only need to change the config file, not recompile the bootloader.

I was thinking both and. Its nice to automatically use the highest mode
because that should be the native resolution, so it will look nicer,
and more of the screen will be available. I'm not sure the common user
will even have an idea that the text mode can be changed. I certainly
didn't until a couple weeks ago when I stumbled on EFI Shell's "mode"
command. However, now I'm seeing that this is not an unambiguous win.
So I'm tending to agree with you for the patch in its current state. I
think it might be worth it if we could selectively run this code when
this specific bug is detected.

> The command could also accept 'min' and 'max' as argument (in addition
> to specific modes).

I like this idea. "min" seems unnecessary because that's always 0
according to the spec, but may be more user friendly. I'll add them
both.

Glenn

Re: [PATCH] efi: Set text-mode console resolution to maximum supported

[Gerd Hoffmann]

> > Well, 80x25 is the only text mode which must be supported by the
> > firmware.  Supporting larger modes is optional.
> > 
> > I think the firmware is also free to choose the default text mode,
> > and the implementations I've seen so far seem to be conservative
> > and use 80x25 or 80x50 by default even in case the screen is larger.
> 
> That kind of surprises me. When in mode 80x25 or 80x50 is the display
> not at its native resolution? For instance, when I put mine into 80x25,
> the display is clearly not at its native resolution, and not even the
> full physical screen is used, unlike at native resolution. The display
> is in a box centered on the physical display and the character glyphs
> are much larger and visibly more pixelated. In your experience, are
> other firmwares at 80x25 using native resolution or like mine some lower
> resolution?

Depends on the GOP driver I guess.  The Intel NUC I have surely comes up
in native resolution (FullHD), and text mode uses only a part of that
screen.  My workstation with two differently-sized displays comes up
with the resolution of the smaller display I think (don't feel like
rebooting to double-check), same here, text mode doesn't take the full
screen.

> Another interesting thing I just found out is that the text is
> displayed much faster in 80x25 mode. I have 4 available modes 80x25,
> 120x36, 128x40, and 240x80 (or there abouts, going off memory). To test
> the speed, I'm cating a largish file, and doing a wall clock time.

Yea.  It's simple software rendering, so it becomes slower when it has
to shuffle more data.  Also not sure how much this is optimized for
speed (linux fbcon is basically the same after all).

> > Typically text mode uses a windows centered on the GOP.  That is at
> > least what standared edk2 is doing and also the behavior you can see
> > when using ovmf in qemu.
> 
> I'm not sure I understand this. I assume by GOP you're referring to
> UEFI's Graphics Output Protocol.

Yes.

> But we're not using that here. Unless
> you're saying that the GOP is used internally by the firmware for
> some text modes.

vga text mode as in "poke chars to 0xa0000" simply doesn't exist in the
uefi world.  There is one (or more) GOP, and the firmware runs
software-rendered text mode on top of that.

Check out MdeModulePkg/Universal/Console/ConSplitterDxe in edk2 source
tree if you are curious.

> > > To be more verbose as to the issue I'm seeing, the computer boots to
> > > GRUB with the display resolution at native, 1920x1080, but only uses
> > > what appears to be the top left 800x600 pixels for the 80x25 text mode
> > > _initially_. So running "lsmod", for instance, uses the full height of
> > > the screen when outputing text and the screen starts scrolling at the
> > > bottom of the screen. But when it finished the GRUB shell prompt is
> > > about midway down from the top and typing overwrites some of lsmod
> > > output.
> > 
> > That sounds buggy indeed.  I've never seen such behavior on a graphical
> > screen.  It sounds like the behavior I see when using efi shell on a
> > serial console with the xterm having more lines than efi text mode.
> 
> Yes, I can imagine that being similar. I wonder if this can be detected
> by setting the cursor position to the last row and first column,
> calling OutputString() with the string "\n", then checking the current
> cursor position in mode to see if its greater than the max line number
> for this mode. If that works, keep writing "\n" until the current
> cursor line number stops changing, then search for a mode with that
> number of rows and set to that mode. I'm not sure I care to do the work
> of writing and testing that though. So this might be a theoretical
> exercise for the time being.

Well, for the serial console it might be possible to figure what the
resolution is by querying the terminal (there is a escape sequence for
that).  Would need fixing in the firmware though as the serial console
driver would have to add the mode detected to the list of text modes.

That probably wouldn't fix the messed up text mode rendering described
above though.  An additional problem with that idea is that
ConSplitterDxe creates the intersection of video modes supported by
outputs, so in case you have both graphical and serial console active
there is a high chance that the serial console native text mode size
doesn't make it to the intersection list ...

take care,
  Gerd