diff options
Diffstat (limited to 'usr.sbin/pcvt/Misc/Doc/NotesAndHints')
| -rw-r--r-- | usr.sbin/pcvt/Misc/Doc/NotesAndHints | 321 |
1 files changed, 321 insertions, 0 deletions
diff --git a/usr.sbin/pcvt/Misc/Doc/NotesAndHints b/usr.sbin/pcvt/Misc/Doc/NotesAndHints new file mode 100644 index 0000000..725831a --- /dev/null +++ b/usr.sbin/pcvt/Misc/Doc/NotesAndHints @@ -0,0 +1,321 @@ +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 */ |
