Date: Sat, 11 Aug 2001 17:26:57 -0700 From: Mike Smith <msmith@freebsd.org> To: tlambert2@mindspring.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: <200108120026.f7C0Qvb03574@mass.dis.org> In-Reply-To: Your message of "Sat, 11 Aug 2001 17:02:57 PDT." <3B75C7B1.FF2E739E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > :Finally, most keyboard/mouse/monitor switches don't work with
> > > :FreeBSD;
> >
> > This is actually not true. I'd doubt that you've even tried many of them.
>
> Boy, you are on one about me...
Make like less of a target, and you're less likely to be shot at...
> ...And you are ignoring the major point, which is that FreeBSD
> should work with _all hardware Windows works with_, and that in
> doing so, _it should work at leasty as well or better_.
"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.
In addition, we don't have the resources to do this.
> > The Belkin switch is hardly the "best" out there; it's also the only KVM
> > switch that I'm aware of that had problems with FreeBSD, and even then
> > only because their QC is so poor that they managed to ship the product
> > with the ROMs _reversed_.
> >
> > 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?
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.
> 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.
> > > :Belkin went out of its way to support FreeBSD specifically,
> > > :actually: their firmware version 1.9 fixes the local wiring
> > > :switches, so that they can pass FreeBSD's aggressive probe, even
> > > :if the FreeBSD mouse/keyboard is _not_ selected.
> >
> > 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.
> 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.
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.
> > 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.
Then go read the commit message where we pulled -P as the default for
boot2. And if you have any bright ideas that are substantiated by
reality, I'm sure we'd be happy to listen.
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).
> 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.
> I guess I'll wait for your commits to dike out the
> "F00F" bug workaround and the CMD640 IDE controller interrupt
> problem, in answer...
Ah, yes. I'm such a demon for gutting our support for hardware, aren't I?
A pity that Australians don't have a reputation for wielding axes;
somehow the image of me hacking away at the source tree with a boomerang
just isn't quite as bloodcurdling...
As I suggested before, Terry; stick to things you understand, and avoid
making sweeping statements without considering your justifications
carefully.
--
... 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?200108120026.f7C0Qvb03574>