Initial import from FreeBSD RELENG_4:

[dragonfly.git] / usr.sbin / pcvt / Misc / Doc / NotesAndHints

Random Notes and Hints                Last Edit-Date: [Sun Apr  2 18:28:09 1995]
--------------------------------------------------------------------------------


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


Can't get pcvt working on a ThinkPad
===============================================================================

Anyway, back to the keyboard.  The problem is that by default the
ThinkPad uses PS/2 scan code mode.

You can fix this by using an option and building a kernel, as shown
below.

] Just for the record, in case someone else is asking for this: Al's
] confirmation that pcvt w/ PCVT_SCANSET=2 works for the ThinkPad:
] 
] As Al Elia wrote:
] | Date: Mon, 28 Nov 1994 18:24:42 GMT
] | From: Al Elia <aelia%aelia.student.harvard.edu@sax.sax.de>
] | Message-Id: <199411281824.SAA01554@aelia.student.harvard.edu>
] | To: joerg_wunsch@bonnie.tcd-dresden.de
] | Subject: Re: Anyone got FreeBSD 1.1.5.1 running on a ThinkPad?
] | 
] | PCVT_SCANSET=2 worked...I had put in PCVT_SCAN_SET=2 (Doh!)
] | 
] | --Al Elia
] | <aelia@aelia.student.harvard,edu>

                         (Terry Lambert quoting Joerg Wunsch quoting Al Elia)


If one of the "lock" keys is pressed, LEDs do not get updated, keyboard hangs
===============================================================================

This entry used to be a long time in the BugList file, and i could never
reproduce the problem. Today i got an explanation in german from someone
owning such a keyboard, i'll try to translate:

"This are old keyboards manufactured (~1985/1986) which manage their LED
 setting only internally.
 It is not possible to set the LEDs from the (main-) processor, if you
 try, the keyboard processor hangs and the PC has to be reset by switching
 power on and off, hard- and/or softreset does not work in this case.
 Workaround: recompile pcvt with the LED update removed"

In other words, define PCVT_NO_LED_UPDATE if you have such a beast!


Cursor not visible anymore in 40 and 50 lines mode
===============================================================================

You have programmed an underline cursor in i.e. 28 line mode by doing
"cursor -s 10 -e 12". Then you switch to 40 line mode using "scon -s 40".
At this point the cursor is no longer visible because the 40 line font
is only 10 pixels high and the cursor size is programmed with a value
expressing its size from the top down and NOT from the bottom up!
If anyone has a good idea how to solve this problem, please tell me!
The only solution i see so far is having some sort of "generic" cursor
sizes/descriptions (i.e. underline, rectangle, block) which are
recalculated in case of a switch to another line size.


386BSD port
===============================================================================

I don't have access to a 386BSD 0.1 machine anymore so the 386BSD pcvt is
considered unsupported and will disappear in the future.

386BSD support was dropped with release 3.20.


Keyboard hangs after first update of keyboard LED's
===============================================================================

Define PCVT_NO_LED_UPDATE and recompile pcvt. (Or, get yourself a better
keyboard. Some keyboards just don't work the documented way, this fact is
"normally" masked by the manufacturers BIOS but unhides when one accesses
the hardware directly.)


Garbled screen when running vi
===============================================================================

When the terminal speed in the tty structure is set to low speeds (i.e. 1200
Baud), pcvt shows a strange behaviour in some environments due to the changed
screen update sequences from vi.

Please check your shell startup files, /etc/ttys and /etc/gettytab and change
the baudrate (i.e. by using stty(1)) to a higher value, i.e. 19200 Baud.

Since i'm not a vi specialist, i never managed to find out wheter to blame
vi or pcvt.


Stty influences on the driver
===============================================================================

There used to be an entry in the BugList:

        (printf with 9 x tab) printf "\n\t\t\t\t\t\t\t\t\tGotcha" works ok,
        while one tab more: printf "\n\t\t\t\t\t\t\t\t\t\tGotcha" doesn't
        work (it doesn't print Gotcha at column 80, but at column 131).

This was solved some time ago:

        On another note: if I use stty xtabs, the 'printf "\t\t\t\t\t\t\t" 
        bug goes away. With stty xtabs the tab handling is done in the kernel.

(See also below: "Vttest shows strange results")


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.

I stumbled a bit deeper into this with my ELSA Winner 1000, which is equipped
with a ICD2061 clock synthesizer chip. For 132 column mode to work properly,
clock generator 2 must deliver 40 MHz to the S3 VGA chip, but this value has
to be programmed or initialized. If this VGA board has ever been switched
into 132 colums, i.e. in my case from a DOS program, it will continue to do
so until X runs or the machine is power cycled. If that occurs, the clock
generator 2 does contain nothing or garbage (in case of power cycling) or it
does contain the value for the current resolution in X in case of having been
in the X Server screen recently.

The X Server reprograms the clock generator each time the server is entered,
so the only thing to do is to reprogram the clock generator too when pcvt is
entered. Until now i found no way of identifying the clock oscillator chip
used, so an automatic clock switching seems to be a problem.


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 reproducible 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 foreground 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 */