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