Date: Sun, 12 Aug 2001 17:20:33 -0700 From: Mike Smith <msmith@freebsd.org> To: tlambert2@mindspring.com Cc: current@FreeBSD.ORG Subject: Re: FreeBSD's aggressive keyboard probe/attach Message-ID: <200108130020.f7D0KXW01270@mass.dis.org> In-Reply-To: Your message of "Sun, 12 Aug 2001 12:13:44 PDT." <3B76D568.5DC1603D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
> 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".
> 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.
> 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.
> 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.
> 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".
> 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.
> 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.)
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
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?200108130020.f7D0KXW01270>