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