5:4 monitor console: 2 unrender lines

[Mike Spencer]

Finally dumped my big 19" 4:3 CRT monitors. Happy with a new 24" 16:9
for the new(er) Slack 15.0 box. Now have the old 14.2 Pentium 4 on a
nice used HP L1950 monitor I was given. It defaults to using 1024x768
where text is big enough for old eyes but it's a 5:4 monitor and images
are distorted. Thanks to pointers here on a.o.l.s to xrandr, this

bogus% cvt -v 1280 1024

Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 \
1034 1063 -hsync +vsync

bogus% xrandr --newmode "1280x1024_60.00" 109.00 1280 1368 1496 1712 \
1024 1027 1034 1063 -hsync +vsync

bogus% xrandr --addmode VGA1 1280x1024_60.00
bogus% xrandr --output VGA1 --mode 1280x1024_60.00

fixes X when it matters. At the cost of smaller text, round things
aren't egg-shaped. All good with X.


But the console is still a problem. Two lines of text at the top of
the screen are random bits and text on those lines is invisible
although the software -- emacs, less etc. -- thinks it's using them.
Is there away to convince the system to render the two lines of text
that are "there" but not rendered?

bogus% stty -a rows 24

bogus% stty rows 26 'standard input': Invalid argument

bogus% tty
/dev/tty2

bogus% stty -F /dev/tty2 rows 26 /dev/tty2: Invalid argument


I obviously don'tknow what I'm doing with stty. Any suggestions?



--
Mike Spencer Nova Scotia, Canada

[Jimmy Johnson]

On 05/01/2023 11:35 PM, Mike Spencer wrote:
> Finally dumped my big 19" 4:3 CRT monitors. Happy with a new 24" 16:9
> for the new(er) Slack 15.0 box. Now have the old 14.2 Pentium 4 on a
> nice used HP L1950 monitor I was given. It defaults to using 1024x768
> where text is big enough for old eyes but it's a 5:4 monitor and images
> are distorted. Thanks to pointers here on a.o.l.s to xrandr, this
>
> bogus% cvt -v 1280 1024
>

> I obviously don'tknow what I'm doing with stty. Any suggestions?

Have you ever tried "arandr", it's easy to use and completely GUI.

https://slackware.pkgs.org/current/slackel-x86_64/arandr-0.1.9-x86_64-1dj.txz.html

--
Jimmy Johnson

Alien-19-Linux - AMD A8-7600 - EXT4 at sda9
Registered Linux User #380263

[John Forkosh]

Jimmy Johnson <Ji...@disposable.invalid> wrote:
> On 05/01/2023 11:35 PM, Mike Spencer wrote:
>> Finally dumped my big 19" 4:3 CRT monitors. Happy with a new 24" 16:9
>> for the new(er) Slack 15.0 box. Now have the old 14.2 Pentium 4 on a
>> nice used HP L1950 monitor I was given. It defaults to using 1024x768
>> where text is big enough for old eyes but it's a 5:4 monitor and images
>> are distorted. Thanks to pointers here on a.o.l.s to xrandr, this
>>
>> bogus% cvt -v 1280 1024
>>

>> I obviously don't know what I'm doing with stty. Any suggestions?

>
> Have you ever tried "arandr", it's easy to use and completely GUI.
>
> https://slackware.pkgs.org/current/slackel-x86_64/arandr-0.1.9-x86_64-1dj.txz.html

Alternatively, have you tried adding a file named 11-monitor.conf to
your /etc/X11/xorg.conf.d/ directory? It should contain the four lines

Section "Monitor"
Identifier "HDMI-1"
Option "PreferredMode" "1280x1024"
EndSection

assuming 1280x1024 is what you want. And run xrandr (no args)
to check that HDMI-1 is indeed your connected screen, and if not
then change the Identifier to the connected shown by xrandr.
I have no idea whether or not this will affect your problem
(I have no idea what your underlying problem is), but in any
case it's typically a cleaner way to control screen resolution,
etc, on boot.
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[Javier]

> Finally dumped my big 19" 4:3 CRT monitors.

You have done the right thing. CRTs glow too much, and that's not
good for your eyes. Modern flatscreens emit much less glow. The best
would be indirect illumination (as it happens in a printed paper),
but flatscreens are a big improvement in that sense anyway.

> But the console is still a problem. Two lines of text at the top of
> the screen are random bits and text on those lines is invisible
> although the software -- emacs, less etc. -- thinks it's using them.
> Is there away to convince the system to render the two lines of text
> that are "there" but not rendered?

As a workaround this will disable the top two lines. Everything will
be run inside screen, but there shouldn't be many issues.

cat > ~/.screenrc_notop <<"EOF"
echo '
escape ^vv # ESC key for screen becomes C-v
startup_message off
split
focus top
resize 2
focus bottom
bash
' > ~/.screenrc_notop
screen -c ~/.screenrc_notop

[Mike Spencer]

Javier <inv...@invalid.invalid> writes:

>> Finally dumped my big 19" 4:3 CRT monitors.
>
> You have done the right thing. CRTs glow too much, and that's not
> good for your eyes. Modern flatscreens emit much less glow.

Not sure about that. I find them a bit too bright.

>> But the console is still a problem. Two lines of text at the top of
>> the screen are random bits and text on those lines is invisible
>> although the software -- emacs, less etc. -- thinks it's using them.
>> Is there away to convince the system to render the two lines of text
>> that are "there" but not rendered?
>
> As a workaround this will disable the top two lines. Everything will
> be run inside screen, but there shouldn't be many issues.

Thanks for the suggestion but I'll get a different (not 5:4) monitor
or a different video card before I add a whole new layer of interfacew
between me and the text. I just started up screen as you suggested
and it still leaves me with hidden lines on a console.

> cat > ~/.screenrc_notop <<"EOF"
> echo '
> escape ^vv # ESC key for screen becomes C-v
> startup_message off
> split
> focus top
> resize 2
> focus bottom
> bash
> ' > ~/.screenrc_notop
> screen -c ~/.screenrc_notop
>

[Mike Spencer]

John Forkosh <for...@panix.com> writes:

> Jimmy Johnson <Ji...@disposable.invalid> wrote:
>
>> On 05/01/2023 11:35 PM, Mike Spencer wrote:
>>
>>> Finally dumped my big 19" 4:3 CRT monitors. Happy with a new 24" 16:9
>>> for the new(er) Slack 15.0 box. Now have the old 14.2 Pentium 4 on a
>>> nice used HP L1950 monitor I was given. It defaults to using 1024x768
>>> where text is big enough for old eyes but it's a 5:4 monitor and images
>>> are distorted. Thanks to pointers here on a.o.l.s to xrandr, this
>>>
>>> bogus% cvt -v 1280 1024

Tnx for replies but you snipped the part where I report at all is well
with the X display itself.

>>> I obviously don't know what I'm doing with stty. Any suggestions?

It's the virtual consoles to which you can switch with CTRL-ALT-Fn
that remain a problem. The X display appears correct after using
xrandr to force the 5:4 res but the consoles have two top lines of
snow/bits/garbage behind which the top two lines of text are unreadable.

AFAIK, nothing in xrandr controls how text consoles are rendered.

[ suggestions about X snipped ]

These suggestions are aout getting the res right for X. I have that
already. I'm trying to get the mode right for consoles.

stty(1) doesn't work. AIUI, the consoles are managed via framebuffer
but "fbset 1280x1024" evokes "ioctl FBIOPUT_VSCREENINFO: Invalid
argument". Yes, there is a suitable entry in /etc/fb.modes and I've
tweaked it in various ways based on suggestions from the web to no
avail.

Doesn't matter whether 1280x1024 is in effect for X or not; the
console still gets it wrong.

So I don't know what I'm doing with fbset, either. tty(1) says a
console is /dev/tty2 but fbset doen't think that's an fb device. Lots
of hits on the web on that error message with no useful resolution.

So I'm still stuck: X okay, console doesn't get it right.

(I did say that this is a 14.2 box in the original post.)

[mz721]

I am much less of an expert than most here, so this is likely to be
useless, but FWIW ... from my experience, if you do not want/need
framebuffer graphics in the ttys (eg you don't want/need fim, fbgs,
netsurf-fb etc), you can run them as text-only consoles by blacklisting
any framebuffer kernel modules. X will AFAIK work fine without a
framebuffer device (that is, no /dev/fb0), so should not be affected.

If I was having your issue and the framebuffer _was_ enabled, I would
disable it and reboot (lsmod | grep *fb should show you if you have a
framebuffer module loaded -- if /dev/fb0 exists, you probably do). You
could also try using a differnt framebuffer kernel module.

If I was having your issue and the framebuffer _was not_ enabled, I
would enable it -- maybe unblacklist a suitable fb module. You can test
that using modprobe. Just load a suitable fb module -- is is vesafb or
uvesafb or something -- and see if it looks any better.

Easy and worth a try.

If it is a really old video card, you can try the old 'named' fb
drivers, like s3fb and all that. I have a very old laptop that works
with sisfb, for example.

PS I like CRTs. But I like to use them with light text on black (like
the old green or amber on black VTs), so no brightness issues there no
matter what the monitor technology!



>

[Jimmy Johnson]

On 5/3/23 12:13 AM, Mike Spencer wrote:
>> Jimmy Johnson <Ji...@disposable.invalid> wrote:
>>> On 05/01/2023 11:35 PM, Mike Spencer wrote:

>>>> Finally dumped my big 19" 4:3 CRT monitors. Happy with a new 24" 16:9
>>>> for the new(er) Slack 15.0 box. Now have the old 14.2 Pentium 4 on a
>>>> nice used HP L1950 monitor I was given. It defaults to using 1024x768
>>>> where text is big enough for old eyes but it's a 5:4 monitor and images
>>>> are distorted. Thanks to pointers here on a.o.l.s to xrandr, this
>>>>
>>>> bogus% cvt -v 1280 1024

> Tnx for replies but you snipped the part where I report at all is well
> with the X display itself.

I just installed 'arandr' from the link I gave you, none of the stuff I
snipped was needed, now it's easy to setup my monitors in a GUI
application. You may want to give it a try. Then you can think me. :)

I should add install instructions are on that link, also you will need
to blacklist arandr in /etc/slackpkg/blacklist or it will be removed
when you run slackpkg clean-system.
--
Jimmy Johnson

Slackware64 14.2 - i7-2820QM - at sda7
Registered Linux User #380263

[Mike Spencer]

Jimmy Johnson <field.e...@gmail.com> writes:

> I just installed 'arandr' from the link I gave you, none of the stuff I
> snipped was needed, now it's easy to setup my monitors in a GUI
> application. You may want to give it a try. Then you can think me. :)

s/ink/ank/ ? :-) Don't get me wrong, I'm grateful for any help I can
get. But we seem to be having an orthogonal conversation.

AFAICT, arandr and xrandr do monitor tricks for X. Not for ttyn.

I have X working fine with Slack 14.2, the i915 chipset and HP L1950
5:4 monitor. I can write a shell script to do the only mode switch
within X that might occasionally be needed. I've already done that
for my 24" 16:9 with Slack 15.

My problem remains that when switching from X to a console, say tty2,
the top two lines of the screen are bit garbage while the software --
emacs, less, whatever -- thinks there're two lines there. If stty or
fbset should be able to fix that, I haven't figured out how yet. The
"ioctl FBIOPUT_VSCREENINFO: invalid argument" error message from fbset
seems to be a stumper. /dev/fb0 exists but console reports itself as
tty2.

I'm getting a rendering on the screen that doesn't match what the
software thinks is there. I'd like to know how to fix the text
console as nicely as xrandr has already fixed the X display.

> ...now it's easy to setup my monitors in a GUI application. You may

> want to give it a try.

Not keen on GUI alternatives. Use X, twm, no desktop. Command line
and shell scripts the favored mode. Cranky old geezer, y'know? ;-)

[Rich]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
> But the console is still a problem. Two lines of text at the top of
> the screen are random bits and text on those lines is invisible
> although the software -- emacs, less etc. -- thinks it's using them.
> Is there away to convince the system to render the two lines of text
> that are "there" but not rendered?

Many monitors include "sizing controls" in their menu systems. Have
you tried accessing the "sizing controls" and adjusting the size of the
image being displayed using those controls?

[John Forkosh]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
> John Forkosh <for...@panix.com> writes:
>> Jimmy Johnson <Ji...@disposable.invalid> wrote:
>>> Mike Spencer wrote:
>>>
>>>> Finally dumped my big 19" 4:3 CRT monitors. Happy with a new 24" 16:9
>>>> for the new(er) Slack 15.0 box. Now have the old 14.2 Pentium 4 on a
>>>> nice used HP L1950 monitor I was given. It defaults to using 1024x768
>>>> where text is big enough for old eyes but it's a 5:4 monitor and images
>>>> are distorted. Thanks to pointers here on a.o.l.s to xrandr, this
>>>>
>>>> bogus% cvt -v 1280 1024
>
> Tnx for replies but you snipped the part where I report at all is well
> with the X display itself.

> It's the virtual consoles to which you can switch with CTRL-ALT-Fn
> that remain a problem.

> [ suggestions about X snipped ]
> These suggestions are about getting the res right for X. I have that

> already. I'm trying to get the mode right for consoles.

Oops, my bad, followed-up JJ's answer which had snipped most of your
"console problem" stuff, though I should have inferred it from the
remaining reference to cvt.

Anyway, no solution to your actual problem, but a recommendation.
Let me now infer that you're using a lot of those Fn consoles
due to your up-to-now use of that 19" crt, where trying to run
multiple terminals in X leaves each one too small to be easily readable.
But I think you'll find the situation changed with your 24" led.
Try it, and see if that's more convenient. I prefer /usr/bin/konsole,
but there are many different choices. And the only thing I use
an Fn console for now is to startx (I still boot in console mode).

[Petri Kaukasoina]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
>But the console is still a problem. Two lines of text at the top of
>the screen are random bits and text on those lines is invisible

Have you selected the VGA text mode in /etc/lilo.conf?

Try vga=normal (and run lilo). 'vga=ask' lets you try different values,
for example 795 for 1280×1024, 24-bit mode. If it works, then edit it to
vga=795.

[Mike Spencer]

Only an "Autoadjust" option that changes nothing.

There is an info panel which tells me that

Current setting: 1024x768-60 hz

Recommended setting: 1280x1024-60 hz

But I knew that already. I can't get the system to believe it's
1280x1024 and talk to it accordingly.

Headed down a rabbit hole here, I used strace(1) on fbset that fails
with error messages. It appears that fbset opens /etc/fb.modes,
reads it and tries to execute an ioctl call with a TCGETS request
but using the same file descriptor returned from opening
/etc/fb.modes. That's obviously wrong and ENOTTY is returned.

Tracing system calls is a bit above my pay grade but it looks like
fbset is screwing up. Anybody know anything about that?

bogus% strace /usr/sbin/fbset 1280x1024-m

execve("/usr/sbin/fbset", ["/usr/sbin/fbset", "1280x1024-m"], [/* 44 vars */]) = 0
brk(NULL) = 0x8128000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76db000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=152026, ...}) = 0
mmap2(NULL, 152026, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76b5000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\210\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1848572, ...}) = 0
mmap2(NULL, 1669660, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb751d000
mprotect(0xb76ae000, 4096, PROT_NONE) = 0
mmap2(0xb76af000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x191000) = 0xb76af000
mmap2(0xb76b2000, 10780, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76b2000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb751c000
set_thread_area({entry_number:-1, base_addr:0xb751c700, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb76af000, 8192, PROT_READ) = 0
mprotect(0xb7704000, 4096, PROT_READ) = 0
munmap(0xb76b5000, 152026) = 0


open("/dev/fb0", O_RDONLY) = 3

# Opens fb0, gets fd 3, does nothing with it

brk(NULL) = 0x8128000
brk(0x8149000) = 0x8149000

open("/etc/fb.modes", O_RDONLY) = 4

# Opens text file, fd 4

ioctl(4, TCGETS, 0xbfdb193c) = -1 ENOTTY (Inappropriate ioctl for device)

# Tries ioctl on fd=4, fails

fstat64(4, {st_mode=S_IFREG|0644, st_size=22716, ...}) = 0
read(4, "#\n# Sample video modes\n# \n# "..., 8192) = 8192
read(4, "gh\nendmode\n \n#\n#\t1024x768, 43 Hz"..., 8192) = 8192
read(4, "80.00 MHz dotclock)\n#\t\n#\t\t\t\tHori"..., 8192) = 6332
read(4, "", 4096) = 0
read(4, "", 8192) = 0

# Reads entire ASCII contents of fd 4

ioctl(4, TCGETS, 0xbfdb193c) = -1 ENOTTY (Inappropriate ioctl for device)

# Tries ioctl on fd 4 again, fails

close(4) = 0
ioctl(3, FBIOPUT_VSCREENINFO, 0xbfdb1f9c) = -1 EINVAL (Invalid argument)

# Tries to talk to /dev/fb0, fails, gives up.

write(2, "ioctl FBIOPUT_VSCREENINFO: Inval"..., 44ioctl FBIOPUT_VSCREENINFO: Invalid argument
) = 44
exit_group(1) = ?
+++ exited with 1 +++

[Mike Spencer]

kaukasoina...@sci.fi (Petri Kaukasoina) writes:

> Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
>
>> But the console is still a problem. Two lines of text at the top of
>> the screen are random bits and text on those lines is invisible
>
> Have you selected the VGA text mode in /etc/lilo.conf?
>
> Try vga=normal (and run lilo).

That's what I've always had.

> 'vga=ask' lets you try different values, for example 795 for

> 1280x1024, 24-bit mode. If it works, then edit it to vga=795.

(For the record, LILO wanted that number in hex (0x31B == 795) when
using the LILO menu.)

That worked to the extent that reboot was successfull but made no
difference to the problem that the virtual consoles hide the top two
lines of text behind a stripe of snow.

thanks anyhow :-)

[John Forkosh]

In your lilo.conf you might try something like
append=" video=1280x1024 vt.default_utf8=0"
just to see what happens. Probably couldn't hurt.
(Sorry if somebody already suggested that.
Didn't read all the followups.)

[Mike Spencer]

Digressing from the subject a bit...

John Forkosh <for...@panix.com> writes:

> Let me now infer that you're using a lot of those Fn consoles due to
> your up-to-now use of that 19" crt, where trying to run multiple
> terminals in X leaves each one too small to be easily readable.

I'm 81 years old so your notion of "too small to be easily readable"
and mine may differ markedly. :-)

With a 24" 16:9 monitor, I run it in 1280x720 mode for most purposes.
An 80 col x 30 line xterm or emacs fills ca. 3/4 of the real
estate. With twm, there's no taskbar and I keep windows not currently
in use iconified to one side along w/ xclock, perhaps xload etc.
Otherwise, windows in use overlap. Text is easily readable
(-sony-fixed-medium-r-normal--24-230-75-75-c-120-iso8859-1 in xterms &
emacs).

This is essentially what I did routinely w/ the 19" CRT except there
wasn't an extra 25% real estate.

To watch a movie, I have a script that uses xrandr to switch the wide
monitor to 1920x1080 mode. Text isn't easily readable but a movie is
fine.

But that's all on a new (to me) box with Slack 15.0 and IS NOT WHERE
I HAVE THE PROBLEM.

What was my main machine until now also has a replacement flat screen
monitor, an old 19" 5:4 one given to me. X works on it in 1024x768
mode (which is somehow auto-selected and is incorrect for the hardware
aspect ratio, giving readable text but egg-ic circles) or 1280x1024
(which has round circles but less easily readable text.) So X is
okay.

On that machine (P4, Slack 14.2, i915 graphics) the virtual consoles
have lovely big text (ter-232b set in /etc/rc.d/rc.font).

But (for example) the top 3 lines of a manpage rendered in less(1) are
covered by bit snow. The software thinks it's sending those lines to
be rendered but they aren't. Scrolling down moves other lines into the
bit snow region.

> But I think you'll find the situation changed with your 24" led.
> Try it, and see if that's more convenient.

On the new 16:9 monitor in 1920x1080 mode I can put two 80x25 xterms
completely on-screen and two more mostly on-screen but I got the 24"
monitor expressly so that I don't have to read text that small. So I
use 1280x720.

Summary: New 16:9 24" monitor w/ Slack 15: all okay.

Old 19" 5:4 monitor w/ Slack 14.2: Virtual consoles fail;
everything else okay.

> I prefer /usr/bin/konsole...

That's part of KDE isn't it? I have never installed KDE except by
accident with my very first Linux box -- Caldera. Moved to Slackware
with twm and never looked back.

Thanks for taking an interest. But my 14.2 backup box w/ the 5:4
monitor is still deficient. fbset(8) claims to do things that might
fix it but I get error messages beyond my pay grade to interpret.

[Rich]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
> What was my main machine until now also has a replacement flat screen
> monitor, an old 19" 5:4 one given to me. X works on it in 1024x768
> mode (which is somehow auto-selected and is incorrect for the hardware
> aspect ratio, giving readable text but egg-ic circles) or 1280x1024
> (which has round circles but less easily readable text.) So X is
> okay.
>
> On that machine (P4, Slack 14.2, i915 graphics) the virtual consoles
> have lovely big text (ter-232b set in /etc/rc.d/rc.font).
>
> But (for example) the top 3 lines of a manpage rendered in less(1) are
> covered by bit snow. The software thinks it's sending those lines to
> be rendered but they aren't. Scrolling down moves other lines into the
> bit snow region.

Your original post (from which your response above became unglued)
while it did say "random bits" that wording was not explicit enough to
indicate "snow" to the rest of us here. I've been thinking your issue
was the top three lines of the text consoles are positioned off the top
of the screen, not just a mess of bit snow. Which was why I suggested
the "sizing controls" that I expected the old monitor to have.

Snow (as in random sparkling on/off pixel changes to what should
otherwise be a clear image) implies some hardware issue. What cable
type are you using to connect the old monitor? If it is a VGA cable
you might try double checking the connection (or even try a different
cable) to see if that makes a difference.

Also, how do you have the system booting? Via LILO? If yes, what do
you have in /etc/lilo.conf for the "vga=" setting. If you have
vga=normal, do you get the same snow on the top lines at the LILO
screen?

If no, and if the lilo screen text size is acceptable, then you might
try disabling the frame buffer console on the system connected to the
old monitor to see if using the plain VGA console fixes the snow issue.

Another option would be to try to reconfigure the frame buffer console
to use one of the modes that seems to work with X (1024x768 or
1280x1024). The snow could very well be an artifact of the actual mode
the frame buffer console picks being either a buggy mode in your video
chipset (i.e., your description sounds like you are describing CGA snow
from the CGA days), or a mode the monitor does not like, and a
different mode might eliminate the snow.




https://en.wikipedia.org/wiki/Color_Graphics_Adapter

The higher bandwidth used by 80-column text mode results in random
short horizontal lines appearing onscreen (known as "snow") if a
program writes directly to video memory during screen drawing. The
BIOS avoids the problem by only accessing the memory during
horizontal retrace, or by temporarily turning off the output during
scrolling. While this causes the display to flicker, IBM decided
that doing so was better than snow.[2] The "snow" problem does not
occur on any other video adapter, or on most CGA clones.

[Javier]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
> I'm 81 years old so your notion of "too small to be easily readable"
> and mine may differ markedly. :-)
>
> With a 24" 16:9 monitor, I run it in 1280x720 mode for most purposes.
> An 80 col x 30 line xterm or emacs fills ca. 3/4 of the real
> estate. With twm, there's no taskbar and I keep windows not currently
> in use iconified to one side along w/ xclock, perhaps xload etc.
> Otherwise, windows in use overlap. Text is easily readable
> (-sony-fixed-medium-r-normal--24-230-75-75-c-120-iso8859-1 in xterms &
> emacs).

This font will be 30% bigger, try:

xterm -xrm '*fullscreen: True' +sb -fn -xos4-terminus-bold-r-normal--32-320-72-72-c-160-iso10646-1

A full screen xterm is equivalent to the console. You can toggle
fullscreen mode with the keybinding Alt-Enter. And I'm sure you
can find bigger fonts if you look for them.