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!inferno.mpx.com.au!news.mel.aone.net.au!imci4!newsfeed.internetmci.com!in2.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: Mon, 22 Apr 1996 15:37:37 -0700
Organization: Me
Lines: 625
Message-ID: <317C0A31.676F6C66@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> <317AD930.2088AE6D@lambert.org> <4leqda$9ob@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:14781 comp.os.linux.development.system:22135 comp.os.linux.x:30034 comp.os.linux.hardware:37063 comp.os.linux.setup:51784 comp.unix.bsd.386bsd.misc:798 comp.unix.bsd.bsdi.misc:3454 comp.unix.bsd.netbsd.misc:3307 comp.unix.bsd.freebsd.misc:18001
erik@fenris.campus.vt.edu wrote:
] There are two kinds of change, that which affects the driver
] and that which does not. I'd do one of your spiffy matrix
] things, but there is no need as I am assuming that you can
] follow a verbal discussion.
Yep. 8-).
] Yes, there are places where the BIOS could tell the driver
] that for example, more clock frequencies are available. On
] the Trident 9440 which I am more familiar with, there does
] not seem to be a way to tell from the chipset what type of
] memory is in the card. XFree86 has an option to set this..
] as far as I can tell, this is gotten from a software-only
] driver under other operating systems. ( Or maybe I'm wrong
] and there is a way.. I've only been looking through that
] manual too many times now for other stuff ).
]
] So this is something that the BIOS by your definition
] should tell me.
>*YES!*< (emphatic enough for you? 8-)).
] And if it did, yes, I'd be much happier. But very few, if
] any, video BIOSes do work that way.. not the Diamonds, not
] the Tridnets, nor the CL chips ..
And that is wrong. It is immoral. It is fattening. They
are witches. See if they weigh the same as a duck.
] But what ends up happening is that the user has to get asked,
] or conservative settings need to be followed.
That's wrong, too. Computers are supposed to make your life
*less* complicated -- aren't they?
Isn't it our job, as computer professionals, to deliver on
that promise?
] On the other hand, something like a change in the RAMDAC, or
] a change in the underlying chip ( from an S3C805 to the S3C811 )
] can be determined by probing the hardware. The BIOS doesn't
] need to give that information.
This is acceptable, IFF the probe is non-intrusive. For
instance, probing COM4 with an ATI Mach32 installed, or
probing an Interlan or Lance ethernet with a WD8003 with
CMOS configuration installed, or probing a PS/2 mouse or
Floppy tape drive when the accompanying hardware *isn't*
installed.
Why do you think "reset the machine if this takes too long"
is an acceptable implementation for the Windows 95 install
time hardware inventory?
] Considering that accessing the bios is sketchy at best.. and
] the only thing that would really be useful with a new chipset
] is a procedure that could be copied from BIOS code to your
] driver for setting these values... ( what.. how does your
] table say you have to set register foo with 25, then register
] foo2 with 45, and register foo3 with the inverse + 1 of
] register foo4 ? the last one is difficult.. the first 3
] would require that the card not have jumpers that it can
] move around in io space ( have a fixed IO address in the
] table ) or have another means of offseting all the foo
] registers.. But still, you can't really determine interactions.
Obviously, it can't.
Amancio Hasty did suggest that a mode-set interpreter be
implemented back when he did the original S3 work, to handle
exactly this case.
And the OpenBoot standard suggests the the cards should
have a common API, written in Forth, to make them processor
independent as well as protect mode/real mode independent.
But even the OpenBoot standard realizes that the drivers used
in the boot process must give way to protected mode drivers
for the same hardware, if possible (ie: they are fallback
drivers, as discussed in the "Historic Opportunity..." thread).
I have recently learned that Plan9 does, in fact, implement
a virtualization of their graphic devices -- my suggested
"DDX in the kernel", with card specific drivers and a default
fallback driver for boot and for when there is no card specific
driver available to demand-load into the kernel.
] : Please read the original SunSite README for patching the XFree86
] : server software to operate with Diamond cards.
]
] I looked quickly for this, and couldn't find it. Maybe you
] could summarize the point?
It documented Diamonds statement to the effect that the non
disclosure resulted from a desire to allow them to firmware
upgrade their cards, and further, what kind of catastrophic
failures you could expect from there being no way to detect
a firmware upgraded card had replaced a previous release,
because the card identification landmarks were not considered
set in concrete and thus may not change from revision to
revision (mistake to be blamed on the driver, not the card).
[Unfortunately, it looks like this material has been taken
offline since XFree86 began supporting Diamond]
] My understanding was that this "patch" was an external program
] that would change clock 3 of the clock chip to work with
] whatever mode you wanted..
That was the one posted by "Bruce_Wayne@Batcave.com". There
were three other versions, including one as a set of patches
to the S3 server that latched the inputs that latched the
clock inputs, instead of latching the clock itself.
Since it worked with the S3 server, the last was the most
popular (and card revision dangerous) one.
[ ... ]
] there are more pieces, which can be used if you have the
] register programming spec sheet, which is what people would
] like to see available for the Matrox ( see, I'm on topic..
] sort of ).
8-).
] How are these less useful to a system just because the bios
] doesn't tell the driver what type of Blipvert is hooked up?
By virtue of the level of intrusion required in the probe
sequence.
] : ] 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.
]
] According to a member of the Xfree86 team, they had available
] to them from the original manufacturers of the chips used in
] the Diamond design enough details to do register level
] programming, and have the S3 server support Diamond cards.
]
] This was not done out of respect for Diamond's stance.
]
] There was nothing to do with reverse engineering in this case.
It was not done as a matter of XFree86 team policy. Get an
older copy of their FAQ from RTFM.MIT.EDU.
] Ok, a they didn't engineer a software access path? Those ports
] you output to.. those count very nicely as a software access
] path. And you can set your clocks and your modes without ever
] touching the bios.
You can not output to (destructively probe) a card as part of
the recognition sequence without potentially screwing a card
to the point of needing a hard reset.
Recognition by any method other than a mapped memory space
read is dangerous to system stabilty. Even memory reads, for
some devices, are dangerous.
Luckily, we can safely follow and read following the INT 10
vector, because if POST didn't run, then the bootstap loader
didn't run, and we're not here to do the reading.
] : ] 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.
]
] This table is not specific to a card. It's mainly specific to
] a monitor, as once you know the timing values for a mode and
] how to program it into the chipset ( which you do need to know
] for each chipset , true ), you can set the mode to that. THe
] only exception is with cards with fixed frequency clocks, where
] you can't be as nice about it, and have to use what you are
] provided.
The default INT 10 mode select modes are, effectively,
implemented as fixed frequency selections, since there is no
externally accessably way to kick the clocks to a different
rate for mode AL=0x10 (for instance).
It is up to the monitor to support standard VGA sync frequencies.
It's why there's a standard in the first place.
It's why the arguing about the "VGA-ness" of Matrox cards is
irrelevant (see, I'm sort of on-topic, too 8-)).
] : 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.
]
] Not a complete driver, but support for the clockchip. Maybe
] potentially inefficient, but this is what we have to deal with.
That's fine... I'd be happy with that. If I didn't have to
destructively probe the chipset.
] Adding support for 50 different variations of the BIOS
] information.. Do you know how many OEMs of S3 based cards
] are out there.. Diamond's S3 cards are only one of many.
Enough that there needs to be a protected mode driver API standard?
8-) 8-).
] There are also only a few clock chips, so it was deemed more
] efficient to have clockchip handling code, ramdac handling
] code and S3 handling code, and use this combination to
] program Diamond cards and OEM cards and similar.
Determining the information in the first place is what is hard,
and what was NDA'ed.
[ ... ]
] Windows* is a different case, because there are drivers per
] individual card ( or in some cases, chipset.. such as the
] mach64, but that is a decision a company makes ). That is
] because the manufacturer supplies these drivers.. and it's
] easier for them to make a driver that works just with their card.
This is a fundamental flaw in the card support process -- it
assumes Windows.
NT and Windows95 are already protected mode systems, and they
suffer the same issues as FreeBSD or any other protected mode
OS.
And I argue that this is a result of bad software interface
design by card manufacturers.
] I can't find a reference to an EAROM in the stuff I have at
] hand.. Maybe a definition would help?
Electically Alterable Read Only Memory. It differs from an
EEPROM in that it does not require an overvoltage to erase
or program.
[ ... ]
] PCMCIA stuff seems to let you specify where you want the
] card to appear, and you can read SOME configuration values
] from a configuration port. This information is NOT enough
] to let you get away without needing different drivers for
] different classes of the same device..
]
] And i'll confess my ignorance of PCMCIA.
There are 5 different ENPIC implementations for PCMCIA bridge
chipsets; of those, the single most predominant standard is
the Intel/IBM clone chipsets. Two of the others are no
longer used. One of the others is from Hitachi, and I
think the final one is European (Olevetti?).
Configuration information sufficient to fully identify the
card is available as sets of non-intrusively readable
"tuples". Mapping space is defined by the ENPIC enabler.
Current PCMCIA card support is on the order of 70 cards
for the free UNIX clone OS's.
The tuple information is hierarchically ordered so that
you *can* use the same driver for different classes and
manufacturers of the same device.
] : 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.
]
] And you would still have to know how to program these values
] into the clock chips.
Granted. Which is the purpose of this Matrox thread. 8-).
] See, the sync frequencies aren't a big problem if you know the
] range for the monitor. These are nearly standard. Look at
] the list of VESA timings in one of the Xfree86 configuration
]files.
]
] That does you about as much good as a ROM table does.
Yep.
] Granted, an EEPROM table of sync frequencies might be nice to
] have so you can incorporate values based on user preferences.
] Convince manufacturers to start doing that.. I'd applaud you.
Very nice. So nice, that it's worth arguing about. 8-).
Nice enough to make protected mode drivers an order of magnitude
closer to BIOS-based drivers in "will probably work".
] At the same time, you also need to know what ports to output
] these clock values to.. YOu can't easily get that from the
] rom tables.. not without a very careful design which still
] might not cover the intrinsics of an update.. for example,
] the Matrox's 3D engine might improve dramatically with more
] commands and abilities.. how would a table handle _that_?
By bumping the revision and making the card unambiguously
identifiable to software so that the commands wouldn't have
to be tested by causing a failure.
] we still are dealing with the issues of making a driver, but
] suddenly we have a whole lot of change... Changes in chipsets
] means a change in the driver and there isn't a whole lot we
] can do about it.
Sure we can. Logically seperate the clock setting module as
a seperately loadable piece of the driver.
[ ... ATI Mach 32 ... ]
] Either way, having an identifier in ROM to identify a card
] is a whole lot different then them giving you a mode table
] on a platter..
Yes it is. You need both. 8-).
] : 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)
]
] So if the information can be used differently for different
] cards you are talking about parsing it for each card, and
] knowing where to use the values for each card. This is
] tantamount to writing a driver already for that specific
] card, which is more than is usually done right now.
Not true.
Usually they write DOS and Windows drivers, if not more, to
get their cards usable by a larger market.
All we're arguaing about now is what belongs in ROM and
what belongs in the DOS driver. 8-).
] Again.. If it can be supported with existing code, there
] is seldom much motivation to add spiffy support for features
] like this in noncommercial code.
I'd sure add the support to FreeBSD. Like some of my other code,
if asked, I'd let it be incorporated in Linux. Or Solaris. Etc..
] : 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.
]
] You'd need to knwo WHICH diamond card you had.. and you'd
] need drivers for each of them. Not that bad, given that you
] have the specs for the chips involved, and so forth.
]
] And you still need to probe it. You are talking about saving
] the user work.. getting rid of mode lines.. this is missing
] the point of .. Diamond wouldn't provide information on the
] HOW of setting clocks, not only the "WHAT" to set them too.
They were willing to provide it under NDA.
If it were a seperable module, I could sign NDA, write the
module with confidence that I would not need to rewrite it
for each revision of either the mode setting code, or for
each new card using the same HOW.
] : 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.
]
] Xinside most likely uses a table of standard values and lets
] the user adjust with a decent interface. That's how I'd most
] likely do it ( Go to a graphics screen and say: hit down arrow
] to move the screen down, up to move it up.. R to change the
] refresh rate.. Just like my configuration program end sup
] doing it.
Catch-22: how do I set graphics mode to use the interface
to tell the doftware how to set graphics mode?
] There goes all the modeline stuff..
And allows the software for the mode setting and the card
software to, once again, become desynchronized -- which was
the Diamond problem in the first place, and is the user
interface problem that we really want to solve: mode lines
are an implementation detail.
] (oh.. and win95 does require that you select a monitor from
] a list.. don't you wish you had to compile a large table
] of monitors and the specs for all of them ? )
No, I want the monitor to talk to the card, but I know that
that's more than a little ways off...
] : It will with a format descriptor, as above.
]
] Yep, as above you need to have a new format for each chipset,
] with a new way of reading it.
No, all you need is one way of reading it and a common grammar
definition.
] You arne't getting rid of any work for yourself..
The point is to eliminate work for the user... by analogy, 100
hours of my time are worth only an hour of users time for 100
users.
] And if the vendor doesn't give you information on what the
] chipset interface is, you are still just as screwed.
You sign NDA and distribute a binary module that does not
require the whole of the program to be binary only.
] : And the card identification section could tell me the other
] : hardware, if it's first field (potentially following a fixed
]
] Yeah, but how do you know what an 0x2000 in this field means
] for hardware when your driver was written when the spec was
] only up to 0x1000.
Because I have a descriptor schema. I already explained that.
It's the difference between defining HTML vs. defining an SGML
DTD for HTML.
I can define an SGML (allegorically) in which I can define any
extended HTML I choose to. I'm not limited to my initial
choices: the schema is extensible.
] : ] 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".
]
] IF you only use documented sync frequences, YOU DON'T NEED A TABLE.
Documented in the table, not documented in the VGA spec.
Remember the monitor table we are still required to have?
] : 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.
]
] The BIOS uses the adjusted values from an eeprom for the
] 800x600 modes.
]
] ( and to get 800x600 you'd typically use a VESA call, which
] would, if I am remembering right, have the value in the BX
] register :) )
8-).
] : How do you use these values with DOS with BIOS INT 10 mode
] : selection then?
]
] Get them from the eeprom or have a software driver read them
] from a file ( the trident, unfortunately :( ).
Yep. Unfortunately. Same design problem, different card.
] : 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.
]
] These ARE people who are bumming their own drivers in the
] free software community.
You can use the standard DDI, or you can write a driver that
is really-card-specific and use that instead ("bum" in the
cycle-shaving, hardware-overdriving sense).
] : The point is to *make it work*. If you want to *make it overwork*,
] : then you have to expect to engage in some gyrations.
]
] Which was a design decision that Xfree made to require mode lines.
] It seems that it wouldn't be that daunting to just use a standard
] set of mode lines, as X inside does it. This is a software design
] issue.. and the drivers wouldn't need to be changed since they
] only program the chip with the main software provided value.
And building a BIOS ROM is a software design 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.
]
] It's been posted about before, and it wuld be nice.. which is
] why the GGI team is working on this.. ( after this semester
] is over, I'll be most likely doing the 9440 driver for that
] project ).
Looks like Plan 9 beat us to it...
] : ] 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".
]
] True. The Xfree86 team isn't selling their software.
]
] Xinside is.. and they have a different set of criteria.
In a very real sense, they are selling their software.
They just aren't charging money for it, which isn't the
same thing as "not selling it".
] : 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.
]
] And you can't get acceleration out of the BIOS anyway, and you
] really want that for a windowing GUI.
]
] So yeah, even if you could thunk to bios and call int 0x10,
] you don't get THAT much benefit out of it..
Anything that works is better than anything that doesn't.
I didn't claim to solve the Matrox acceleration problem
with BIOS changes, only the firmware-upgrade, policy based
non-disclosure requirements, and minimally functional
protected mode driver problems.
I still claim the Matrox problem is the result of management
at Matrox accepting bogus legal advice and making a purely
financial decision on the basis of that advice.
] : Better to employ a design to make it impossible instead of
] : only unlikely.
]
] Ok, which is why PCI does that for identification.. ( although
] my understanding is that those are read from ports in at least
] some cases.. I've seen some PCI device checking code that just
] read from a list of ports instead of claling a BIOS ).
Mom: "If your friend Timmy jumped off a cliff, would you?"
8-) 8-).
I claim it's bad PCI code, if it hasn't previously determined
that the reads are safe after already identifying the card.
If nothing else, it's in technical violation of the 2.0 spec..
] It is fun, isn't it.. :)
Thinking... too bad so few people are succeptible to addiction.
8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.