Date: Tue, 30 Jan 2018 12:32:07 +0100 From: Polytropon <freebsd@edvax.de> To: "@lbutlr" <kremels@kreme.com> Cc: Freebsd Questions <freebsd-questions@freebsd.org> Subject: Re: Setting console resultion Message-ID: <20180130123207.b7739451.freebsd@edvax.de> In-Reply-To: <BD35D3BE-6948-4C2A-8B4F-C28618F63344@kreme.com> References: <5919B7EF-A04A-47CD-AFE1-3B2290420AEF@kreme.com> <20180129154404.f1662f20.freebsd@edvax.de> <BD35D3BE-6948-4C2A-8B4F-C28618F63344@kreme.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jan 2018 21:07:54 -0700, @lbutlr wrote:
> On 29 Jan 2018, at 07:44, Polytropon <freebsd@edvax.de> wrote:
> > On Mon, 29 Jan 2018 02:37:05 -0700, @lbutlr wrote:
> >> I'm not sure why this is so hard, but I've read dozens of pages
> >> and threads on setting up the console to boot into something
> >> other than VGA 80x24 and I can't get anything to change the
> >> resolution.
> >
> > I think with vt, it's the exact opposite problem: You cannot
> > set it to 80x25 anymore. ;-)
>
> I dunno, that was what my console was set to and I could not change it.
With vt as the console driver? Is that even possible?!
> >> I have an old Core 2 duo machine with a 27" screen. Once I
> >> change by boot.conf to use sc instead of vt, I can see the
> >> mode that I want (1920x1440x32) but I cannot get the screen
> >> to change.
> >>
> >> vidcontrol mode
> >> This is a fresh install of 11.1.
> >>
> >> If I try to load the intel driver, the screen goes blank.
> >
> > If you are using X, you cannot use sc anymore. X requires
> > the use of vt now.
>
> I do not use X, I am only talking about the text console.
In that case, you can choose between vt and sc. I'd suggest
becoming friends with vt under any circumstances as sc will
probably be abolished soon. Both systems allow you to change
the screen resolution, and with sc, it has always been easy
to do (with vidcontrol).
But you've been talking about loading the intel driver, this
is usually only needed if you want to use X (and X requires
you to use vt instead of sc), that's why my assumption that
you also were using X on that system (because this is the
only reason to load that driver).
> >> The onboard video connector not he machine is VGA, so even
> >> though the monitor supports higher resolutions, I don't think
> >> those would work.
> >>
> >> I've also tried 1024x600, just to see if I can get *something*
> >> to work.
> >
> > If you can, use the exact size of your monitor (in pixels);
> > I assume you're talking about a LCD monitor, which is common
> > today, as hardly anyone still uses CRTs like I do (which can
> > have more than one mode, while LCDs only have one physical
> > mode, determined by the amount of pixels).
>
> LCDs support many resolutions, and the VGA connector will not
> support the maximum number of pixels the screen can display
> (2564x1440).
An LC display has only a fixed amount of pixels, and this amount
does _not_ change. What you are describing is done in software.
Still it's common for LCDs to address them in their native mode.
So if a display has 2564x1440 pixels ("hardware pixels"), this
should be the mode the driver talks to it in; however, if its
internal software also "speaks" 1024x768, you can get to see
something in that mode, even though it will look ugly. But many
displays are able to internally "re-calculate" images and either
apply a border, or just scale them up ("light 2x2 pixels where
the source image contains 1"). So if you input 1200x800 px, the
device _can_ scale it up to fill 2564x1440 px, but that doesn't
change its physical properties.
Note that even though commonly "resolution" is being used as
a term for "size in pixels", it's technically not correct. The
resolution is provided in dpi, dots per inch, like 75, 100,
or 120 dpi (with the assumption that the horizontal and the
vertical resolution will be equal), or 150x150dpi (to
explicitely state they are equal):
width in inch height in inch
resolution = ------------- x --------------
pixels wide pixels high
As both values are _physically fixed_ on a flatpanel display,
the resolution is also fixed ("native resolution"). On a CRT,
the amount of (addressable) pixels changes with the size, so
does the resolution.
> Also, there will be a different display connected once the
> setup is done and the machine is actually installed in it's
> final location.
In combination with vt, this might require you to change your
settings once you got them working for _one_ display.
> >> Every attempt requires changing /boot/loader.conf and then
> >> rebooting, so it gets very aggravating very quickly, and I
> >> can't find consistent information since most of the pages
> >> i've found refer to FreeBSD 9.x or 10.x (or sometimes
> >> earlier) and it appears a lot has changed in 11.x.
> >
> > The vt documentation isn't fully complete yet, but here is a
> > good starting point:
> >
> > https://wiki.freebsd.org/Newcons
>
> kldload i915kms <- screen goes black, never comes back.
I'm almost sure you won't need that if you use sc.
For vt... maybe yes... but this is probably only needed if you
are going to use X (which you denied).
> hw.vga.textmode <- already set
This is only relevant for vt.
> kern.vt.fb.default_mode="1024x768"
This isn't the size in pixels your system has (it's even 4:3,
nobody uses that anymore).
Use the loader command "gop" to see what the system _thinks_ your
screen looks like.
> Not sure if I tried that specific number, as that's still a
> very limited sccreen size, but certainly the other numbers I
> tried did not work.
It might cause the screen to blank, or to to perform a fallback
to a known "good mode".
Maybe you can experiment with the following syttings (from a
FreeBSD 10.3 system connected to a CRT with now unreadable "text
mode" thanks to vt):
/boot/loader.conf:
kern.vty=vt
hw.vga.textmode=0
i915kms_load="YES" # can be removed if causing trouble && !X
/etc/rc.conf:
allscreens_flags="-f gallant" # ugly
This will give you 132x54 ugly characters on a 21" 4:3 CRT. :-)
Try fonts like vgarom-8x14 or vgarom-8x8 if you want to try a
smaller character size.
I have also experimented with kern.vt.fb.default_mode in
/boot/loader.conf, but it didn't seem to have any effect.
The "gop" loader command is not available on FreeBSD 10,
so I couldn't check that.
> Reading that, other than UTF-8 support, vt appears to be
> extremely limited and its know issues list is nearly 4 years
> old, which certainly gives one pause.
Yes, vt doesn't provide the functionality sc provided for decades,
without any trouble. Keep in mind vt isn't text mode. It is
already a graphics mode that just disguises as a text mode (by
displaying text characters). But vt is rich on features, it's
just that the documentation isn't complete yet.
If you want things like normal 16 colors, block graphics or german
umlauts, then definitely stay with sc; vt hasn't achieved that
level of excellece yet. ;-)
> "Pre-loading i915kms.ko/radeonkms.ko disables video output
> from the point of time these video drivers are attached
> until interrupt threads are enabled way later. This makes
> kernel panics during boot undebugable."
Great...
> Anyway, I have set the console to use sc which is how I got
> a screensaver to load (not that I want/need a screensaver,
> but I was testing) and I've managed to set the screen size
> of a current session, but I still can't get it to change
> during boot (so I can actually read some of the output) and
> I have to apply it to each console manually after logging in.
With vt, the screensaver wouldn't even work. ;-)
> This seems needlessly obtuse and complicated. Not that sc
> was much better, though things have gotten much worse that
> they were in, say, freebsd 9 in terms of plugging in a
> screen and having a reasonable hope you'd be able to set it
> to a mode where each characters isn't 24-30 points.
The alternative "solution" is to have tiny crappy characters
and blurry colors, so you can't read anything on your huuuge
screen. ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180130123207.b7739451.freebsd>