NetBSD/sys/arch/i386/isa/pcvt/Doc/NotesAndHints

Random Notes, Hints and Thoughts
--------------------------------------------------------------------------------
                                      Last Edit-Date: [Tue Mar  1 20:11:22 1994]


First of all, please read the file BugList in this directory !


After running some graphics application, the cursor is stuck on the
bottom line, though everything else appears well
===================================================================

Though this might initially appear to be a driver problem, it's rather
an application program's bogosity. The cursor update is done asynchron-
ously (to gain output speed), but this cursor update is inhibited while
an application has put a virtual terminal into ``graphics mode'' (i.e.,
the application program tells the driver that it's now responsible for
anything and all on this vty). This is notably the case while X11 is
running.

If the application fails to properly shut down itself, the terminal
might be left in an undefined state. The driver stand no chance there,
even if it could detect this bad status, since it doesn't know enough
about each piece of hardware to deal with. One possibility is that
the X server has been shot up and didn't get it to do its cleanups.
Another case (which i've often noticed on my slow notebook) is, killing
the Xserver is too slow for the (unfortunately hard-coded) 10-second
timeout from xinit, so it's being aborted ridiculously. (``X server
slow to shut down, sending KILL signal.'') This way, the state of
damage might range from ``almost okay, but cursor is stuck'' up to
a totally unusable machine (moon bitmap from xphoon still displayed,
no keyboard responses, only network is working and can be used to
shut down cleanly).
If the state of damage is only minimal, you might try to run the pure
X server on that vty again, and exit it with Ctrl-Alt-BkSpc. This might
be a workaround.

Vttest shows strange results
============================

Verify your stty "oxtabs" settings, it has to be "oxtabs", NOT "-oxtabs".
Get yourself an original DEC terminal to verify vttest's output, i have
until now not seen any (!) VTxxx clone, which does it right !!!


VT220-like Keyboard Layout
==========================

I have to say, i don't use it and i don't like it, so it's mostly unsupported
and untested. Patches welcome!

132-column mode
===============

There are known difficulties running pcvt in 132 column mode in conjunction
with X. Switching to 132 column mode does not only depend on a given chipset,
but on the board/manufacturers method of clock generation also. Even if your
chipset is detected, there may be still a problem with your board and it's
method of generating clocks. You may run in severe difficulties if your
board has a programmable clock generator and you run X and you switch from
132 col mode into X and back.

I have currently no idea how to solve this, other than having a similar
scheme as XFree86 applied to pcvt: Letting the user probe his board by using 
SuperProbe and recompiling pcvt according to the result.

NetBSD 0.9 and Xfree86 2.0
==========================

To get the X server up and running on 0.9, you have to compile pcvt with
PCVT_USL_VT_COMPAT disabled, otherwise X (and SuperProbe) will hang the
video driver (not the whole machine !). This bug is reproducable but not
found yet ...
This does not apply to NetBSD-current, 386BSD and FreeBSD.

X server ioctl compatibility:
=============================

The compatibility X-Mode ioctl commands CONSOLE_X_MODE_ON and
CONSOLE_X_MODE_OFF should not be used intermixed with the USL VT style
commands on another virtual terminal. NB, that this situation could happen
if you run an XFree86 2.0 server on one virtual terminal and attempt to
run SuperProbe version 1.0 (as delivered with the XFree86 2.0 release)
on another vty. SuperProbe is still using the old commands in order to
gain IO privileges.
Since the old commands cannot care for things like terminal switching,
serious corruption could result from this, which need not to be detected
immediately (i.e., apparently SuperProbe ran well). Known problems are
font corruptions after the X server has been shut down later, or palette
flickers in 1-second intervals due to an erroneously re-enabled screen
saver.

Once that SuperProbe has been fixed in its release to use the USL VT style
commands, any support for the old CONSOLE_X_MODE_XXX commands will be
eliminated.

(Recent comment: SuperProbe 1.3 has been fixed. It will be delivered with
XFree86 2.1.)

How to set the forground intensity to high on VGA mono screens:
===============================================================

try to issue the command: "scon -p8,60,60,60", EXPERIMENT !!!


How to change the color palette on VGA cards:
=============================================
	
try out the following commands:

	/usr/local/bin/scon -d/dev/ttyv0 -pblack:0,0,0 -pblue:20,20,40
	/usr/local/bin/scon -d/dev/ttyv0 -pbrown:55,55,15 -plightgray:0,42,0
	/usr/local/bin/scon -d/dev/ttyv1 -pblack:42,42,42 -pblue:60,60,60
	/usr/local/bin/scon -d/dev/ttyv1 -pbrown:60,60,30 -plightgray:30,10,0
	/usr/local/bin/scon -d/dev/ttyv2 -pblack:42,42,42 -pblue:63,63,63
	/usr/local/bin/scon -d/dev/ttyv2 -pbrown:60,60,20 -plightgray:0,22,0
	/usr/local/bin/scon -d/dev/ttyv3 -pblack:38,38,38 -pblue:63,63,63
	/usr/local/bin/scon -d/dev/ttyv3 -pbrown:60,40,0 -plightgray:0,0,20

	("scon -p default" resets the colors ...)


I have the screensaver compiled in, but can't see any effect
============================================================
Don't forget to turn it on with the scon utility. E.g.,

	scon -t 120

sets the timeout to 2 minutes.


Your Notebook uses the NumLock state to switch half of the keyboard
into a numeric keypad
===================================================================
Sigh, each time you leave "vi", your NumLock LED is on again and you
get a "6" instead of "o"? Try

	options  "PCVT_INHIBIT_NUMLOCK"

this prevents applications from turning NumLock on/off (except the
Xserver - but you want this).


Your notebook significantly loses contrast when using pcvt
==========================================================
Pcvt turns off the "high intensity" attribute bit internally (to enable
the use of a 512-characters charset). Some notebooks hard-code the out-
put intensity versus the character attribute though (i know it for a
Cirrus Logic CL-GD610/620 chipset).

As a quick & dirty workaround, you can reverse what pcvt did to the
Attribute Controller. Do not hack pcvt_sup.c, instead patch your
VGA registers during rc.local with the help of the vgaio utility:

    echo "ar12=0f" | vgaio > /dev/null

For the CL-GD610/620, i'm remapping some attribute registers and
get a simple gray scale emulation with this (i.e., i DO NOT use
the hack above):

   eagle_id=`echo 'cr1f?' | vgaio | cut -dx -f2`
   echo "sr 6 = $eagle_id" | vgaio > /dev/null	# enable extended regs
   echo "sr d5 = 40" | vgaio       > /dev/null	# not inverse, enable
						# color emulation
   echo "ar0=0;ar1=9;ar2=12;ar3=1b;ar4=24;ar5=2d;ar6=36;ar7=3f"|vgaio>/dev/null
   echo "ar8=0;ar9=9;ara=12;arb=1b;arc=24;ard=2d;are=36;arf=3f"|vgaio>/dev/null

NOTE THAT THIS IS ONLY FROM EXPERIMENTS! There's no warranty that something
like this wouldn't damage your screen/VGA!

(If you have chipset documentation, you're lucky...)


How to set the "LINES"-Environment variable for sh/csh:
=======================================================
(Note: this is mostly obsoleted now since the driver properly generates
SIGWINCH'es to notify applications about a changed screen size.)

     first for the csh:

	alias linesw scon -s \!^ \; setenv LINES \!^

     now for the bash/ash/sh/bash users:

	linesw()
	{
		scon -s $1
		LINES=$1; export LINES
	}

/* EOF */