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 ] | 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 ] | (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 */