Commit Graph

7 Commits

Author SHA1 Message Date
Kyle Evans
37528fb4fb efi-autoresizecons: Don't fail the boot w/o GOP or UGA
efi-autoresizecons is currently executed for every boot. If it fails, we
risk failing the boot, and we really shouldn't do that unless we absolutely
must.

Not being able to locate GOP or UGA is not a significant enough failure to
kill the boot. We always have the option to fall back to resizing ConOut to
a higher text mode resolution (if available), so do that.

This was detected by Doug [1] while attempting a bhyve + UEFI + PXE boot.
This patch was effectively also submitted by Doug, but I expanded the
comment he had originally sent me a little bit to indicate why this is an OK
idea.

Reported by:	Doug Ambrisko <ambrisko@ambrisko.com> [1]
2018-08-04 06:40:18 +00:00
Kyle Evans
807dbf2b94 efi loader: Address two nits with recent graphics changes
- We should be setting a known graphics mode on conout, but we aren't.
- We shouldn't be setting gop mode if we didn't find a good resolution to
  set, but we were. This made efi_max_resolution=1x1 effectively worthless,
  since it would always set gop mode 0 if nothing else.
2018-04-19 03:31:41 +00:00
Kyle Evans
76e00374d2 loader efifb: implement uga_autoresize as a call to text_autoresize
UGA does not have the same kind of mode enumeration that GOP does. Implement
it instead as a call to text_autoresize so that firmwares with only UGA
present still get some kind of autoresizing behavior.

While here, rename a typo'd "gop" to "uga", although it will remain unused
for the time being.
2018-03-26 13:45:17 +00:00
Kyle Evans
1c1692795a efi loader: Choose a console mode instead if hw.vga.textmode is set
Not all systems use efifb; pull hw.vga.textmode and choose a good console
mode instead if it's set to something non-zero. This is basically a revival
of the code that used to live in boot1, but instead rebased onto this
different way of doing mode selection in loader.efi.

Interestingly enough, the regression that was previously introduced where
GOP would not reflect the console setting does not seem to exist when
console mode selection is done here. I've not done any investigation as to
why this is the case. Nevertheless, boot1.efi is still not the best place to
do mode selection.
2018-03-24 01:53:43 +00:00
Kyle Evans
05e8899d7d efi loader: Respect efi_max_resolution in loader.conf(5)
Default the max resolution to 1080p, we'll accept Width x Height
specifications along with the following presets:

- 480p
- 720p
- 1080p
- 2160p or 4k
- 5k

PR:		224825
Differential Revision:	https://reviews.freebsd.org/D14801
2018-03-23 21:02:46 +00:00
Kyle Evans
5f8cfbe134 UEFI: Ditch console mode setting, choose optimal GOP mode later in boot
boot1 is too early to be deciding a good resolution. Console modes don't map
cleanly/predictably to actual screen resolutions, and GOP does not reflect
the actual screen resolution after a console mode change. Rip it out.

Add an efi-autoresizecons command to loader to choose an optimal screen
resolution based on the current environment. We'll explicitly execute this
later, preferably before we draw anything of value but after we load config
and pick up any tunables we may need to decide where we're going.

This method also allows us to actually pass the correct framebuffer
information on to the kernel.

UGA autoresizing is not implemented because it doesn't have the kind of mode
enumeration that GOP does. If an interested person with relevant hardware
could get in contact, we can take a look at implementing UGA autoresize.

This effectively "fixes" the breakage caused by r327058, but doesn't
actually set the resolution correctly until the interpreter calls
efi-autoresizcons. The lualoader version of this has been included for
reference; the forth equivalent will follow.

Reviewed by:	imp (with some hestitation), manu
Differential Revision:	https://reviews.freebsd.org/D14788
2018-03-21 20:36:57 +00:00
Warner Losh
ca987d4641 Move sys/boot to stand. Fix all references to new location
Sponsored by:	Netflix
2017-11-14 23:02:19 +00:00