grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [PATCH] efi: Set text-mode console resolution to maximum supported
Date: Tue, 10 May 2022 13:57:08 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]