192 lines
7.6 KiB
Plaintext
192 lines
7.6 KiB
Plaintext
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 */
|