Re: Debian Jessie : regular console instead of a hi-res one!

[David Wright <deblis@lionunicorn.co.uk>]

On Wed 14 Sep 2016 at 05:43:24 (-0400), Felix Miata wrote:
> David Wright composed on 2016-09-13 13:36 (UTC-0500):
> 
> Rather curious to see a regular participant here with a .co.uk
> mailing address apparently in a university environment in a UTC-0500
> time zone. Curiosity makes it for me a recurring distraction,
> wondering just what part of the world this might be, somewhere north
> of Wisconsin, Minnesota or North Dakota? :-p

Three states south of ND...Kansas.

> >On Thu 08 Sep 2016 at 12:53:49 (-0400), Felix Miata wrote:
> >>David Wright composed on 2016-09-08 09:08 (UTC-0500):
> 
> >>>You can play with framebuffers and kernel drivers all you like.
> >>>What you cannot do is alter the layout of pixels on the screen.
> 
> >>Absolutely true.
> 
> >>>If you don't use a resolution that matches those pixels exactly,
> >>>nothing you do can compensate.
> 
> >>False. The difference from one resolution to the next is easily lost
> >>if the screen resolution is beyond the resolving power of the eyes.
> 
> >>>You are deluding yourself if you think you can.
> 
> >>Been doing it for years. One factor is called natural optical
> >>deterioration. There's a limit to resolving power that typically
> >>gets worse with age. It's a primary reason why complaints are ever
> >>made about tiny fonts accompanying increased pixel density.
> 
> >The main reason people complain about tiny fonts
> 
> I'd like to see a cite for the assertion of this "main" reason.
> 
> >? is because they're
> >often difficult to change, or changing them leads to undesirable
> >effects, like web pages that don't re-wrap lines to take account
> >of the change.
> 
> I rather think the *main* reason is difficulty reading them, closely
> followed by, or in conjunction with, their pervasiveness, which is
> almost as commonly coupled with gray color instead of best contrast
> black.

I can't see the point of arguing about this; we're just looking down
opposite ends of a telescope. From my end...

The person to complain to about not being able to *read* small fonts is
your optician. Small fonts exist, are useful in the right context when
designed (or modified, see Knuth's metafont writings) with care, and
aren't going to go away by being complained about. :)

The people to complain to about inappropriate use of small screen fonts
are the web designers who serve them up. However, is this practical?
How many people are you going to complain to? How will you reach them?
Where do they work now?

So you're better off aiming for the single point of "failure": ones
inability to change (enlarge) them.

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
the Debian installation team, not web designers.

> Probably for most people, most of computing any more is within the
> confines of a browser window. Now that ≤IE6 support is history, more
> and more websites have taken to defining all sizes in px, with text
> sizes most commonly those suited for the lowest pixel density
> screens, rather rarely as large as 16px, which on a larger than
> average size but also higher than average density 2560x1440 screen
> is only 9.8pt, while a much more common 13px is <8pt and a not
> uncommon 10px is 6.1pt.
> 
> Others with poorer than it used to be eyesight, like myself, or at
> least poorer than average, and/or higher density screens, surely get
> rather tired as do I of the need to either zoom on entry to every
> previously unvisited domain, or suffer the ill effects of either
> configuring use of a minimum text size or disabling site styles
> altogether.
> 
> >But with an armoury of font sizes, six in my case from tiny to vast,
> >there's no difficulty changing at all, as long as one is prepared
> >to visit the bash prompt (or use a shell-escape).
> 
> Easy for you to say. Do you have a realistic idea how hard it is to
> do anything when the defaults start difficult to manage in the first
> place, the proverbial chicken and egg problem? It's a whole lot
> easier to make too big text smaller than it is to make too small
> text bigger. Maybe size 6 isn't so vast when density is double the
> reference standard and the acuity is below average.

Good point. Perhaps it would be worth submitting a feature request to
the d-i bug list to add an optional installer step that requests a
larger default font size after the the keyboard language/layout etc.
This could write lines in locations like /etc/default/console-setup
and /boot/grub/grub.cfg.

My smallest font gives me 213x66 characters on this laptop, and
would be very uncomfortable to read for any length of time. But
I can't claim that it's too difficult for me to be able to type in
commands to investigate and change it. Some others probably would.

> >It's easy to be misled by just considering the means to resolve two
> >dots of lines from each other as the only function of display
> >resolution. The crispness of a font depends on the angles of edges
> >to which the eye is very sensitive, even when it can't resolve the
> >actual dots themselves that make up that edge.
> 
> Maybe it's time to emulate some senior eyeballs. Hang some
> cheesecloth in front of your face, turn screen brightness down below
> 33%, let plenty of bright sunlight into the area where the display
> faces, and double or triple the normal distance between screen and
> face, then try to discern any difference in crispness between the
> vtty's default 9x16 font at 1280x720, and larger pixel size fonts on
> the same display at a native 1920x1080. Once the threshhold is
> reached, more px density is wasted.

Back in the '60s or '70s, the UK often had periods of low voltage
which would shrink the picture size on TVs. The Evening News would
reduce the picture to demonstrate the effect to those watching on
full power, and our picture would almost disappear...

But I don't understand why you're worrying about a screen font being
over-crisp. 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).

> >>Another factor has to do with screen size and distance, not
> >>necessarily caused by deterioration, but because of eyes never that
> >>good to begin with, and corrective lenses that do a better job at
> >>particular focal lengths. Too close and pixels can become apparent
> >>and bothersome. More distance can work better.
> 
> >If the pixels are as large as to be bothersome, then make them
> >smaller, ie use a higher resolution on the screen! Why would you
> >ever use a lower resolution in that case?
> 
> Visual threshhold vs. ease of (re)configuring. For a lot of people,
> the only way they know to deal with everything being too small is to
> reduce resolution. Is it ideal? Of course not! Do people do it? It's
> common among the simple minded and the elderly.

That's why I posted
https://lists.debian.org/debian-user/2016/09/msg00135.html
I used to play with console-setup, both the file and
dpkg-reconfigure console-setup   (which requires root), and it works
fine but is tedious. It's best used just for initial configuration,
and would be the target of that d-i bug suggestion above.

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.

> >>IOW:
> 
> >>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 can blacklist my i915 module; should I replace it in /etc/modules
> >with, say, the i810fb module.
> 
> I don't diddle with any modules in tweaking vtty behavior to my satisfaction.
> 
> >Or should I just add
> >video=intelfb:mode=640x480@60,accel,hwcursor,vram=8
> >to grub's boot line?
> 
> Dunno. What's your goal?

I run all my computer displays at their maximum resolution. They
are all LCD displays. (My last CRT monitor went to the tip in
October 2011, the last CRT TV in February 2014.)
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?

If it's any help in telling me, I know that the laptop can expand
the "dots" itself to a certain extent. The POST screen and the
CMOS screen has a resolution of xxxxxxx and there is an option to
live with this or enlarge to full-screen. But you choose one or the
other, nothing in between. You get an 80x25 character console.
The enlarged characters are noticeably blurred at the edges;
nothing like my crisp my-font-huge="setfont Lat15-Terminus28x14"
which gives me 91x28 characters at native resolution.

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.

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.
I don't know where this is going either.

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?

> >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.

But I've installed fbset and will try that; thanks. I'm not sure what
I type and when. 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.

> >>2-Don't expect just because you decide it's not for you that it
> >>can't be for anyone else.
> 
> >I've made no such decision. I'm just trying to understand your
> >statements in terms of the physics. If you take a font with an
> >x-height of 8 pixels and decrease the resolution to make it 50%
> >taller and wider, why would making the font with 8 bigger pixels be
> >clearer than making it with 12 pixels of the original size? You've now
> >got over twice as many pixels to manipulate.
> 
> Again, it's about reaching the resolving power threshold, or not.
> More pixels in a given space is higher resolution, is higher
> quality, but wasted if the resolving power limit is already reached
> at 8. I'm not asserting that higher pixel density is bad, only that
> past a certain point, a given set of eyeballs may not be able to
> make use of more.

But why throw resolution away to increase character size when
you can just increase the font size instead?

> >>3-Lowered resolution for the framebuffers does not necessarily
> >>dictate resolution for Xorg. For the past couple of years or so, if
> >>using the Intel Xorg driver, Xorg will default to the cmdline video=
> >>directive, in contrast to nouveau and radeon sticking to native by
> >>default, but this can be overcome via xrandr or xorg.con* or the DE.
> >>I normally configure them differently, native for Xorg, reduced for
> >>framebuffer.
> 
> >Irrelevant. We're talking about linux consoles here.
> 
> 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.

We're on a VC using a CLI; what has Xorg or a DE got to do with it?
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.

> >>4-I'm not suggesting font reconfiguration can't be appropriate, only
> >>that there may be an easier way that is quite suitable, particularly
> >>for a machine that is shared among people with diverse visual
> >>acuity.
> 
> >I need to try your method to have an opinion about that. I've
> >explained how easy it is with my method to have each VC at a different
> >font size simultaneously and independently.
> 
> 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
$ my-font-tiny
$ echo $COLUMNS $LINES
213 66
$ 
with the aliases described in the link.

> >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!? 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?

Cheers,
David.