Date: Sun, 12 Aug 2001 12:13:44 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, Matt Dillon <dillon@earth.backplane.com>, Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>, Sean Kelly <smkelly@zombie.org>, current@FreeBSD.ORG Subject: Re: FreeBSD's aggressive keyboard probe/attach Message-ID: <3B76D568.5DC1603D@mindspring.com> References: <200108112135.f7BLZEb01968@mass.dis.org> <3B75C7B1.FF2E739E@mindspring.com> <15222.44015.177885.83834@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > I have tried 5 switches. At ClickArray, we have a large number > > of Belkin Omniview switches. I have one with firmware version > > 1.9 at my desk, and freqiently use one with firmware version 1.6 > > in our lab, with the results I have described. > > Strange, as the group at Nokia is running quite a lot of them (Belkin > OmniView and OmniCube) without any problems. > > I'm guessing it's operator error. :) You killed the context; v1.9 does _NOT_ have the problem with FreeBSD, since Belkin went out of its way to support FreeBSD. Prior versions _do_ have a problem with FreeBSD, because of the keyboard probe, which, among other things, flashes the "scroll lock" LED. Here is the _precise_ problem with older firmware: The Belkin KVM switch uses the "on->off->on" or "off->on->off" of this LED to signal a port change character is coming next, and times out the port change request only after a little while. The problem was that, while in this state, data from the keyboard which was not one of the numeric key characters was not buffered, and was lost. This included probe data from the keyboard being sent back to the FreeBSD box. The obvious intent of non-buffering was to ensure that if the user wanted to switch to, say, port 3, and they hit the "Scroll Lock" key twice to initiate the toggle, that after a wrong key that was not a console switch key, they could hit the real console switch key, and not have to restart the toggle command. This is particularly onerous, if one has a cascaded control system, since you are required to hit two digits (or the space bar, and then use the cursor keys and "enter" to select a console, or "esc" to abort the selection). -- The fundamental problem here is that FreeBSD _resets_ a keyboard which has already been correctly reset by the BIOS, if it is present. Get rid of the gratuitous reset, and assume that the BIOS has configured the keyboard the same way keyboards have been configured by POST routines since the first IBM PC was built, and the problem goes away for the Belkin KVM with the older firmware. -- The FreeBSD keyboard detection is another matter; FreeBSD will assume that there is no keyboard, and try to "helpfully" drop you into serial console mode. Some of this _used_ to be mitigated by checking for the "extended keyboard bit" in the "keyboard identify" BIOS call, but this was a problem for people with antique keyboards. My suggestion for a probe in this case would be to set up a different handler for the reset signal, and then ask the keyboard to send the reset signal. If it does, then there is a keyboard present. Unfortunately, this will not work with things like the QVM mechanical switch, unless the switch selects the system being booted during reboot. More ideally, the FreeBSD box would detect whether or not the video card had been disabled, and use _that_ to decide whether or not to use a keyboard. It would become the job of the video driver -- be it a regular driver, or be it an LCD driver -- to make the distinction. Absolutely ideally, FreeBSD would come up with the boot code on _both_ (this is an option), and then be told by the user to not use one of them -- or boot using _both_, until told to do otherwise. This would _also_ solve the Alpha serial console dance. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B76D568.5DC1603D>