Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #171782 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  Debian Jessie : regular console instead of a hi-res one! Mayuresh Kathe <mayuresh@kathe.in> - 2016-09-05 18:10 +0200
    Re: Debian Jessie : regular console instead of a hi-res one! Nicolas George <george@nsup.org> - 2016-09-05 18:40 +0200
    Re: Debian Jessie : regular console instead of a hi-res one! Stephen Powell <zlinuxman@fastmail.com> - 2016-09-05 18:50 +0200
      Re: Debian Jessie : regular console instead of a hi-res one! Stephen Powell <zlinuxman@fastmail.com> - 2016-09-08 06:10 +0200
        Re: Debian Jessie : regular console instead of a hi-res one! Felix Miata <mrmazda@earthlink.net> - 2016-09-08 10:10 +0200
          Re: Debian Jessie : regular console instead of a hi-res one! Nicolas George <george@nsup.org> - 2016-09-08 10:10 +0200
            Re: Debian Jessie : regular console instead of a hi-res one! Felix Miata <mrmazda@earthlink.net> - 2016-09-08 10:40 +0200
              Re: Debian Jessie : regular console instead of a hi-res one! Nicolas George <george@nsup.org> - 2016-09-08 10:50 +0200
              Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-08 16:20 +0200
                Re: Debian Jessie : regular console instead of a hi-res one! Felix Miata <mrmazda@earthlink.net> - 2016-09-08 19:00 +0200
                  Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-13 20:50 +0200
                    Re: Debian Jessie : regular console instead of a hi-res one! Felix Miata <mrmazda@earthlink.net> - 2016-09-14 11:50 +0200
                      Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-15 06:10 +0200
                        Re: Debian Jessie : regular console instead of a hi-res one! Felix Miata <mrmazda@earthlink.net> - 2016-09-15 11:20 +0200
                          Re: Debian Jessie : regular console instead of a hi-res one! rhkramer@gmail.com - 2016-09-15 13:30 +0200
                            Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-15 18:00 +0200
                            Re: Debian Jessie : regular console instead of a hi-res one! Felix Miata <mrmazda@earthlink.net> - 2016-09-18 08:00 +0200
                          Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-15 18:00 +0200
                    Re: Debian Jessie : regular console instead of a hi-res one! Ric Moore <wayward4now@gmail.com> - 2016-09-14 17:20 +0200
                      Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-15 06:10 +0200
    Re: Debian Jessie : regular console instead of a hi-res one! David Wright <deblis@lionunicorn.co.uk> - 2016-09-05 19:10 +0200
      Re: Debian Jessie : regular console instead of a hi-res one! Brian <ad44@cityscape.co.uk> - 2016-09-05 19:40 +0200
        Re: Debian Jessie : regular console instead of a hi-res one! Jude DaShiell <jdashiel@panix.com> - 2016-09-05 19:50 +0200
          Re: Debian Jessie : regular console instead of a hi-res one! Brian <ad44@cityscape.co.uk> - 2016-09-05 20:10 +0200
        Re: Debian Jessie : regular console instead of a hi-res one! Mayuresh Kathe <mayuresh@kathe.in> - 2016-09-05 20:30 +0200

Page 1 of 2  [1] 2  Next page →

#171782 — Debian Jessie : regular console instead of a hi-res one!

Hi,

Is there any way to get a regular console under Debian Jessie?
I don't use a GUI, just plain old CLI, and working on hi-res with "tiny" 
little fonts is extremely painful.
I have tried playing with "console-setup". No results.

~Mayuresh

[toc] | [next] | [standalone]

#171786

[Multipart message — attachments visible in raw view] — view raw

Le decadi 20 fructidor, an CCXXIV, Mayuresh Kathe a écrit :
> Is there any way to get a regular console under Debian Jessie?
> I don't use a GUI, just plain old CLI, and working on hi-res with "tiny"
> little fonts is extremely painful.
> I have tried playing with "console-setup". No results.

You probably need to inhibit the auto-loading of the kernel module
corresponding to your video controller.

But I advise against it: you will get stuck with the text mode emulation of
modern video cards, something very old and something that the vendors no
longer care about. You would probably get much better comfort by keeping the
framebuffer console and configuring it to use larger fonts.

In fact, even for CLI, if the box is not too old, I think you would be even
better of starting an X11 server with just a big XTerm taking all the
screen: in my experience, X11 terminal emulator are much more comfortable
than anything in the console.

[toc] | [prev] | [next] | [standalone]

#171789

On Mon, Sep 5, 2016, at 12:01, Mayuresh Kathe wrote:
> 
> Is there any way to get a regular console under Debian Jessie?
> I don't use a GUI, just plain old CLI, and working on hi-res with "tiny" 
> little fonts is extremely painful.
> I have tried playing with "console-setup". No results.
> 

Yes.  What you are seeing is a "frame buffer" console.  In most cases,
the X driver requires this.  But if you are not using an X server, you
can disable it.  The trick is to blacklist the right driver.  For example,
if you have a radeon chipset, blacklisting the radeon driver might accomplish
this.  Create a file such as /etc/modprobe.d/local.conf.  Put a line in it
which says

   blacklist radeon

Save the file and exit the editor.  Whenever you blacklist a module, it is
a good idea to rebuild your initial RAM file system, although if the module
is not loaded until after the permanent root file system is mounted read-only,
this is not strictly required.  To do this, issue

   update-initramfs -u -k $(uname -r)

Then shutdown and reboot.

To determine which module to blacklist, issue

   dmesg|less

and see if you can figure out which module is loading.  You can also issue

   lsmod|less

to see which modules are loaded.  Perhaps you can identify which module is
the frame buffer driver this way.  Knowing your video chipset helps give you
a clue also.  Issue

   lspci|less

and look for VGA.  This may give you a clue as to the identity of the frame
buffer driver.

-- 
  .''`.     Stephen Powell    <zlinuxman@fastmail.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#171886

On Mon, Sep 5, 2016, at 12:46, Stephen Powell wrote:
> 
> To determine which module to blacklist, issue
> 
>    dmesg|less
> 
> and see if you can figure out which module is loading.  You can also issue
> 
>    lsmod|less
> 
> to see which modules are loaded.  Perhaps you can identify which module is
> the frame buffer driver this way.  Knowing your video chipset helps give you
> a clue also.  Issue
> 
>    lspci|less
> 
> and look for VGA.  This may give you a clue as to the identity of the frame
> buffer driver.
> 

I found a better way to identify the frame buffer driver.  Issue

   lspci -k|less

then search for the character string VGA.  You should see something like this:

   01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000]
   Subsystem: Gigabyte Technology Co., Ltd RS780L [Radeon 3000]
   Kernel driver in use: radeon
   Kernel modules: radeon

This clearly identifies the frame buffer driver.

I realize that the OP has chosen a different solution.  But for the sake of
others who may find this thread in a future search who wish to go the hardware
text mode route, I have added this information.  The "vga" option of LILO
(also usable with GRUB2 if you use linux16 and initrd16 instead of linux and initrd
in the menuentry bloc) provides more choices than the hardware default of 80x25.
For more information about this, see my LILO web page at

   http://www.stevesdebianstuff.org/lilo.htm#VGA

-- 
  .''`.     Stephen Powell    <zlinuxman@fastmail.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#171890

The simplest way is to direct KMS's framebuffer to use a lower resolution 
than the native hi-res one by including a video= parameter on the kernel 
cmdline. The lower the resolution, the larger the standard (usually 16x9) 
framebuffer font becomes. On a 1920x1200 display I typically use 
video=1440x900@60; on a 1920x1080, 1280x720@60; depending on size of display 
and actual resolutions it supports. Using video=1920x1080 on a 2560x1440 
display should produce a font 177% of the physical size of the one used natively.
-- 
"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/

[toc] | [prev] | [next] | [standalone]

#171891

[Multipart message — attachments visible in raw view] — view raw

Le tridi 23 fructidor, an CCXXIV, Felix Miata a écrit :
> The simplest way is to direct KMS's framebuffer to use a lower resolution
> than the native hi-res one by including a video= parameter on the kernel
> cmdline. The lower the resolution, the larger the standard (usually 16x9)
> framebuffer font becomes. On a 1920x1200 display I typically use
> video=1440x900@60; on a 1920x1080, 1280x720@60; depending on size of display
> and actual resolutions it supports. Using video=1920x1080 on a 2560x1440
> display should produce a font 177% of the physical size of the one used
> natively.

It may be ONE OF THE simplest ways, but it a very bad one: screen have a
native resolution, operating at a different one requires scaling: the
resulting text will be much less readable than with the better solution of
using a larger font.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#171892

Nicolas George composed on 2016-09-08 10:07 (UTC+0200):

> Felix Miata composed:

>> The simplest way is to direct KMS's framebuffer to use a lower resolution
>> than the native hi-res one by including a video= parameter on the kernel
>> cmdline. The lower the resolution, the larger the standard (usually 16x9)
>> framebuffer font becomes. On a 1920x1200 display I typically use
>> video=1440x900@60; on a 1920x1080, 1280x720@60; depending on size of display
>> and actual resolutions it supports. Using video=1920x1080 on a 2560x1440
>> display should produce a font 177% of the physical size of the one used
>> natively.

> It may be ONE OF THE simplest ways, but it a very bad one: screen have a
> native resolution, operating at a different one requires scaling: the
> resulting text will be much less readable than with the better solution of
> using a larger font.

Have you ever tried it? Default framebuffer fonts are quite adaptable to 
different resolutions, as they are generally produced with many more pix than 
typical GUI fonts. All that extra size enhances readability, compensating 
rather nicely for the loss in apparent resolution.
-- 
"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/

[toc] | [prev] | [next] | [standalone]

#171893

[Multipart message — attachments visible in raw view] — view raw

Le tridi 23 fructidor, an CCXXIV, Felix Miata a écrit :
>			 as they are generally produced with many more pix
> than typical GUI fonts.

You said, quite rightly, "usually 16x9". That does not make many more
pixels, that is rather typical of what is used with GUI fonts too.

>			  All that extra size enhances readability,
> compensating rather nicely for the loss in apparent resolution.

Yes, it enhances it compared to tiny glyphs, but it worsens it compared to
larger glyphs at native resolution.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#171900

On Thu 08 Sep 2016 at 04:36:42 (-0400), Felix Miata wrote:
> Nicolas George composed on 2016-09-08 10:07 (UTC+0200):
> 
> >Felix Miata composed:
> 
> >>The simplest way is to direct KMS's framebuffer to use a lower resolution
> >>than the native hi-res one by including a video= parameter on the kernel
> >>cmdline. The lower the resolution, the larger the standard (usually 16x9)
> >>framebuffer font becomes. On a 1920x1200 display I typically use
> >>video=1440x900@60; on a 1920x1080, 1280x720@60; depending on size of display
> >>and actual resolutions it supports. Using video=1920x1080 on a 2560x1440
> >>display should produce a font 177% of the physical size of the one used
> >>natively.
> 
> >It may be ONE OF THE simplest ways, but it a very bad one: screen have a
> >native resolution, operating at a different one requires scaling: the
> >resulting text will be much less readable than with the better solution of
> >using a larger font.
> 
> Have you ever tried it? Default framebuffer fonts are quite
> adaptable to different resolutions, as they are generally produced
> with many more pix than typical GUI fonts. All that extra size
> enhances readability, compensating rather nicely for the loss in
> apparent resolution.

You can play with framebuffers and kernel drivers all you like.
What you cannot do is alter the layout of pixels on the screen.
If you don't use a resolution that matches those pixels exactly,
nothing you do can compensate. You are deluding yourself if you
think you can.

Now, I will apologise if you're still using a monochrome CRT. None
of the paragraph above applies in that case as the screen has a
uniform coating of phosphor. If you're still using a colour CRT,
then you get the worst of both worlds: the screen is pixelated
(you can see the dots or stripes with a handlens) but there's
no way of precisely lining up the grid of pixels from the video
card with the grid of holes in the shadow mask because the
mechanism linking them is analogue (shooting electrons through
a vacuum).

Terminal fonts are then designed to be displayed as a raster of
those pixels, rather than as a series of strokes coerced into
a raster of pixels. One might have a different opinion of the
clarity of any individual font displayed at different sizes.
One of the benefits of using setfont is that you can use a
different font for each size if you wish, and you can select
them on the fly according to circumstances: the type of work,
the ambient lighting etc. I use a much smaller font in bed
than outdoors, for example.

Another compromise that can be compensated for by having an
instant choice of fonts is their ability to handle unusual
glyphs in Unicode. Some of the clearest fonts are lacking in
coverage for obvious reasons.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#171905

David Wright composed on 2016-09-08 09:08 (UTC-0500):

> On Thu 08 Sep 2016 at 04:36:42 (-0400), Felix Miata wrote:

>> Nicolas George composed on 2016-09-08 10:07 (UTC+0200):

>> >Felix Miata composed:

>> >>The simplest way is to direct KMS's framebuffer to use a lower resolution
>> >>than the native hi-res one by including a video= parameter on the kernel
>> >>cmdline. The lower the resolution, the larger the standard (usually 16x9)
>> >>framebuffer font becomes. On a 1920x1200 display I typically use
>> >>video=1440x900@60; on a 1920x1080, 1280x720@60; depending on size of display
>> >>and actual resolutions it supports. Using video=1920x1080 on a 2560x1440
>> >>display should produce a font 177% of the physical size of the one used
>> >>natively.

>> >It may be ONE OF THE simplest ways, but it a very bad one: screen have a
>> >native resolution, operating at a different one requires scaling: the
>> >resulting text will be much less readable than with the better solution of
>> >using a larger font.

>> Have you ever tried it? Default framebuffer fonts are quite
>> adaptable to different resolutions, as they are generally produced
>> with many more pix than typical GUI fonts. All that extra size
>> enhances readability, compensating rather nicely for the loss in
>> apparent resolution.

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

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.

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.

2-Don't expect just because you decide it's not for you that it can't be for 
anyone else.

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.

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

[toc] | [prev] | [next] | [standalone]

#172134

On Thu 08 Sep 2016 at 12:53:49 (-0400), Felix Miata wrote:
> David Wright composed on 2016-09-08 09:08 (UTC-0500):
> 
> >On Thu 08 Sep 2016 at 04:36:42 (-0400), Felix Miata wrote:
> 
> >>Nicolas George composed on 2016-09-08 10:07 (UTC+0200):
> 
> >>>Felix Miata composed:
> 
> >>>>The simplest way is to direct KMS's framebuffer to use a lower resolution
> >>>>than the native hi-res one by including a video= parameter on the kernel
> >>>>cmdline. The lower the resolution, the larger the standard (usually 16x9)
> >>>>framebuffer font becomes. On a 1920x1200 display I typically use
> >>>>video=1440x900@60; on a 1920x1080, 1280x720@60; depending on size of display
> >>>>and actual resolutions it supports. Using video=1920x1080 on a 2560x1440
> >>>>display should produce a font 177% of the physical size of the one used
> >>>>natively.
> 
> >>>It may be ONE OF THE simplest ways, but it a very bad one: screen have a
> >>>native resolution, operating at a different one requires scaling: the
> >>>resulting text will be much less readable than with the better solution of
> >>>using a larger font.
> 
> >>Have you ever tried it? Default framebuffer fonts are quite
> >>adaptable to different resolutions, as they are generally produced
> >>with many more pix than typical GUI fonts. All that extra size
> >>enhances readability, compensating rather nicely for the loss in
> >>apparent resolution.
> 
> >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 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.

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

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.

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

> 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.
I can blacklist my i915 module; should I replace it in /etc/modules
with, say, the i810fb module. Or should I just add
video=intelfb:mode=640x480@60,accel,hwcursor,vram=8
to grub's boot line?

When I want to change resolution, which keys should I press to do that?

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.

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

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

> 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. So I need to know
your keystrokes for comparison.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#172163

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

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

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.

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

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#172195

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.

[toc] | [prev] | [next] | [standalone]

#172206

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/

[toc] | [prev] | [next] | [standalone]

#172217

TL;DR (Too Long, Didn't Read)--I didn't anticipate ever using that little 
abbreviation.

Anyway, my only reason for writing is to suggest (to the OP) that he consider 
using a fairly inexpensive digital flat screen tv as his monitor.  I currently 
use a 1080P 32" T that I bought for under $200 (on sale, somewhere, sometime, 
probably either Newegg or TigerDirect).

It has something like 1920x1280 resolution (which is enough resolution for 
me)--lets me easily set up two large windows side by side on the screen.

When I installed Wheezy, iirc (some years ago), fonts were pretty good (i.e., 
plenty big enough) with little or no intervention.  When I recently built a 
Jessie machine I did initially get some very small fonts and I had to do some 
adjustment.

Things too small on a 32" TV--get a 40 or 48 or even bigger TV (although the 
expense does go up)--again on sale, about 2 years ago I found a 48" TV for 
about $250.


On Thursday, September 15, 2016 05:11:26 AM 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):

[toc] | [prev] | [next] | [standalone]

#172236

On Thu 15 Sep 2016 at 07:28:16 (-0400), rhkramer@gmail.com wrote:
> TL;DR (Too Long, Didn't Read)--I didn't anticipate ever using that little 
> abbreviation.
> 
> Anyway, my only reason for writing is to suggest (to the OP) that he consider 
> using a fairly inexpensive digital flat screen tv as his monitor.  I currently 
> use a 1080P 32" T that I bought for under $200 (on sale, somewhere, sometime, 
> probably either Newegg or TigerDirect).
> 
> It has something like 1920x1280 resolution (which is enough resolution for 
> me)--lets me easily set up two large windows side by side on the screen.
> 
> When I installed Wheezy, iirc (some years ago), fonts were pretty good (i.e., 
> plenty big enough) with little or no intervention.  When I recently built a 
> Jessie machine I did initially get some very small fonts and I had to do some 
> adjustment.
> 
> Things too small on a 32" TV--get a 40 or 48 or even bigger TV (although the 
> expense does go up)--again on sale, about 2 years ago I found a 48" TV for 
> about $250.
> 
> On Thursday, September 15, 2016 05:11:26 AM 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):

https://lists.debian.org/debian-user/2016/09/msg00135.html
applies to laptops' own screens too.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#172379

rhkramer@gmail.com composed on 2016-09-15 07:28 (UTC-0400):

> ...  my only reason for writing is to suggest (to the OP) that he consider
> using a fairly inexpensive digital flat screen tv as his monitor.  I currently
> use a 1080P 32" T that I bought for under $200 (on sale, somewhere, sometime,
> probably either Newegg or TigerDirect).

> It has something like 1920x1280 resolution (which is enough resolution for
> me)--lets me easily set up two large windows side by side on the screen.

> When I installed Wheezy, iirc (some years ago), fonts were pretty good (i.e.,
> plenty big enough) with little or no intervention.  When I recently built a
> Jessie machine I did initially get some very small fonts and I had to do some
> adjustment.

> Things too small on a 32" TV--get a 40 or 48 or even bigger TV (although the
> expense does go up)--again on sale, about 2 years ago I found a 48" TV for
> about $250.

Using a TV is nice idea at least in theory. A virtually blind friend uses a 
42", seated at a pretty typical viewing distance, for Stretch and Leap. It 
takes me a lot of head movement to use. Most screens 20" & up are actually 
just small HDTVs (16:9 panels) with connections made for computers instead of 
TV, omitting any tuner, and commonly omitting speakers. However, larger may 
not be feasible:

1-boss provides hardware, so you get what you get, use it or get fired

2-space may be limited

3-personal field of view may be limited such that a bigger screen 
necessitates a large distance between eyes and screen

4-no money, must use whatever you already have

5-screens are designed for a certain range of viewing distances - 1080p is 
rather grainy when close enough to actually make typical default sizes 
adequate for someone using a big screen in order to make things big rather 
than providing room for more of similarly sized objects
-- 
"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/

[toc] | [prev] | [next] | [standalone]

#172237

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.

[toc] | [prev] | [next] | [standalone]

#172168

On 09/13/2016 02:36 PM, David Wright wrote:

> When I want to change resolution, which keys should I press to do that?

Back in the day, when xorg.conf roamed free, you could have multiple 
screen resolutions noted within it and a ctrl-alt-+ would switch 
resolutions on the fly. That worked on CRT monitors, not sure how that 
would work on LEDs. Ric


-- 
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

[toc] | [prev] | [next] | [standalone]

#172194

On Wed 14 Sep 2016 at 11:09:47 (-0400), Ric Moore wrote:
> On 09/13/2016 02:36 PM, David Wright wrote:
> 
> >When I want to change resolution, which keys should I press to do that?
> 
> Back in the day, when xorg.conf roamed free, you could have multiple
> screen resolutions noted within it and a ctrl-alt-+ would switch
> resolutions on the fly. That worked on CRT monitors, not sure how
> that would work on LEDs. Ric

I remember it well. I also remember that you hoped the CRT had
remembered the X/Y height/width/position settings for each
resolution's mode, or you'd have to do a lot of fiddling with each
change. Also the "clunk" presumably from the Line Output Transformer
as it coped with the sudden change in demand.

But none of this applied to the linux console of course.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web