Date: Tue, 08 May 2001 08:45:44 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Ingo Flaschberger <if@sil.at> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: no keyboard Message-ID: <3AF814A8.39E959F5@mindspring.com> References: <Pine.SOL.4.21.0105052051180.16630-100000@ikarus>
next in thread | previous in thread | raw e-mail | index | archive | help
Ingo Flaschberger wrote: > > > > > the problem is, when i connect after the boot a keyboard > > > > at the box, it is not recognized. at the colocations we > > > > often need access to this boxes (not remote access). > > > > is there a solution for this problem? > > > > Note : this is a way to kill your keyboard : an AT keyboard is not > > hot-plug compatible > > i have never killed a keyboard with un / plugging. > at linux it works. I've cooked several. It's not nearly as likely these days; in the original AT days, the controller chip was on board the keyboard itself, and inadequately isolated. Using a KVM switch is roughly tantamount to doing the same thing, only without the static issue. FreeBSD has an extremely annnoying habit of taking a keyboard that has been successfully configured by the BIOS, and then reconfiguring it "destructively" during probe, such that, if there is no KVM hooked up, or there is no keyboard and mouse hooked up, that the keyboard and mouse get "lost". Linux doesn't have this problem, and neither does Windows (I believe from looking at the source to the Windows 98 mouse driver from the DDK CDROM from Microsoft, that the mouse driver periodically resynchronizes "just in case someone uses a KVM switch on me"). It's really, really annoying. At least one company has revised their KVM switch firmware for FreeBSD's peculiar tastes, but you still have to have the KVM switch plugged in at FreeBSD boot time, or it loses its mind. I rather suspect that the mouse issue could be dealt with in moused, with a tiny amount of kernel cooperation. For the keyboard itself, it's really a matter of getting FreeBSD's nose out of the keyboard controller at probe time (I actually think it's the LED code that causes the problem, but that's just my gut feeling on it), and letting the BIOS set it up however it wants it set up, and have FreeBSD adapt to that, instead. I think the destructive probe is probably an artifact of the pre-VM86() days, before we could ask the BIOS if there is a PS/2 mouse port present. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AF814A8.39E959F5>