Date: Tue, 3 Apr 2018 15:48:03 -0500 From: Kyle Evans <kevans@freebsd.org> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Call for Testing: UEFI Changes Message-ID: <CACNAnaGUD3EiL-D5NR4=CcjaPNuMQ4JJCRpdRqPHrdzhY6u-Mg@mail.gmail.com> In-Reply-To: <CACNAnaHSpicqRzH=YAZWxVqSh6HnPSa=FBeTJxoZZOXRrS5NyQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?CACNAnaGUD3EiL-D5NR4=CcjaPNuMQ4JJCRpdRqPHrdzhY6u-Mg>