Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!howland.reston.ans.net!xlink.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: does XFree86-1.3 and/or codrv actually work?
Message-ID: <1993Jun29.090254.10877@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD - German National Research Center for Computer Science
References: <1993Jun28.072719.16216@qualcomm.com> <1993Jun28.102903.12571@gmd.de> <1993Jun28.201522.15048@qualcomm.com>
Date: Tue, 29 Jun 1993 09:02:54 GMT
Lines: 84
In article <1993Jun28.201522.15048@qualcomm.com>, karn@unix.ka9q.ampr.org (Phil Karn) writes:
|> In article <1993Jun28.102903.12571@gmd.de>, veit@mururoa.gmd.de (Holger Veit) writes:
|> |> Codrv does not expect the system to be in scan mode 2, it actually switches
|> |> it into this mode (in kbd_warmreset()).
|>
|> I spent most of yesterday scrutinizing this function in great detail,
|> and I didn't see anything that looked like it would set the keyboard
|> into scan mode 2. According to my copy of the IBM AT reference, you do
|> that by sending the two byte sequence (0xf0, 2) to the keyboard. I
|> even tried adding that code myself, but all I got back from the
|> keyboard was 0xfe (bad command, resend).
This is certainly not from the IBM AT tech. ref. man. This is possibly a
code understood by PS/2 controllers. But this is not downward compatible.
The recommended way is the one you yourself describe below.
|>
|> I think it's clear I don't understand how the keyboard and i8042
|> controllers really work (not surprising considering their wretched
|> design and IBM's abysmal documention). In particular, I guess I don't
|> understand what functions are done in the 8042 and which in the
|> keyboard. From the IBM documentation, I got the impression that the
|> keyboard itself accepted the scan code set command, but then there's
|> brief mention of the two bits in the 8042 command word (Bit 6, IBM PC
|> Compatibility mode, and Bit 5, IBM PC mode) that implies that the 8042
|> gets involved in scan code translation, one of which you set when
|> XTKBDMODE is defined. Now I'm thoroughly confused. Is there a better
|> explanation of this stuff than the IBM manual?
I haven't seen a good source for that except the BIOS source. But in particular
the setting stuff is not used very frequently. The bits 5 and 6 in the
command word have the following meaning (from memory, so bits may be swapped):
Bit 6 changes the data transmission protocol from the controller to the
keyboard to XT-mode. XT and AT keyboards use different protocols (9 bit vs 11 bit),
and this bit allows to connect a XT keyboard to an AT pc (provided the BIOS
supports this).
Bit 5 sets the translation mode for the scan codes back to the old scan 1 style.
For AT-8042 controllers scan mode 2 is the default, but due to the general
"compatibility" nonsense, every BIOS falls back to emulating a XT keyboard
to the user side. This is the bit KC8_TRANS which is set for XTKBDMODE.
The AT reference manual does distinguish between commands sent to the controller
and interpreted by it and commands passed directly to the keyboard. The bits
set here are interpreted by the 8042, and I think the 8042 also does the
scan code translation (just for remaining compatible to XT keyboards which
do not know the later modes).
|>
|> |> You can compile the kernel with options XTKBDMODE; in this case codrv
|> |> uses scan 1 codes and translates them to the internal form used.
|>
|> I tried this, but it didn't make any difference. Maybe I don't have a
|> correct version of codrv? I got it from the 0.2.4 patchkit, but I see
|> that it hasn't made it to many of the standard archive sites (like agate)
|> so I began to wonder if it had been revoked due to problems.
With the exception of a correction in MAKEDEV the pk version is identical
to codrv-0.1.2-110593.tar.z, which is the current version available from some
archives, e.g. bsd.coe.montana.edu. agate had a version in /pub/incoming; I
don't know whether it has been moved to elsewhere. You can install the
three codrv related patches (see pk-0.2.4-index, I think they were 160,161,162)
independently from the rest of the patchkit, if you suspect problems with
the rest of the patchkit (e.g. the npx or int code).
|> |> Maybe the system you have is no longer exactly 386bsd-0.1-srcdist+patchkit,
|> |> but was modified by several other patches.
|>
|> This is possible. I had been running syscons, which is not in the standard
|> patchkit track, so it's possible that some of the other patches didn't
|> do the right thing. I eventually punted and went all the way back to 386BSD
|> version 0.1 and applied patchkit 0.2.3. This got me a usable kernel, and
|> once I re-created /dev/vga as something other than a link to /dev/console,
|> XFree86-1.3 started working fine.
|>
|> Phil
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Had a nightmare yesterday:
| |/ Schloss Birlinghoven | My system started up with
DW-5205 St. Augustin, Germany | ... Booting vmunix.el ...