From owner-freebsd-current Mon Nov 18 22:00:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA17989 for current-outgoing; Mon, 18 Nov 1996 22:00:08 -0800 (PST) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA17901; Mon, 18 Nov 1996 21:59:56 -0800 (PST) Received: by nasu.utsunomiya-u.ac.jp (5.57/ULTRIX-940302) id AA14386; Tue, 19 Nov 96 14:57:41 +0900 Received: by outmail.utsunomiya-u.ac.jp (5.57/ULTRIX-940909) id AA29455; Tue, 19 Nov 96 14:57:39 +0900 Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.33.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id PAA03041; Tue, 19 Nov 1996 15:00:30 +0900 (JST) Message-Id: <199611190600.PAA03041@zodiac.mech.utsunomiya-u.ac.jp> To: Bruce Evans Cc: current@freebsd.org, nate@mt.sri.com, sos@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: UserConfig is broken + PS/2 support success In-Reply-To: Your message of "Mon, 18 Nov 1996 04:18:12 +1100." <199611171718.EAA22673@godzilla.zeta.org.au> References: <199611171718.EAA22673@godzilla.zeta.org.au> Date: Tue, 19 Nov 1996 15:00:29 +0900 From: Kazutaka YOKOTA Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>According to his book, the bit 5 and 1 of the keyboard command byte >>are related to the PS/2 mouse but are treated differently for the >>ISA/EISA systems and the MCA systems (p.304-305): >> >>ISA/EISA >>bit 5 0 Check parity form keyboard, with scan conversion (0 is >> normal operation). >> 1 Ignore parity from keyboard, no scan conversion. >... >I think I know what bit 5 does: setting it makes XT keyboards work. XT >keyboards send scancodes that don't need any conversion (see Van Gilluwe). >However, I couldn't get this to work in practice for an old keyboard with >an XT/AT switch. Neither the BIOS nor standard syscons nor syscons >tweaked to set the bit can see the keyboard in XT mode, and the tweaked >syscons can see the keyboard in AT mode. Perhaps my keyboard controller >is MCA compatible. As far as I understand, the bit 5 does not turn on/off conversion by itself. It must be used in conjunction with the bit 6 which, I think, is the bit to control the scan code translation/conversion. bit 6 0 No conversion of keyboard scan codes. 1 Standard Scan conversion - the scan code from the keyboard is converted into the normal scan codes used in PCs (1 is normal operation). MCA Type 2 controllers cannot set this bit to 1. In this case scan code conversion is set using keyboard command F0h to port 60h. This applies to both ISA/EISA systems and MCA systems (Van Gilluwe, p304-305). My understanding on scan code sets and conversion is as follows (is this right?): The bit 5 should be set/reset according to the keyboard device attached to the system. The XT keyboard sends scan codes without the parity bit. The AT keyboard, on the other hand, sends them with the parity bit. In addition, the AT keyboard can send three different sets of scan codes: set 1 XT scan code set set 2 AT scan code set (default) set 3 for manufacturing test? So, I think we can have the following hardware combinations to get XT scan codes: 1. XT keyboard with an ISA/EISA style keyboard controller The keyboard sends XT scan codes without the parity bit, thus, we should set: bit 6 - 0, bit 5 - 1. 2. AT keyboard with an ISA/EISA style keyboard controller 2.1 If the keyboard is programmed to use the scan code set 2 The keyboard sends AT scan codes with the parity bit; bit 6 - 1, bit 5 - 0. 2.2 If the keyboard is programmed to use the scan code set 1 The keyboard sends XT scan codes with the parity bit; bit 6 - 0, bit 5 - 0. 3. AT keyboard with a MCA style keyboard controller 3.1 If the keyboard is programmed to use the scan code set 2 The keyboard sends AT scan codes with the parity bit: bit 6 - 1 3.2 If the keyboard is programmed to use the scan code set 1 The keyboard sends XT scan codes with the parity bit: bit 6 - 0 I guess it is not possible to use the XT keyboard with the MCA style keyboard controller, because parity checking cannot be turned off on this controller. Most AT systems, except some ThinkPad models?, operate in 2.1 or 3.1 above. The `syscons' driver can be flagged to make the keyboard to send the scan code set 1; this corresponds to the cases 2.2 and 3.2. >>>3. KBDS_CONTROLLER_BUSY 0x0002 >>>aka KBS_IBF 0x02 >> >... > KBS_OBF (1) /* KeyBoard Status [reg] [any] Output Buffer Full */ > KBS_IBF (2) /* KeyBoard Status [reg] Input Buffer Full */ > KBS_OBF_AUX (0x20) /* KBS_OBF for Aux port */ > >I prefer not to OR bits together in #defines. I think you are referring to: #define KBDS_BUFFER_FULL 0x0021 #define KBDS_ANY_BUFFER_FULL 0x0001 #define KBDS_KBD_BUFFER_FULL 0x0001 #define KBDS_AUX_BUFFER_FULL 0x0021 #define KBDS_CONTROLLER_BUSY 0x0002 I intended to use these constants in the following ways: To test if a keyboard data byte is available if (inb(status_port) & KBDS_BUFFER_FULL) == KBDS_KBD_BUFFER_FULL) To test if a mouse data byte is available if (inb(status_port) & KBDS_BUFFER_FULL) == KBDS_AUX_BUFFER_FULL) To test if a keyboard OR mouse data byte is available if (inb(status_port) & KBDS_ANY_BUFFER_FULL) != 0) If we use: #define KBDS_AUX_BUFFER_FULL 0x0020 and undef KBDS_BUFFER_FULL, then these tests have to be: if (inb(status_port) & (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL)) == KBDS_KBD_BUFFER_FULL) if (inb(status_port) & (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL)) == (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL)) if (inb(status_port) & (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL)) != 0) The first and the third tests look all right. But the second test looks less intuitive to me than before. Kazu