Re: Debian Jessie : regular console instead of a hi-res one!
On Thu 15 Sep 2016 at 05:11:26 (-0400), Felix Miata wrote:
> 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.
Please read the whole paragraph rather than deconstructing it and
criticising the parts. I personified the small fonts, hence the :).
If talking to a short person cricks your neck, better get a chair
rather than complain that the person should be taller.
> >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.
I didn't know we were talking about *your* goals. You obviously use
GUI browsers otherwise you'd not be worried about web pages having
small fonts, something a non-GUI user would be blissfully unaware of.
Please read the OP
https://lists.debian.org/debian-user/2016/09/msg00127.html
and my reply
https://lists.debian.org/debian-user/2016/09/msg00135.html
which the OP has obviously read as xe responded to Brian's
comments on it.
Brian's "dpkg-reconfigure console-setup" will write the file
I mentioned and set a default size. My setfont commands will
allow different sizes to be selected on the fly, and used
contemporaneously.
Meanwhile the other subthread developed which involved changing the
resolution of the screen (and the font?) by loading different
drivers and modules or, in your case, by "direct[ing] KMS's
framebuffer to use a lower resolution than the native hi-res
one by including a video= parameter on the kernel cmdline".
I'm not convinced that this is the "simplest way". However,
on saying this, you exhorted me to try it before criticising it.
Well, I tried and so far have failed.
> >>>>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.
This will seem like pulling teeth, but...
https://www.kernel.org/doc/Documentation/fb/fbcon.txt
was where I started after a google. This page has a lot about
fbcon= values. My /boot/grub/grub.cfg files have fbcon= lines, viz.
... fbcon=scrollback:128K ...
... video=efifb fbcon=rotate:3 ...
So that gave me the syntax for adding such parameters to grub.
Now I had a look at
https://www.kernel.org/doc/Documentation/fb/
to see what else is there and went to
https://www.kernel.org/doc/Documentation/fb/intel810.txt
which is the closest thing to an Intel i915 device and
https://www.kernel.org/doc/Documentation/fb/intelfb.txt
which looked like it could be some sort of generic device
that might also work.
Here, the recommended lines to set the video (as you suggested in
https://lists.debian.org/debian-user/2016/09/msg00235.html
quoted above) are in LILO-speak, viz.
append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
vsync1:50,vsync2:85,accel,mtrr"
and
append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
which I stripped of their append=" " and some of the values (by
consulting the appropriate lists of parameters and their default
values listed on those pages.
Whew.
> >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.
Simplicity itself.
https://lists.debian.org/debian-user/2016/09/msg00135.html
says it all. You install the font package you want, and then
use setfont commands to change font size on the fly *if* you
want to, all with maximum native resolution.
If you're a CLI non-GUI person like the OP, that's it.
Configuring the default font is done the Debian Way.
> 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.
Cheers,
David.
Reply to: