Subject: nwscons additions
To: None <current-users@NetBSD.ORG>
From: Matthias Drochner <email@example.com>
Date: 06/12/1998 01:44:53
[This is probably only of interest for i386, but because the changes
are in mi code, I'll post it here.]
I've just added some code and options to the new wscons code,
which allows to emulate enough of PCVT, FreeBSD syscons
and the Linux console to get X servers and sdoom running.
It's still experimental, in particular I thing that more checks
and some locking must be added to make it work reliable with
not so well-behaving clients. (sdoom is at the limit, at least
with libvga.so.1.2.9 -- more below)
The new kernel config options are:
-WSDISPLAY_COMPAT_PCVT: compatibility to
PCVT (NetBSD, FreeBSD). Only useful with
WSDISPLAY_COMPAT_USL and WSDISPLAY_COMPAT_RAWKBD.
-WSDISPLAY_COMPAT_SYSCONS: compatibility to
syscons (FreeBSD). Only useful with WSDISPLAY_COMPAT_USL
-WSDISPLAY_COMPAT_USL: support for process-synchronized
VT switching and the other common ioctls.
-WSDISPLAY_COMPAT_RAWKBD: support for access to
raw keyboard data (which does not fit too well into the nwscons
framework, but is necessary for these emulations)
The Linux emulation can make use of WSDISPLAY_COMPAT_USL
and WSDISPLAY_COMPAT_RAWKBD. Additionally, I have
added support for KDGKBENT ioctl which gets the kernel's
keyboard mapping to userland. I don't know if this is really necessary
if one can use xkb. At least it allows an X server to be usable without
much thinking... The implementation is sub-optimal, it does not
really use the kernel keyboard map because this would require
some interface change in the wskbd part.
sdoom does only work in the first virtual console. It (not really -
this is libvga) does set the keyboard for "/dev/console" to raw mode
and uses then a "/dev/ttyN" device for reading. That's obviously
not written with portability in mind, and I don't like to screw up
a differently designed console framework to support that kind
How to get it working?
0. Have a boot floppy at hand because it's hard fo fix things
if the console ends up unusable.
1. Make a kernel with nwscons and WSDISPLAY_COMPAT_*.
If you have a PS/2 mouse, use the old mouse driver ("pms* at pckbc?").
2. Create device special files, eg:
crw------- 1 root wheel 47, 0 Jun 11 23:41 /dev/wsd0_0
crw------- 1 drochner tty 47, 1 Jun 11 22:49 /dev/wsd0_1
crw------- 1 root wheel 47, 2 Jun 11 22:40 /dev/wsd0_2
crw------- 1 root wheel 47, 3 Jun 11 22:40 /dev/wsd0_3
crw-r--r-- 1 drochner ca1 47, 4 Jun 7 13:43 /dev/wsd0_4
crw-r--r-- 1 drochner ca1 47, 5 Jun 7 13:44 /dev/wsd0_5
(The wsd* names are not the right thing, finger & Co. can't
handle them. Use ttyX* names if you want to do better.)
3. Add entrys in /etc/ttys, eg:
wsd0_0 "/usr/libexec/getty Pc" sun on secure
wsd0_1 "/usr/libexec/getty Pc" sun on secure
wsd0_2 "/usr/libexec/getty Pc" sun on secure
wsd0_3 "/usr/libexec/getty Pc" sun on secure
4. Set up links for compatibility:
lrwxr-xr-x 1 root wheel 6 Jun 7 13:43 /dev/ttyv0 -> wsd0_0
lrwxr-xr-x 1 root wheel 6 Jun 7 13:43 /dev/ttyv1 -> wsd0_1
lrwxr-xr-x 1 root wheel 6 Jun 7 13:43 /dev/ttyv2 -> wsd0_2
lrwxr-xr-x 1 root wheel 6 Jun 7 13:43 /dev/ttyv3 -> wsd0_3
lrwxr-xr-x 1 root wheel 6 Jun 7 13:44 /dev/ttyv4 -> wsd0_4
lrwxr-xr-x 1 root wheel 6 Jun 7 13:44 /dev/ttyv5 -> wsd0_5
For Linux, this works for me:
bash$ ls -l /emul/linux/dev
lrwxr-xr-x 1 root wheel 4 Jun 8 21:13 console -> tty0
lrwxrwxrwx 1 root wheel 9 May 5 16:58 mouse -> /dev/pms0
lrwxrwxrwx 1 root wheel 9 May 5 16:58 null -> /dev/null
lrwxr-xr-x 1 root wheel 8 May 29 13:58 tty -> /dev/tty
lrwxr-xr-x 1 root wheel 11 Jun 7 18:00 tty0 -> /dev/wsd0_0
lrwxr-xr-x 1 root wheel 11 Jun 11 19:13 tty1 -> /dev/wsd0_0
lrwxr-xr-x 1 root wheel 11 Jun 11 19:13 tty2 -> /dev/wsd0_1
lrwxr-xr-x 1 root wheel 11 Jun 11 19:13 tty3 -> /dev/wsd0_2
lrwxr-xr-x 1 root wheel 11 Jun 11 19:13 tty4 -> /dev/wsd0_3
lrwxr-xr-x 1 root wheel 11 Jun 11 19:14 tty5 -> /dev/wsd0_4
lrwxr-xr-x 1 root wheel 11 Jun 11 19:14 tty6 -> /dev/wsd0_5
Note that tty[1-6] point to the screens 0-5.
5. Play, report what works and what not.