Re: Call for Testing: UEFI Changes

If you're thinking on it,  you should know that the DVD version works.  The
difference, AFAICT, is that it simply calls loader.efi directly.  Ie:
bootx64.efi is loader.efi, not boot1.efi.

Loader.efi doesn't seem to change the screen mode when it starts.  When the
kernel starts afterwards, this all just works.

I assume loader.efi works here because CD9660 is a format supported by
EFI.  Thus loader.efi can directly read it.  That and/or loader can work
with the device is was started from.

When I start boot1.efi on this system, it changes mode, then it continues.

... so if you've got a boot1.efi that doesn't change mode, can you post
that binary for me to try ... ?

On Tue, Apr 3, 2018 at 4:48 PM, Kyle Evans <kevans_at_freebsd.org> wrote:

> On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans <kevans_at_freebsd.org> wrote:
> > Hi,
> >
> > Right- so, `gop set 0` should've immediately cleared your screen and
> > put it into 1920x1080, full stop. If it did not, I think that's
> > indicative of some kind of interestingly broken firmware...
> >
> > Regardless! We're clearly bad at trying to set a mode before the
> > kernel starts, so r331904 sets the default max resolution in such a
> > way that we just don't change the resolution by default anymore and
> > interested parties can bump that up if they want to try it. This
> > Thursday's snapshots should have this included.
>
> After reviewing the video again and discussing it with manu, I don't
> think that commit's going to solve your problem at all... we'll need
> to re-think this one a bit more.
>
> > I think if we're going to change modes as a default, we should have
> > some way for vt/efifb to use EFIRT or be notified by EFIRT of
> > supported resolutions so that vt/efifb can hopefully just handle it
> > all and do it properly. This approach would be more similar I guess to
> > how KMS drivers operate, and less fragile than what we're seeing with
> > these different approaches we've taken.
> >
>