Date: Mon, 18 Nov 1996 17:10:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, yokota@zodiac.mech.utsunomiya-u.ac.jp, current@FreeBSD.org, nate@mt.sri.com, sos@FreeBSD.org Subject: Re: UserConfig is broken + PS/2 support success Message-ID: <199611190010.RAA07981@phaeton.artisoft.com> In-Reply-To: <199611171718.EAA22673@godzilla.zeta.org.au> from "Bruce Evans" at Nov 18, 96 04:18:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. It should be noted that Windows 95's VKD code (again, from the DDK) does a keyboard disable during the mouse probe phase, and goes so far as to call VPICD_Physically_Mask and VPICD_Clear_Int_Request to insure no one can do anything to the keyboard in the interim. Since if the probe is false, these bits are restored by the PS/2 mouse (Virtual Auxillary Device, or VAD) driver, I don't think this will damage the PS/2 mouse case. Maybe if the mouse is not probed true, these bits could be restored to their previous values? This would fix your complaint about XT keyboards on non-MCA keyboard controller chips. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611190010.RAA07981>