From owner-freebsd-current Thu Aug 16 6:55: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id A11D637B403 for ; Thu, 16 Aug 2001 06:54:17 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f7GDs4c308117; Thu, 16 Aug 2001 22:54:04 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f7GDs4K79847; Thu, 16 Aug 2001 22:54:04 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:GyenW62bhiXoSIHjQ8Uvxqr18IeIO8TS@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id XAA10653; Thu, 16 Aug 2001 23:03:44 +0900 (JST) Message-Id: <200108161403.XAA10653@zodiac.mech.utsunomiya-u.ac.jp> To: current@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: keyboard reset (was: Re: FreeBSD's aggressive keyboard probe/attach) Date: Thu, 16 Aug 2001 23:03:43 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am entering a tricky part now :-) ----------- Keyboard reset Because there are so many complicated issues here, I will start with describing something I know about what BIOS and FreeBSD keyboard driver do. (Beware, this is a long message.) 1. What BIOS does During AT BIOS POST, things happen as follows. Step 1. It sends the reset command to the keyboard. Step 2. It waits for the result code. During this reset operation the embedded controller inside the keyboard will flash LEDs(*1). Step 3. If it doesn't receive the result code, it assumes there is no keyboard. Depending on your BIOS (and BIOS setup), you will get the error message "keyboard not present." Step 4. If it has received the result code, but it signifies an error, you will get an error message too. Step 5. If it has received the result code, and there was no error, the BIOS sends the send-ID command to the keyboard. Step 6. If the keyboard is 101/102 enhanced keyboard (or newer), it will respond with a 2 byte ID code(*2). The original AT 84 keyboard (and some old notebook computers too) doesn't support this command and will report error. Step 7. If the BIOS recognizes this ID code(*2), it will set the bit 4 in the keyboard status byte in the BIOS data area (0x496). Step 8. The BIOS then send the set-LED command. This is typically done to turn the NumLock LED on. Step 9. The BIOS optionally send set-repeat-rate command to set repeat delay and rate which you have specified in the BIOS setup menu. (The original IBM AT didn't have such menu, thus, didn't send this command.) Note *1: we can certainly see the LEDs flash. But, this is not caused by the set-LED command from the host computer. It is by the keyboard's internal routine. In addition, LED flash is not detectable from outside, in an electrical way by the host computer or KVM. There is no signal line in the keyboard cable associated with the LEDs! We should also remember there are some keyboard which doesn't have LEDs. Note *2: a typical ID code is 0x41ab for the US 101 keyboard. But other keyboards may send a different code. If the ID code is not one of those the BIOS knows about, the bit 4 at 0x496 won't be set. If the machine is in warm-boot sequence, the entire above keyboard probe may be skipped. It is also important to note that there is no BIOS service or status byte (or bit) in BIOS data area which tells us the presence or absence of the keyboard. As already pointed out in this mailing list by many people, we cannot rely on the bit 4 at the BIOS data area 0x496 for this purpose; this bit is set only when the keyboard identifies it self as one of enhanced type (12 function keys and separate cursor pad keys) AND the BIOS recognizes its ID code. 2. What FreeBSD atkbd driver does Step 1. the probe routine sends the echo command to the keyboard port. If a keyboard is present behind the keyboard port, it will respond. Step 2. If there was no response, the driver assumes that there is no keyboard and note as such. The driver will fail to install ONLY IF you set bit 0 (FAIL_IF_NO_KBD) in the flags for atkbd. Step 3. If the keyboard is present, then the attach routine first try to retrieve the ID code from the keyboard by issuing the send-ID command. (The returned ID code will be saved.) Step 4. Then the reset command is sent(*1), in order to put the keyboard in known state(*1). (If the keyboard returns error and the FAIL_IF_NO_KBD bit is set in the device flags, the atkbd will fail to install.) Step 5. The set-LED command is sent. It typically set the NumLock LED which was turned off reset in the step 4. Step 6. The set-repeat-rate command is sent. Note *1: if you really don't want to reset the keyboard, you may set the NO_RESET flags to skip it. Note *2: if you warm boot the machine after you used it under another OS, we need to reset the keyboard to put it in known state, in case the BIOS doesn't do so for us. It is true that there is not much room for the other OSes to configure the keyboard in arcane state/mode, but I have seen in some Linux mailing list that someone suggested that they should use the scan code set 3. The atkbd driver uses the scan code set 2 (this is the default after reset), or the set 1 for old ThinkPad keyboards (you need to set the ALT_SCANCODESET in the atkbd device flags for this). Note: all these FAIL_IF_NO_KBD, NO_RESET, and ALT_ACANCODESET flags are documented in the man page for atkbd(4). 3. Difference between the BIOS POST and atkbd Except that the atkbd driver uses the echo command first and that the order of the send-ID and reset commands is different, both do essentially the same thing. 4. So, what the problem with the atkbd driver? I am not convinced that the atkbd driver's behavior is too aggressive. If you say it is, what the BIOS does must also be regarded as too aggressive. I must say that if the atkbd's probe/attach causes the KVM problems because ScrollLock LED is flashed, then, BIOS POST must cause the same problem too. Remember that during both BIOS POST and atkbd probe/attach, LEDs are flashed because of the INTERNAL reset/test routine in the keyboard during the reset command; it is not caused by the set-LED command from the host computer. (Well, if the ScrollLock bit in the BIOS data area was set when the machine first starts, the set-LED command will turn the ScrollLock LED on. But, this is usually not the case.) If you think that the reset command in the atkbd driver is harmful, set NO_RESET in the atkbd driver flags and see if it makes difference. I suspect that what Belkin fixed in their firmware v1.9 was not something about LEDs, but either of the followings: a) Pass any commands from the host computer to the keyboard even if the keyboard is not directed to this computer. Or, b) Process/emulate the reset, echo, send-ID, set-LED, and set-repeat-rate commands (and possibly other keyboard commands) internally in KVM, so that the host computer is made to think a real keyboard is directly connected. As the BIOS POST does essentially the same things as the atkbd driver except for the echo command, my guess is that the reset, send-ID, send-LED and set-repeat-rate commands were already emulated in v1.6 (otherwise you get the "keyboard not present" error during BIOS POST), and the support for the echo command was added in v.1.9. I find it is good for them to make emulation better than before. If they want their KVM to be as transparent as possible both to host computers and to the keyboard, their emulation had better be good and complete. 5. Note on atbkd driver flags FAIL_IF_NO_KBD (0x1) This flag is optional. If it is not set, the atkbd driver DOES install itself even if the AT keyboard is not present, by default. This has been the behavior since our days as far back as FreeBSD 1.X. This flag is currently set in /boot/device.hint. It was added in order to support systems with the USB keyboard only. Because if the atkbd installs when the AT keyboard is not there, syscons will grab it before the USB keyboard becomes accessible. This flag, convinced with the flags 0x100 (AUTO_DETECT_KBD, it's also default in /boot/device.hints now) for syscons, makes syscons search for a keyboard periodically while it isn't using one, and as soon as a USB keyboard becomes available, it will be used. If you attach the second USB keyboard, you cannot use this one (instead of the first one) until the first one is detached. You can force syscons to use the second USB keyboard via kbdconrol. But, it is not automatic. We can improve our current behavior of syscons and keyboard drivers in the following approaches. a) Remove the FAIL_IF_NO_KBD flag from /boot/device.hints. Leave the AUTO_DETECT_KBD as it is now for syscons, so that syscons searches for a keyboard periodically while it isn't using one. Add a script to /etc/usbd.conf to switch to the USB keyboard. This way, the last USB keyboard attached will be the keyboard for syscons. Even if the atkbd driver is present, you will be able to use the USB keyboard. But, you can use one keyboard only at one time. (This was suggested by someone in the past. I don't remember who.) b) Remove the FAIL_IF_NO_KBD flag from /boot/device.hints. Implement a general/virtual keyboard driver which will grab any keyboard devices in the system, combine all the input and forward it to syscons (as John Baldwin suggested recently). This way, we use all the keyboard attached to the system at once. c) Remove the FAIL_IF_NO_KBD flag from /boot/device.hints. Leave the AUTO_DETECT_KBD as it is now for syscons, so that syscons searches for a keyboard periodically while it isn't using one. Make syscons not grab the atkbd driver while the real AT keyboard is not present. Do so only when it becomes available. This way if you plug the USB keyboard before you plug the AT keyboard, the USB keyboard will be used. But, once the AT keyboard is plugged while there is no USB keyboard, it will be the keyboard for syscons and the USB keyboard will never be used, because we cannot detect the removal of the AT keyboard. (You can manually override this via kbdcontrol.) I must admit that I have known these ideas for a long time but not implemented any so far ;-< I always liked the idea b), but haven't designed it yet. Probably the most reasonable thing to do is, in the short run, a). But there still is a snag ;-( Some USB keyboards have a PS/2 mouse connector and identify itself as a USB keyboard AND a USB mouse. The current implementation of usbd(8) doesn't handle this situation well; it find action for one device only, not for both. If this keyboard is detected as ukbd0 and ums0, usbd(8) will execute action for either ukbd0 or ums0, for whichever device a matching entry is found in /etc/usbd.conf first. (The USB keyboard with USB HUB function seems not have this problem, as it appears to identify itself as a HUB with a keyboard attached to it as a child.) c) is easy to implement. So, we can settle for c) until usbd(8) is fixed and a) becomes feasible. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message