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