Date: Wed, 4 Apr 2018 00:23:05 -0400 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: Kyle Evans <kevans@freebsd.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Call for Testing: UEFI Changes Message-ID: <CACpH0Me55rcQDc8fQ2TX9%2BmNfYQ82MUhQHNg9RQQUxQAqAWXkw@mail.gmail.com> In-Reply-To: <CACNAnaGUD3EiL-D5NR4=CcjaPNuMQ4JJCRpdRqPHrdzhY6u-Mg@mail.gmail.com> References: <CACNAnaFmu2rFF1w4ar4xHUbN5vHitTLi0Ui6aCjL1MuTj3iJsQ@mail.gmail.com> <5f663141-433c-951d-a350-7369b004415f@alvermark.net> <CACNAnaE1UaqzS4bjQY9uqnhH2mX7XfUKT%2BVA%2Bn0v1=xF2FWXRg@mail.gmail.com> <20180322225644.1480251c4547ce30f3d88de9@dec.sakura.ne.jp> <dd6790b2-dfd2-d851-e851-99dfc489c5e5@ieee.org> <CACNAnaEfw2vzgnqrRkjgzqqtEyOYCeCR%2BP%2BVexPGzbOvNxsJ5A@mail.gmail.com> <CACNAnaE237%2Bb9-ZD1AWpnsSeE5EnDU539QDMDDcdZ5KWJjQwQA@mail.gmail.com> <20180401213831.1535c7511c1d95a258318bc7@dec.sakura.ne.jp> <CA%2B_TYQEFtc0LPSJBuggP1__gPNfaoBTf7qPadbmOXB_-CnHh5Q@mail.gmail.com> <CACpH0Md=ky4gs8pgvFa2nhbiSwdeKU1ZW6c3JdxfERKTOaSUTw@mail.gmail.com> <CACNAnaGgZy5k6hV2VG4PhSvzut9Uzno1SYpk0fmHcQD5S5k8Ag@mail.gmail.com> <CACpH0McmjRUm7hRoydCtSwYqhHuHvMvjbSk7yQ8drp823b3WvA@mail.gmail.com> <CACNAnaHSpicqRzH=YAZWxVqSh6HnPSa=FBeTJxoZZOXRrS5NyQ@mail.gmail.com> <CACNAnaGUD3EiL-D5NR4=CcjaPNuMQ4JJCRpdRqPHrdzhY6u-Mg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> wrote: > On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans <kevans@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. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0Me55rcQDc8fQ2TX9%2BmNfYQ82MUhQHNg9RQQUxQAqAWXkw>