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?

[Jimmy Johnson]

Post by 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
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

[John Forkosh]

Post by Jimmy Johnson

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

[Mike Spencer]

Post by 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

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

Post by Mike Spencer
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.)

[Jimmy Johnson]

Post by Mike Spencer

Post by 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

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.

[Mike Spencer]

Post by Jimmy Johnson
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.

Post by Jimmy Johnson
...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? ;-)

[John Forkosh]

Post by Mike Spencer

Post by 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

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

[Javier]

Post by Mike Spencer
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.

Post by Mike Spencer
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]

Post by Javier

Post by Mike Spencer
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.

Post by Javier

Post by Mike Spencer
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.

Post by Javier
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

[mz721]

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

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!

[Rich]

Post by Mike Spencer
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?

[Mike Spencer]

Post by Rich

Post by Mike Spencer
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?

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

[Petri Kaukasoina]

Post by Mike Spencer
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]

Post by Petri Kaukasoina

Post by Mike Spencer
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.

Post by Petri Kaukasoina
'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]

Post by Mike Spencer

Post by Petri Kaukasoina

Post by Mike Spencer
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.

Post by Petri Kaukasoina
'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.

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