Date: Sat, 11 Apr 2020 23:50:29 -0700 From: Chris <bsd-lists@BSDforge.com> To: Eugene Grosbein <eugen@grosbein.net> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: Why is the console a graphic/bitmapped console, and not text/character by default Message-ID: <0945b3b641401e1b7c50590169cc5265@udns.ultimatedns.net> In-Reply-To: <548297b0-d720-c3fc-2bca-01025f581515@grosbein.net>
index | next in thread | previous in thread | raw e-mail
On Sun, 12 Apr 2020 12:55:47 +0700 Eugene Grosbein eugen@grosbein.net said > 12.04.2020 11:41, Chris wrote: > > > Sorry for the ling title. But wasn't sure how make my > > question more concise. > > Why did we begin making an initial console "graphics mode" > > by default. My understanding has always been that (Free)BSD > > has been a "Server by default", and a Desktop after an initial > > install if that's one chosen target. > > It's near impossible to perform initial configuration > > in graphics mode, using a mouse to cut/copy/paste does *not* > > work as intended. Which requires one to make the necessary > > changes "breaking to the new system" after install completes > > to change initiation to test-mode before bouncing the box. > > While this "works" for long-time users. It's an *extra*, and > > seemingly *unnecessary* step. It is also likely to behoove > > first-time/new users -- except those already targeting a > > Desktop. > > > > Thanks for any insight into this! :) > > There are now many new hardware incapable of booting in legacy mode. > It runs in UEFI mode only that needs newer console driver vt(4) > that defaults to pixel rendering mode but supports text mode, too. > Sadly, some UEFI-based hardware does not support text mode even with vt(4) > and there is no option other than using pixel mode then. > That explains it. Thanks Eugene! :) Even if the answer is a bit disappointing. ;) --Chrishelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0945b3b641401e1b7c50590169cc5265>