Date: Mon, 13 Aug 2001 02:15:26 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Smith <msmith@freebsd.org> Cc: current@freebsd.org Subject: Re: FreeBSD's aggressive keyboard probe/attach Message-ID: <3B779AAE.3AC31E1B@mindspring.com> References: <200108130020.f7D0KXW01270@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > > 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. > > Ah, so the problem is actually a design defect in the Belkin switch. > Nice to have that part confirmed. Toe-may-toe, Toe-mah-toe. Other vender's hacks are no better; if there's a design defect in the switch, it's that it doesn't take the double scroll-lock, instead of using the LED from the host, such that if it's wedged, you have to manually hit the "next console" button. On the other hand, I can force a console switch from software on a machine by toggling the scroll lock LED, and then forcing the keyboard to send me a key-down for a digit by priming its buffer, which is really handy if you want to do an automated rolling demo for a trade show, etc.. > > The fundamental problem here is that FreeBSD _resets_ a > > keyboard which has already been correctly reset by the BIOS, > > if it is present. > > You can't be sure of this. Just as we reset everything else we > talk to, we reset the keyboard. Specific examples where *not* > resetting things gets us into trouble can typically be found by > looking for "when I reboot from Windows XYZ doesn't work". I think that depowering the thing and repowering it at POST is enough to know its state... The only historical fly in this ointment is that some old systems didn't put a real flip-flop on the CPU reset line, and latch it as a result of getting the keyboard reset command from the keyboard controller. Most of these are using XT keyboards, though, which won't work with any KVM switches out there today, since the controller chip is on the wrong side of the keyboard connector cable. 8-). > > 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. > > No it won't, unless you explicitly configure it. This is the "-P default" case; most people are not running that recent a -current. > > 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. > > This is not the problem, as I have already mentioned in another message. > BIOS vendors have *stopped* setting this bit. I've checked 5 machines, including the Tyan and SuperMicro (the latter is AMI BIOS), as well as my Sony VAIO... all set the bit. That said, I agree that it's not a very good way of detecting a keyboard being out there... 8-(. > > 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. > > Keyboard probing is a dead loss, which is why we don't do it > by default. I wish we could avoid resetting, as well. I think that the BIOS you are seeing not setting the bit has decided to not do the probe, too. That's understandable, given that KVM switches are becoming more and more common: they probably saw the same thing FreeBSD is seeing with these boxes. > > 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. > > There is no standardised way of detecting whether a display > has been "disabled". One gross way that I have never seen fail is to make an INT 10 call to set a standard (the default) video mode, and note that the registers indicate a failure. > > 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. > > We've tried this already; people didn't like it. Well, I think the only option left here is explicit configuration. The boot loader doesn't reset the keyboard, does it? I've never seen the LEDs "flash dance", between the PST and the FreeBSD keyboard probe, anyway. Perhaps we could elect to reset the keyboard from the boot loader, as an option, and not do it by default... > > This would _also_ solve the Alpha serial console dance. > > Actually, it wouldn't, since we use the SRM console for quite a ways, and > SRM doesn't do multi-source console I/O. (And when you have a version of > SRM that allows you to 'pull' the console by sending a few keystrokes, > you can't work out where it's actually directed anyway.) Ugh. I was thinking more in terms of activating both drivers, and sinking both inputs to the same /dev/console... not pretty, either. Cheers, -- 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?3B779AAE.3AC31E1B>