Re: Debian Jessie : regular console instead of a hi-res one!
David Wright composed on 2016-09-14 22:59 (UTC-0500):
On Wed 14 Sep 2016 at 05:43:24 (-0400), Felix Miata wrote:
David Wright composed on 2016-09-13 13:36 (UTC-0500):
The person to complain to about not being able to *read* small fonts is
your optician.
Thats presumptuous. There's only so much corrective lenses can do. More
heroic correction may or may not be possible, or financially viable.
The people to complain to about inappropriate use of small screen fonts
are the web designers who serve them up. However, is this practical?
Only on rare occasions.
How many people are you going to complain to? How will you reach them?
Where do they work now?
Historically I've expended effort in various web design help forums trying to
catch some while they're young enough to be receptive. Time to do so has
become increasingly scarce.
So you're better off aiming for the single point of "failure": ones
inability to change (enlarge) them.
Done that too, mostly via bugzilla.mozilla.org, a little on
bugzilla.opensuse.org, less elsewhere, and very little of late.
The main thrust of *my* posts has been aimed at the VC user, in which
case the people to complain to are those serving up the small fonts:
the computer manufacturer (if you can't read the CMOS screens) or
Only my three most recent PC acquisitions don't use antiquity's 80x25 text
mode for BIOS setup. The newer are clearly inheritors of common
characteristics of modern web design, meaning more complexity per screenful,
and everything is considerably smaller than characteristic of 80x25.
the Debian installation team, not web designers.
Actually, the Debian installer shows more evidence of design wisdom than is
typical of other FOSS OS installers. I've only used the text mode, which
handily accepts kernel cmdline options to select a screen resolution that
works quite acceptably.
But I don't understand why you're worrying about a screen font being
over-crisp.
I don't think you're properly interpreting my intent, observation, not complaint.
> If you really object to paying for a higher pixel density,
> then why not buy a cheaper screen (if that's an option, which is
> unlikely with a laptop).
Cheaper tends to equate to smaller dimensions, contra to the object of making
stuff bigger and reducing opportunity for eyestrain. At any given physical
size, options for native resolution tend to be quite limited.
But using setfont (through aliases, to avoid having to remember
font names) is so much better: instant, and affects each VC
individually, so you can trade clarity with screen real-estate
merely by using Ctrl-Alt-Fn switching if you have several
VCs running side by side.
Here it becomes apparent your goals differ from mine. I'm perfectly happy
with having every VC use the same font, and prefer the very 16x9 one every
rpm kernel I've encountered has used by default (IIRC) since my first Linux
installation last century. This is the same font my (sans-plymouth) Debian
installations use at least for the initial phases of init, if not all the way
through to VC login prompts.
>>1-Don't knock it if you haven't tried it. By this I don't mean tried
>>only on Debian installations either. The default framebuffer font of
>>Debian and its derivatives is very commonly different from
>>non-Debian distros, represented by the spindly ugly thing used by
>>Ubuntu. Without Plymouth, one can typically see the initial font
>>during post is much bolder, changing somewhere along the way to the
>>desktop or login prompt to a much lighter stroked variety. If all
>>you've ever seen is the lightweight, try a (Debian) Knoppix CD or
>>DVD and you'll see what Fedora and openSUSE users see by default
>>(TerminusBold?) on their framebuffers, a font that's nicely bold and
>>forgiving of non-optimal screen resolution.
>Well, I'm up for that. Tell me what I have to do: it's quite involved.
Which "that" are you up for that's "quite involved"?
You wrote "Don't knock it if you haven't tried it" so I'm up for trying it.
I get that you are, just not what exactly is your definition of "that" or "it".
I run all my computer displays at their maximum resolution.
I have one 19.8" (actual viewable) Trinitron that I still use fairly often,
but the rest are flat panels. The general rule for panels here is Xorg is run
in native mode, but resolution differs for the VCs as an eminently
efficacious method of controlling the size of the kernel's and framebuffer's
default font learned decades ago.
They
are all LCD displays. (My last CRT monitor went to the tip in
October 2011, the last CRT TV in February 2014.)
I still have two CRT TV's in serviceable condition, though used little. Only
one has PIP, and neither have POP. Unlike newer TVs and their digital modes,
source selection and channel switching on a CRT is for all practical purposes
instantaneous. Also they have durable glass surfaces, not susceptible to
scratching. I currently have eight functional flat panel PC displays and TVs.
https://lists.debian.org/debian-user/2016/09/msg00235.html suggests
changing character size by changing the resolution because it's meant
to be easy.
I'm curious to see what happens when you run a display at
sub-optimal resolution. Where does the change from the, say, 640x480
buffer to the screen's 1280x800 red/green/blue-pixels occur? Does
the kernel do this in the video driver module, or does the non-linux
(Dell?/Intel?) firmware on the laptop circuit boards do it?
This is not something I've ever investigated. I've always assumed that it is
the display electronics that perform the required interpolation.
https://lists.debian.org/debian-user/2016/09/msg00133.html
told me to remove the video driver (i915) that I normally use.
I did that and found I could add an explicit framebuffer module
(i810fb) which looks like it might match my hardware. I don't know
where this is going.
I don't know either. I use i810 only on one machine that actually has an
i810e chipset, and it hasn't been updated (or even booted) since December.
https://lists.debian.org/debian-user/2016/09/msg00235.html
told me to include a video= parameter on the kernel cmdline
so I modified the example on the linux kernel framebuffer page.
Would "the kernel framebuffer page" be
https://www.kernel.org/doc/Documentation/fb/framebuffer.txt ? I don't see
video= anywhere on it.
I don't know where this is going either.
Other than life has changed a bit since KMS went into the kernel, I can't say
without knowing which page to which you refer.
That's why I need a bit of handholding. It must be easy...?
>When I want to change resolution, which keys should I press to do that?
In which context? Grub menu? Plymouth-free vttys? Vttys with
Plymouth? Different fonts for different vttys?
Well, to make an easy comparison, in the VCs.
Imagine a scenario where you boot into a console with a small/medium
font giving you 128x40 chars, then the sun comes out and you decide
you need larger characters to compensate for the loss of contrast.
I'd want more like 106x33 or even 91x28 chars. What do I press?
As I wrote above, different fonts among the VCs is not something I've ever
considered doing. I wonder if such support might be one of the many functions
of the "screen" utility?
>And last, but not least, I need a surefire method of determining what
>resolution I have succeeded in running. With native resolution, that's
>very simple. I put some text on the screen such that the bottom line
>and rightmost character are both used, determine the pixels used in
>the character grid, multiply each with $LINES and $COLUMNS, and then
>add the unused pixels at the bottom and right edges. All done with
>a handlens.
Or more simply, just see what fbset reports.
I was talking native resolution, ie hardware. There's no arguing with
the uninterpreted numbers you get by counting the little flecks of light.
I expected get-edid from the read-edid .deb would do it, but on the Jessie I
have booted currently (GeForce 8400GS), it segfaults. On the openSUSEes that
offer it, monitor-edid reports it.
'hwinfo --gfxcard' on openSUSE will tell you the current and supported modes
according to EDID, but on its output I'm currently viewing it doesn't
explicitly tell which mode is actually native/preferred. On Jessie, same
command omits modes output.
But I've installed fbset and will try that; thanks. I'm not sure what
I type and when.
I've only used to do discover the current mode, never managed to have it
change anything.
Having loaded i810fb and set a video= line I found
that I now lack a /dev/fb0 file so fbset just prints an error message.
So I'm going down the wrong alley at the moment.
I don't know what's going on here either. I don't mess with dictating what
modules the kernel loads, always using with KMS kernel whatever it chooses
for framebuffer support. ISTR seeing no /dev/fb0 only when stuffed by some
bug into using 80x25 just to get something besides black on screen.
We're talking about how we get where we want to go, and the
ramifications of the various methods of getting there that depend on
which driver and/or gfx hardware is used.
I'm trying to reduce the resolution of the VC so I can test your
method of increasing character size and compare it with mine.
With KMS kernels and gfxchips KMS supports, I only ever change VC mode using
a video= cmdline parameter and rebooting. Appropriate configuration of
/etc/default/grub ought to produce an equivalence if unable to use it
directly, via GRUB_TERMINAL and/or GRUB_CMDLINE* and/or GRUB_GFX*. As I don't
use Grub2, I'm not up to speed on which does what or why so many apparent
configuration options Grub2 provides WRT video.
Actual comparison dependent on rebooting I think problematic unless you have
a matched pair of displays to test with.
You haven't to degree that I can grok how it is that you find your
method easy/fast/convenient/other.
What did I omit from
https://lists.debian.org/debian-user/2016/09/msg00135.html
Switching is as easy as:
$ my-font-vast
$ echo $COLUMNS $LINES
80 25
90 columns, 28 lines in 1440x900 mode, which is what I most often use for VCs
on a 1680x1050 display.
$ my-font-tiny
$ echo $COLUMNS $LINES
213 66
240 columns, 75 rows in 1440x900.
$
with the aliases described in the link.
None of the fonts there listed do I favor like the kernel's default.
Lat15-TerminusBold16 seems closest to it.
>So I need to know
>your keystrokes for comparison.
Again, which context? I boot using Grub with Gfxboot versions that
display a substantial tail of the selected stanza. The way I
configure, there's typically little stroking, typically limited to
one or more instances of Left, then holding down the BS key until
what I want removed is gone.
You're not serious!?
Every bit, but my goals are apparently quite different from yours.
With my method, I can change the font size
instantly by typing, say,
$ my-font-large
which is aliased to
$ setfont Lat15-Terminus24x12
and you're suggesting that that might not be as easy/fast/convenient
as rebooting and editing the kernel command line in the grub menu to
change the display resolution! Is that a correct interpretation of
what you're suggesting? Or have I got hold of the wrong end of the stick?
Different stick. You're getting what you want, maybe just not as simply as
you'd like. I get what I want on the VCs (except in Debian and its
derivatives that I've tried) without having to change anything in what the
installer puts in /etc/. In Debians, I must change /etc/default/console-setup
to get what I want to stick across boots.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Reply to: