Date: Sat, 11 Aug 2001 17:44:47 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Smith <msmith@freebsd.org> Cc: 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: <3B75D17F.1EE4C602@mindspring.com> References: <200108120026.f7C0Qvb03574@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I should wait on this, but... Mike Smith wrote: > "should", eh? And in the next breath, you'll switch to your other tune, > which is that FreeBSD should "do it right". > > The two simply aren't compatible. Says you. > In addition, we don't have the resources to do this. I wonder why that is? > > > Not that it needs stating, but I've used FreeBSD with a wide range of KVM > > > switches over the years; I'm writing this through an 8-port Cybex, for > > > example. > > > > This switch emulates the keyboard controller to the point that > > it looks as if a keyboard is present at all times to the connected > > system, even if it's not. > > "This" switch being what? The subject of the previous paragraph, per standard English syntax as regard use of perpositional phrases: "an 8-port Cybex". > Note that I have a selection of rotary-switch KVMs here; they all work > with FreeBSD. They sure as shit don't emulate a keyboard controller. Which, as with my QVM switch, I am sure you compensate for, either by switching the machine active when rebooting (not an option in a colocation facility), or by purchasing above-average motherboards, the list of which you have not lowered yourself to share with the rest of us. > > People who run *Free*BSD are going to run it on cheaper equipment; > > evidence the amount of effort that has gone into ATA/IDE support. > > People who run FreeBSD don't actually typically complain about KVMs, > interestingly enough. Matt did. I did. Roland Hsu did. For everyone who complains, there are probably 20 who shut up and live with it. > > > Gosh. How painful that we actually expect the hardware to behave like, > > > well, hardware. > > > > Windows doesn't have the problem on the same hardware. Therefore > > it is not a hardware problem, since it can be resolved in software. > > Ah, yes. Your steering wheel doesn't turn to the right. People who only > make left turns don't have any problems, so it's clearly something wrong > with your driving style. And you expect that 125MPH should not result in a speeding ticket, because, after all, your car is manufactured to be up to it... > > To put it another way: it is the _job_ of software to make up > > for bad hardware design. > > Yes. To a point. Beyond that point, well shit, you just can't use that > hardware. Then you and I simply draw the line at a differnt place: I draw it at being able to use Tyan Tiger and Supra Micro motherboards, with Belkin switches -- all commodity hardware -- without problems, and you draw it elsewhere. > The big difference here is that you get an opportunity to address these > software deficiencies yourself. I for one would be delighted if you > actually *did* occasionally, rather than just puling about it. And I would be delighted if you'd commit my damn patches, instead of saying "well, this patch is unnecessary, since it works on the hardware I buy: you should just buy better hardware, like me". > > > You are smoking crack again. "Use the BIOS" for what? Keyboard input? > > > Get real. > > > > For hardware probe, which occurs at PSOT time anyway, or DOS or > > Windows would not be able to make a BIOS call to ask if the > > hardware were there. > > *snort* Now, you are going to tell me what this BIOS function is, > aren't you? Come on. Look it up. Then go test it on a few systems, and see > whether it tells you that there's a keyboard there. I believe that if you lookes at *MIKE SMITH'S* code in the boot loader, you would be able to find it... > Then go read the commit message where we pulled -P as the default for > boot2. I've never used it as the default option, but I've sure as heck put it in machines /boot.config since it was yanked. > And if you have any bright ideas that are substantiated by > reality, I'm sure we'd be happy to listen. Read the Linux and Widnows drivers source code, for a start; you do have a copy of "Sourcer" from V Communications, don't you? If you don't, if you will commit to fixing the problem, I will happily buy you one, to be presented the next time I see you (or shipped; your option). I will do the same thing for the first 10 people in Germany or another country that allows reverse engineering for purposes of documenting interface definitions, provided they promise to write FreeBSD drivers for the hardware. It will be a couple of thousand dollars well spent. > Neither DOS nor Windows make BIOS calls to "see if the keyboard is there". > Otherwise, neither of them would work when you boot without a keyboard > attached, and then install one. They both do (as does FreeBSD, > incidentally). Make it work with my Belkin in the lab with a 1.6 firmware, and with the ethernet Belkin in the labe (both of which work with both Windows and Linux), and you will have a convert to the Church Of Mike. > > Put it another way: should FreeBSD snub hardware because "it's > > not up to our standards, even though it can be made to work with > > software"? > > There are times when this is the correct approach, yes. It all depends > on the justification for the decision. Ugh. This is the "expediency over correctness" argument. > ... 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 -- 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?3B75D17F.1EE4C602>