406 lines
16 KiB
Plaintext
406 lines
16 KiB
Plaintext
FAQ's, Notes and Hints Last Edit-Date: [Tue Oct 3 11:05:55 1995]
|
|
--------------------------------------------------------------------------------
|
|
|
|
How to start the X server at boot time in a dedicated virtual screen
|
|
================================================================================
|
|
|
|
> I'm trying to keep an xdm session open on screen 4 at all times so I
|
|
> don't have to keep starting X whenever I login. However, I don't want
|
|
> the xdm login screen to be the default since I usually prefer
|
|
> character mode screens.
|
|
>
|
|
> I'm using the pcvt console driver and in rc.local I'm doing this:
|
|
>
|
|
> /usr/sbin/scon -c 3 # go to screen 4
|
|
> /usr/X11R6/bin/xdm -daemon # fire up xdm
|
|
> sleep 10 # give xdm some time to start
|
|
> /usr/sbin/scon -c 0 # come back to preferred login screen
|
|
>
|
|
> When I reboot, I see xdm start, come up with the graphical login, then
|
|
> switch back to screen 1. However, if I hit CTRL+ALT+F4, the xdm
|
|
> screen is gone and I'm met with just a blank (character mode) screen.
|
|
|
|
Hmm - I'm doing this all the time with 2.0.5 on the 8th virtual screen.
|
|
|
|
Did you disable the getty for the corresponding screen in /etc/ttys ?
|
|
|
|
You need a configuration for xdm in /usr/X11R6/lib/X11/xdm/Xservers similar
|
|
to this (from my system):
|
|
|
|
:0 local /usr/X11R6/bin/X vt8
|
|
|
|
My (part of) rc.local looks like this for starting xdm at boot time on
|
|
screen 8:
|
|
|
|
[....]
|
|
|
|
# path for xdm (X11R6)
|
|
XDMP=/usr/X11R6/bin
|
|
# path for xdm (X11R5)
|
|
#XDMP=/usr/X386/bin
|
|
|
|
# set to YES to start xdm on screen 8
|
|
xdm_start=YES
|
|
#xdm_start=NO
|
|
|
|
[....]
|
|
|
|
#--------------------------------------------------
|
|
# if desired, start xdm on screen 8
|
|
#--------------------------------------------------
|
|
|
|
if [ X${xdm_start} = X"YES" -a -x $XDMP/xdm ]
|
|
then
|
|
$SCONP/scon -d /dev/ttyv7
|
|
$XDMP/xdm
|
|
sleep 10
|
|
$SCONP/scon -d /dev/ttyv0
|
|
fi
|
|
|
|
|
|
pcvt (german) keyboard remapping not adopted by X server
|
|
================================================================================
|
|
|
|
1) make shure your xterm is able to display national (8-bit) characters,
|
|
i.e. issue something like "stty cs8 -parenb -istrip".
|
|
|
|
2) and more important, in the XFree86 3.x configuration file XF86Config,
|
|
you have to enable the AltGr - Key by uncommenting the line:
|
|
|
|
RightAlt ModeShift
|
|
|
|
in the Keyboard Section.
|
|
|
|
|
|
Keyboard not working with pcvt
|
|
================================================================================
|
|
|
|
From Leo Bicknell (bicknell@ufp.org):
|
|
|
|
I have two systems I am trying to use your PCVT driver on
|
|
running NetBSD 1.0. One is a plain vanilla PC, but it has a
|
|
Northgate Omnikey Ultra programmable keyboard, the other is a IBM
|
|
Thinkpad 755c laptop. Both exhibit the same behavior. Under scan
|
|
set 1 they both are completely broken. Virtual consoles don't work
|
|
at all, in fact on the laptop none of the keys work properly.
|
|
|
|
After using PCVT_SCANSET=2 both keyboards are running (-hm).
|
|
|
|
|
|
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)
|
|
|
|
Scancode 2 is also reported to work for a Thinkpad 755c (-hm)
|
|
|
|
|
|
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 to compile pcvt with:
|
|
|
|
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 */
|