Date: Sun, 17 Nov 1996 18:08:43 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org, sos@freebsd.org, nate@mt.sri.com, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: UserConfig is broken + PS/2 support success Message-ID: <199611170908.SAA01967@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Sun, 17 Nov 1996 11:27:16 %2B1100." <199611170027.LAA00201@godzilla.zeta.org.au> References: <199611170027.LAA00201@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, my name is Kazu. I have been working on the `psm' driver and recently wrote the `kbdio' module to provide a set of common I/O routines to be used both with the `syscons' and `psm' drivers. I suggested to S'ren Schmidt and Nate Williams that we start with these routines and improve them. To this end I need reports and comments, and found yours variable. Please note these routines currently does NOT do queuing (as Nate Williams suggested) or check `ipending' (as you have suggested). It doesn't mean these ideas have been rejected or found infeasible; it simply means they haven't been tried, just yet. >Some of the flags and flags testing seem to be wrong: > >1. KBD_DISABLE_AUX_PORT 0x20 > >According to Van Gilluwe, on ISA/EISA keyboards setting this gives: >"Ignore parity from keyboard, no scan code conversion" [not the default]. >This is now used. It seems to be harmless. It was also used in pccons. >It is still defined in /sys/i386/isa/ic/i8042.h (which is where all the >i8042-specific defines should always have been) as > > KC8_OLDPC 0x20 /* old 9bit codes instead of new 11bit */ I have a copy of: Van Gilluwe, "The Undocumented PC", Addison-Wesley, 1994. 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. bit 1 Unused, set to 0. MCA bit 5 0 Enable mouse. 1 Disable mouse by forcing the mouse serial clock line low. Data cannot be sent to or received from the mouse. bit 1 0 Do not send interrupt when mouse output buffer full. 1 Mouse output buffer full causes interrupt (IRQ 12). Now, the question is which speicification modern non-MCA mother boards follow and we should honor. MBs with the PS/2 mouse port I own all seem to follow the later specification. Another, relatively recent MB also has no problem setting/clearing these bits even though it has no mouse port. I also tested an old 386 MB without the mouse port and found no problem. These experiences led me to believe that it's OK to manipulate these bits if a PS/2 mouse exists in the system, and is *probably* safe too with old MBs and MBs without the mouse port if they are touched sparingly. So, I use these bits to enable/disable mouse port and interrupt, but they are so manipulated only 1) when the keyboard is being probed, 2) when the mouse is being probed and reset, 3) when the mouse device is opened or closed after a mouse is found. During the keyboard probe (`scprobe()'), these bits are touched to disable the mouse, but they are restored to the state as it was when `scprobe()' was called. During the mouse probe (`psmprobe()'), these bits are touched to disable mouse interrupt, and will be manipulated thereafter only if a mouse is found (in `psmopen()' and `psmclose()'). If no mouse is found, these bits are restored to the state as it was when `psmprobe()' was called. >2. KC8_IGNSEC 0x08 /* ignore security lock */ [in i8042.h] > >This silently went away. Now syscons honors the security lock switch like >most drivers. The PROBE_KEYBOARD_LOCK feature in the bootstrap works >better with old buggy behaviour. Oh, I didn't know the keyboard lock switch should be ignored. The bit should be set then... >3. KBDS_CONTROLLER_BUSY 0x0002 >aka KBS_IBF 0x02 > >According to Van Gilluwe and all other docs and drivers that I've seen, >this bit is for "The motherboard controller's input buffer is full ... >no writes should occur to ports 60h or 64h or the data/command will be >lost". It has nothing to do with the controller's output buffer (i.e., >scancodes for the driver to read). No, it has nothing to do with the output buffer. I wrote the I/O routines to test this bit to avoid writing to the keyboard controller while this bit is on. Isn't this the right action to take? If you think the name "KBDS_CONTROLLER_BUSY" is inappropriate or misleading, we shall change the name. After all, English is not my native tongue, I am not good at naming. >This bit is spun on for up to 100 >msec in wait_while_controller_busy() which is (incorrectly) called from >read_kbd_data_no_wait(). Not good for a no-wait routine in an interrupt >handler. You are right!! `wait_while_controller_busy()' is called from `read_controller_data()',`read_kbd_data()',`read_kbd_data_no_wait()', and `read_aux_data()', and this is useless. Should be removed. >Calling it a "busy" bit encourages this error. Ok, let's change the name. >The wait_until_controller_is_really_idle() function seems to be unusable. >E.g., when it use used for a LED update,, interrupts are disabled, so it >is guaranteed to spin if a scancode arrives. The LED update will succeed >after a delay of a couple of hundred msec because it ignores the return >code. > >The empty_*_buffer*() functions are broken. They miss scancodes that >arrive a microsecond after the test and are almost certain to miss >all but the first of a bunch of scancodes - the controller is unlikely >to be able to deliver another scancode on the 0-20 usec delay time, >especially if the keyboard is a few msec away from sending it! See >pcvt_kbd.c for a working version (which is unsuitable for general use >because of the lengthy spinloop). Well, these points are tricky parts. We certainly don't want mouse data gets in our way when programming the keyboard, and keyboard data gets in our way when programming the mouse too. In addition, we sometimes want the keyboard and/or mouse data is drained so that the next byte in the controller's output buffer is definitely the responce to a command. I will look at `pcvt_kbd.c' and think what I can do... >write_kbd_command() ignores the return code from >wait_until_controller_is_really_idle(). Apart from the buggy interface >(see above), this is critical for issueing the reset command - it is >possible for the keyboard to hang and resetting it fixes it. I think >the return code should not be ignored for other commands - the keyboard >should be reset and reinitialized in this case. You certainly have a point. Sloppy programming on my part. >The 7us delays that are said to be necessary for MCA keyboards aren't >there. I will put the delay before any read from the data port (60h). I will contact S'ren Schmidt and Nate Williams to discuss your points. Kazu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611170908.SAA01967>