Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: Why to not buy Matrox Millennium
Date: Sun, 21 Apr 1996 17:56:16 -0700
Organization: Me
Lines: 458
Message-ID: <317AD930.2088AE6D@lambert.org>
References: <3170348D.4496D9F1@lambert.org> <stephenkDq2BCK.B40@netcom.com> <3176AFE0.28146F7@lambert.org> <stephenkDq3B99.FDq@netcom.com> <31785BB6.99F81FD@lambert.org> <4la0hg$j6h@solaris.cc.vt.edu> <3179639A.7B782E0E@lambert.org> <4ld1l3$bem@solaris.cc.vt.edu>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14728 comp.os.linux.development.system:22021 comp.os.linux.x:29944 comp.os.linux.hardware:36950 comp.os.linux.setup:51581 comp.unix.bsd.386bsd.misc:771 comp.unix.bsd.bsdi.misc:3418 comp.unix.bsd.netbsd.misc:3267 comp.unix.bsd.freebsd.misc:17892
erik@fenris.campus.vt.edu wrote:
] A PAL, or Programmable Logic Array, is a very generic way to refer to
] a whole class of devices. Also, PALs are seldom, if ever, used in a
] manufactured design because of their greater cost.
Then you were wrong, and I *did* mean PAL. I really don't give a
damn what get's changed at the same time the BIOS gets changed,
it's that the data in the BIOS describing the change is not
available to the protected mode driver (because it does not use
the BIOS) which is the important fact.
I really don't care if that information is related to the PCB
card clor going from green to orange, if the drivers need to know
about the change and have no way of determining that it has
taken place (even though the BIOS *could* tell them but does not
choose to because of its poor design).
] : Now let's look at what their supposedly "magic" card design
] : does for them: it lets them use firmware to upgrade their
] : card capabilities without changing component layouts or
] : redoing artwork.
]
] I actually don't recall this. My understanding was that they
] kept upgrading their card capacities by making cards with
] newer chipsets, ranging from the ET4000, to the S3C805 to the
] newer, spiffier S3's. None of the 'magic' was to really do
] with the firmware.
Please read the original SunSite README for patching the XFree86
server software to operate with Diamond cards.
] : The firmware consists of a BIOS ROM and a RAMDAC (or an
] : EEPROM, as you suggest, and a PAL, as I suggested, would work
] : to provide the same design results).
]
] *BLINK* I suppose this must be my penance for something in a
] past life.
Or a past posting, where you insisted that "PAL" was an improper
term. I'll use whatever idiotic terms you want to use so long
as we can get you out of "semantic nitpick" mode and into
discussing the topic instead of discussing how best to discuss
the topic.
I'm not interested in engaging in a terminology meta-discussion
with you. Call the piece that gets changed out with the ROM
a "blipvert" for all I care.
The point is that there are two matched pieces, one of which
is only (currently) useful to BIOS-using systems because of
bad software design.
] XFree86 had the means to work on the cards before Diamond
] released info.
No, it did not. The XFree86 group specifically *refused* to
integrate the Sunsite patches into the XFree86 source base,
much in the same way David's posting starting this thread
stated that they would refuse to integrate patches based on
a reverse engineering of the Matrox card.
] : Now why didn't Diamond disclose protected mode programming
] : information for the cards if they were not actively
] : protecting intellectual property through their non-disclosure
] : (which is what most net.idiots thought they were doing:
] : simply keeping secrets)?
]
] Diamond didn't disclose information because it was POLICY.
] That's all.. There wasn't anymore more in it. And, their
] designs were very easy to clone, using off the shelf chips, but...
Screw that. Companies make policy for economic reasons. There
was an economic reason for the policy. It wasn't an arbitrary
decision to intentionally decrease their potential market. It
was an economic trade-off, since the benefit of the policy
exceeded the benfit of the (slightly) larger potential market.
The Matrox policy that started this thread is based on the
assumption -- false, as it turns out -- that non-disclosure
will allow them legal remedy for reverse engineering. It will
not; reverse engineering is specifically allowed in EU countries,
even under the Berne Convention, for the purposes of documenting
interfaces to allow interoperability. This includes the
interoperability of drivers for the card with cards of other
manufacturers.
Matrox made a monetary decision (it just so happens they did
so on the basis of incorrect or incomplete legal information).
] : Simple: because they neglected to engineer a software access
] : path other than the BIOS to the mode-table-to-clock-setting
] : circuitry.
]
] HUH?
]
] The Diamond drivers in other 32bit operating systems didn't use
] the BIOS. The Diamond driver in Linux sure doesn't use the BIOS.
I didn't say that it did. Read it again. *OTHER* than the BIOS.
] mode-table -> clock setting is a rather straightforward thing.
] the only thing you need for each card is HOW to tell the card
] what clock rate you want it at.
You mean you need to code a card-specific table somewhere, and
you think that the place to do this is in the driver instead
of in memory that is already specific to the card.
That makes for a driver per card revision, doesn't it.
How bloody inefficient to require an OS to have 50 drivers
for 50 slight variations on the same card. Or an X Server
running on an OS.
] : Which is to say, that internally, the BIOS ROM's could do a
] : table lookup, but since the table was not formally specified
] : as to location, size, and content, protected mode software
] : could not.
]
] Protected mode software seldom does this. I don't know of any
] driver which actually does, although I am sure there might be
] one or two. Having a tablein a ROM would be STUPID because
] different people have monitors with different specs... havne't
] you ever ran the configuration program with your video card
] that lets you align the screen to your monitor and specify
] the frequency?
]
] This is either saved onto an EEPROM or a driver at bootup sets
] these values (ugh!) on cheaper cards.
I think you mean an EAROM, unless there is an over-voltage supply
for the erase that I don't know about.
Almost all ENPIC code for PCI and PCMCIA card autoconfiguration,
and some ISA PNP POST code (ISA is otherwise a piece of shit)
operate *precisely* by looking at memory on the card.
EISA *almost* did this, using per slot configuration CMOS instead,
which is what caused the need for all the stupid configuration
disks.
If the table in the ROM/EAROM were expanded to include sync
frequenceies (if you will recall, I suggested an expanded
table structure, didn't I?), you would only need to know
the allowable sync frequencies for the monitor to make your
choice.
] : In other words, as far as protected mode software is concerned,
] : the table effectively does not exist... and even if it could
] : find the damn thing, it's incomplete because of information
] : implied in the INT 10 mode select interface. Like where the
] : damn thing ends.
]
] So what else is new.. that's why we have modelines in the
] Xfree configuration file. BECAUSE these tables aren't
] standard, and ebcause there aren't drivers for individual
] cards, but for chipsets that are in the cards. The common
] denominator is the hardware, not the design of the ROM.
The ATI MACH 32, for IBM card compatability, stupidly listens
to port 2e8 even when the mode the card is in specifically
does not require it.
It is impossible to deterministically probe the standard COM4:
port with an AIT Mach 32 installed because of this.
Similarly, the ISA PNP port location is used by IBM Parallel
port cards to implement extended functionality. It is
impossible to deterministaclly use ISA PNP on a machine with
one of these IBM cards installed.
In both cases, the problem can be remedied in software by
identification of the offending card. Identification of an
ATI Mach 32 card can be accomplished, per the documentation
in the file:
http://www.atitech.ca/dr/AP_NT_03.DOC
] And IF you could find the table, and figure out what format
] it was in, you would have the values.. of course, the drivers
] don't need to use this, and it is too much trouble.
Speak for yourself. 100 hours of card-designer time is worth
1 hour of card-user time, if the card users only outnumber the
card designers 100:1.
In point of fact the proportion of users to designers is much,
much larger than 100:1, even if we limite ourselves to protected
mode drivers.
] Diamond cards are identified as S3 based cards. Their RAMDAC
] is identifiable by similar methods ( i/o to known ports with
] known results ).
]
] Why should they pay more for a software engineer.. they were
] probably only slightly modifying the BIOS provided ( I am
] supposing ) by S3.. paying you to overdesign the product
] would be a needless expense that would have affected the
] market price of the cards.
Whereas the fire-storm on the net resulting from their policy,
which resulted from the original *underdesign*, had no economic
impact on them whatsoever, you claim?
[ ... my top-of-the-head design elided ... ]
] A nice way to do it. It's been done by a couple of designs.
] The thing is, most people don't want to do a specific Diamond
] Stealth 64 driver, since THE UNDERLYING HARDWARE is different
] between different Diamond versions. Your hypothetical design
] assumes that the underlying hardware will stay the same.
] WRONG. The ports to write the clock values might easily be
] different. And these table values are WORTHLESS without
] knowing the ports.
I make no such assumptions. I only assume that the table
reading code would not vary. It's perfectly reasonable to
use the table information in different ways, assuming it's
sufficiently comprehensive (ie: all you would need would be
a size and filed descriptor record at the fron to make it
the same for all Diamond cards, regardless of underlying
hardware).
I'm assuming here that Diamond table reading code would be
less than XFree86 mode line and implementation code (which
it would).
If I know I have a Diamond card (put the card probe recognition
code into a one-time run program that picks which card_driver.o
to link into the S3 server using "dlopen()"), then I can already
optimize.
How do you thing X Inside, Thomas Roell's comapny, avoids making
users bang mode-lines? How about Windows 95, which assigns the
right card driver during install in the vast majority of cases.
It's a poor design that has to ask a human a question to get an
answer about itself.
] So, you have to do a different set of outputs for various clock
] chips and ramdacs anyway. And the table doesn't shield you
] from that.
It will with a format descriptor, as above.
] So all the table is good for, is once you know ALL the other
] hardware... then you _could_ theoretically use the timing
] values,.
And the card identification section could tell me the other
hardware, if it's first field (potentially following a fixed
length card identification string) was a "card identification
section size" value, followed by "port usage descriptor values"
to avoid the need for invasive ports.
PCMCIA and PCI bus cards already provide these tuples.
It seems to me that, in the interests of simplifying bus
portability for these designs, you want to do that.
Just like the Adaptec VLB SCSI controller provides an EISA
configuration data section (a side effect of the ASIC's on
the card being the same as those used on the EISA version
of the same card).
] BUT these timing values might be worthless.
]
] What if you want a higher refresh rate for a loewr mode?
] to align a mode to your screen better?
Not necessary, if you use only documented sync frequencies, it
will "just work".
How often do you meed to align your Windows 95 screen given
the card tables (which I'm saying "move them to the card") and
the monitor capability matrix (which you can go ahead and
keep in software, with the connection made by a human -- for
now) from the "Display" "Control Panel" item?
I'll tell you: never.
] These table values are likely FIXED.
Yes, so? They don't need to correspond directly to INT 10
modes. I might as well as how you adjust the screen in the
case of a mode-select for an 800x600, where your only control
is the calue in the AL register on the INT 10 call.
] What about someone using an interlaced monitor? ( I am... ).
] They can't use the default table values.
How do you use these values with DOS with BIOS INT 10 mode
selection then?
] : No XFree86 "mode line" crap, no Windows 95 "card type and
] : monitory type" Display Control Panel crap, etc..
]
] These mode lines are necessary for supporting a wide range of
] cards with similar hardware and for getting the most out of
] the cards, using non-standard modes if you are really daring.
Peeople can bum their own drivers, at that point, if they are
trying to steal an additional 8 pixels out of the monitor
overscan areas.
The point is to *make it work*. If you want to *make it overwork*,
then you have to expect to engage in some gyrations.
] And, supporting a wide range of monitor types. Something your
] table can't really handle.
Keep the monitor table in the configuration software, as in
Windows 95, until such time as the display card and monitor
manufacturers add another pin and another 5,000 transistors
to the monitor control circuitry ASIC's so that the display
card can ask the monitor its sync frequencies and horizontal
retrace cut points to allow the card to "do the right thing".
] : Irrelevant. If a write-only register exists, a competent
] : driver writer will shadow it in the driver so that the state
] : is always knowable. This is why having the DDX mode setting
] : code in XFree86 instead of in the kernel is a stupid idea.
] : A competent software engineer would have immediately arrived
] : at this soloution and not called the problem "nasty" in the
] : first place.
]
] It is nasty because of the existing design of Linux.
So change the design of Linux. It's not holy writ. I could
implement something similar for Win95, WinNT, or FreeBSD in
about 24 working hours (a weekend).
] The GGI project will solve it.
Good. Saves us the trouble. ;-).
] X is the way X is.. and it is one solution that is not
] ideal for this problem.
There is nothing in the design of X that puts the DIX/DDX
interface layer in X server softare instead of at the
user/kernel boundry. I first suggested this in 1993, and
I'm sure I wasn't the first person to think of it.
] I call it nasty because the hardware doesn't support the
] existing software design well. Eventually the software
] will change, but since it is an underlying problem, it
] will take much time.
Change the software, and work to change the way hardware
layers are cut. This basically speaks to hardware standards
(like the example of asking the monitor display space
utilization and available sync frequncies and horzontal
and vertical range correspondances available).
] If you are calling the X programming team incompetent, I'll
] let others deal with that.
I'm not. There are some design issues that they have neglected,
that I think that X Inside got, if not right, then closer to
the target ideal.
The Diamond problem was technical, and they've solved it (in
a different way than I would have solved the same problem, and
they lost out on flexibility I would not have lost out on as
a result, but they solved it).
The Adaptec AIC 7770 problem is probably much more analogous
the the Matrox problem that started this thread. Adaptec had
their software interface ripped off by competitors for the
154x/174x family of porducts and had their products commoditized
as a result.
The need to violate Adaptec's patents on the AIC-7770 sequencer
protects Adapatec a hell of a lot better than their NDA policy
ever will. Their NDA can be (and has been) worked around.
Similarly, the need to violate Matrox's patents to provide the
same programming interface (interface and physical contraints
dictate design) protects Matrox sufficiently that NDA is not
necessary to prevent their product from being commoditized
(which I think is their real worry; not that people will
be able to steal their design).
I'd argue that if I were a competitor, it's less expensive
for me to clean-room the interface than it is for me to come
up with my own, in any case, so you do not protect yourself
from hardware competitors, only from software. And thus
you limit your market.
[ ... ]
] : you claim, then this would have been known to you already.
] : The first thing in the README was a disclaimer that it might
] : fry your hardware.
] :
]
] You can fry your hardware with just about any XFree86 driver.
] What's the big deal -- you are't supposed to mess with the
] configuration file unless you know what you are doing.
The "big deal" it that this impacts your ability to sell to
people who "don't know what they are doing".
[ ... ]
] Replacing the BIOS doesn't affect a protected mode driver, since
] they don';t use the BIOS anyway.
Exactly the problem for protected mode driver writers like the
XFree86 team... a problem which does not occur for people using
the BIOS interface, which, because the BIOS interface is badly
designed and VM86() facilities in free OS's are primitive, the
XFree86 team can not do.
] The drivers detect the hardware based on hardware identification..
] the new card/old driver case doesn't happen that much, unless
] the ins/outs are very similar, which is fortunately rare. Most
] likely, the old driver will say "unrecognized revision id : 0xE3 "
] or something similar.
Better to employ a design to make it impossible instead of
only unlikely.
Other than the "I must take you down a peg to prove my unrelated
point", this has been an enjoyable discussion. 8-).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.