Date: Mon, 18 Nov 1996 04:18:12 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, yokota@zodiac.mech.utsunomiya-u.ac.jp Cc: current@FreeBSD.ORG, nate@mt.sri.com, sos@FreeBSD.ORG Subject: Re: UserConfig is broken + PS/2 support success Message-ID: <199611171718.EAA22673@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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. OK. Queueing will take a fair amount of work to get right. The `ipending' hack isn't necessary now that the driver knows how to distinguish keyboard scancodes from mouse scancodes. >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. >... >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. 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. >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. Yes, this is OK. scprobe() was hard to debug with the keyboard turned off :-]. I usually use a serial console to debug keyboard drivers, but I want all console code to be as reentrant as possible. sccngetc() breaks after scprobe() disables the keyboard. I also tried `n' in ddb after stopping at a breakpoint at scprobe(). This took about 1 million instructions and a long time to return. Perhaps the polling routines were confused by the scancode for the key release after `n'. I noticed some unnecessary function calls in scprobe(): - empty_both_buffers() isn't necessary. reset_kbd() does it better. - wait_while_controller_busy() isn't necessary. send_kbd_command_and_data() should have already read all the response codes, and there will be a wait before sending the next command anyway. >>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... I think it should not be ignored. The change should just be kept in mind in case anyone cares. Now that the command byte is mostly preserved, the BIOS default is preserved. >>3. KBDS_CONTROLLER_BUSY 0x0002 >>aka KBS_IBF 0x02 > >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 Yes. >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. I would put INPUT_BUFFER or IB in its name somewhere, and OUTPUT or `O' in the names of the other buffers. This makes the names too long :-). I would probably use: 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. >>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... It should work to drain for 10-20msec and then ignore unexpected scancodes. I think draining was originally introduced because the driver (pccons in 386BSD) didn't ignore unexpected scancodes. Draining also gets rid of stale response codes. After draining once there should be no more stale response codes provided you wait long enough for the new commands. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611171718.EAA22673>