Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!inferno.mpx.com.au!goliath.apana.org.au!news.syd.connect.com.au!news.mel.connect.com.au!yarrina.connect.com.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!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: Tue, 23 Apr 1996 19:24:06 -0700
Organization: Me
Lines: 346
Message-ID: <317D90C6.274931F9@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> <317C0A31.676F6C66@lambert.org>
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:14855 comp.os.linux.development.system:22274 comp.os.linux.x:30144 comp.os.linux.hardware:37197 comp.os.linux.setup:52056 comp.unix.bsd.386bsd.misc:832 comp.unix.bsd.bsdi.misc:3500 comp.unix.bsd.netbsd.misc:3352 comp.unix.bsd.freebsd.misc:18098
*******************************************************************
*** ***
*** Erik's news server is sick. He has asked me to post this ***
*** reply to my message on his behalf. ***
*** ***
*******************************************************************
It seems that there are some interesting ideas here.. and well worth
the continued discussion of this. So.. I'll try and consolidate the
arguments
a little, and we can elaborate, instead of trying to approach the same
thing from different sides.
Terry Lambert (terry@lambert.org) wrote:
: Why do you think "reset the machine if this takes too long"
: is an acceptable implementation for the Windows 95 install
: time hardware inventory?
First, I don't consider this acceptable.
I would sooner have it have a CMOS timer set, or have as many safe means
of
gaining control as possible. This won't prevent _every_ problem, but it
would
have solved many. I guess they had their reasons for doing it as they
did..
at the very least, I would have given a time and said ( if this takes
more than
a minute, then reboot.. long time is a relative concept and thus subject
to
mis - interpretation ).
I would also like to have seen a short thing of what it was doing. Ie,
looking
for CDROM cards. Looking for Sound cards. etc.. etc. This way, if it
locks
up, I could either (a) manually specific that I had / didn't have this
(b)
the process could re-run and not try this again (c) someone could call
with
a bug reboot about this probe.
: 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).
The default VGA modes are. However, modern cards support the VESA
interface,
and newer ones should support the protected mode VESA interface.
However, I
believe this is 16bit protected mode (someone could confirm / deny this
).
These cards use various means to define the often slightly non-standard
clocks
for modes like 640x480, 800x600 and 1024x768.
That is the problem we have to deal with, reading the frequencies for
this.
: 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.
Yes, they do. Even though they were written by the manufacturers, many
of them do stupid stunts involving writing registers to determine the
existence of their own chips.
At least we are nearing the end of this foolishness with the other means
of identification mentioned..
[ Regarding Diamond / Matrox cards ]
: 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.
: Enough that there needs to be a protected mode driver API standard?
: Sure we can. Logically seperate the clock setting module as
: a seperately loadable piece of the driver.
This is a good point, and it would be very nice to see it added to Linux
and FreeBSD. A standard API for graphics would be an interesting thing
and it would be even more interesting to see, if perhaps winNT or win95
drivers could be coerced into running under Linux, perhaps with some
milder
speed penalty than thunking into real mode?
This would eliminate a lot of driver writing time for various X
implementations,
as all the work is done by the writers for the drivers. It would be
ideal
if they would provide source code implementations of their drivers, but
that
is yet a ways off.
Still, we would want the BIOS tables, depending on exactly how the API
was
designed ( ie, have a VESA like query to use to find modes that have
what
we want? Or to have just a "set clock and bits per pixel" call..
And if we have to write the drivers, instead of using the ones that do
exist,
then doing something to identify the clock chips, the ramdacs and the
main
accelerator, ala SuperProbe, and dynamically linking these loadable
modules
wouldn't be _that_ difficult..
: ] 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..
: ] 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...
[ ... ]
:
: 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.
:
Exactly how does Plan 9 implement the API for mode changing? Does it
also handle such perks as acceleration, possible add ons for 3D support?
Maybe we should move this to a thread something like: a common API for
kernel
level SVGA support.
Loadable modules could easily be combined with an object file containing
NDA routines, and we get rid of this whole Matrox fuss, the fuss with
Diamond,
and any other card vendor who might want to do NDAs. ( yes! this is
STILL about the Matrox 8-) )
: 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.
If a design doesn't have a way of non-intrusively probe for a chipset,
it
should be considered broken. Most chipsets are designed with a register
that can be read, and if this has a semi-standard value, then it's a
good
chance of being that chipset.
PCI and PCMCIA solves this nicely with ..
: 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.
however, we still need to deal with the ISA / VLB cards somehow.
: 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.
True, but this requires changes to _everyone's_ cards..
: ] 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?
What remains with this is the problem of belling the cat. Who will
convince
every video card manufacturer to use a standard. If one _very_ popular
card
could be convinced to follow this, and all the others started following,
this
then would have definite possibility for making future drivers much
easier
to develop. Even without use of the standard API.
: ] 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?
If you know the clock chip, then setting a mode with the standard sync
frequency and changing it slightly isn't all that difficult. Again this
is more work than getting it from the BIOS/EEPROM/EAPROM .. but it's
still
a viable solution to what we have right now?
:
: ] 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.
Unfortunately, with today's hardware, this is something that I don't
really
see how we can avoid.. The BIOS changes can happen, but this would be
over a period of a several months at the earliest, and years for
everyone to
have them -- people still use 386s with ancient 512k vga cards.
: ] (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...
That would be very nice.. we have even MORE time to wait for that.
Knowing
the horizontal and vertical freuqencies for monitors, either through a
table
provided by the manufacturer, or through a monitor table, are probably
the best
options available at this time..
: ] 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.
IF this can be done in a way to reduce the already rather high
configuration
cost for free Unices. A "run this program to set up X" would save the
user
a lot of time.. Likewise, a generic test hardware and include such into
the kernel modules would be a nice touch. All things that seem to be
possible
with what we have mostly already written.. and would save the user much
time.
So, how about it? Should some group work together to save time and
effort
when configuring free operating systems/ environments? The issues
exist
in both FreeBSD and Linux, and a resolution would benefit everyone..
: ] 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.
As mentioned above, this really ought to be an object file with routines
like .. oh..
"mode_select","mode_find","gui_drawrectangle","gui_getcapacities"
or similar. This way, similar object files can exist for different
platforms
and the C source that depends on it can be changed by anyone for
different
revisions of the program / kernels..
: ] : 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.
And leaves us with the problem that has to be resolved in software
today..
How to deal with this.. as above...
hopefulyl the next generation of video cards will have something like
what
you propose, if it can be done so it is actually able to remain a viable
standard.
Fortunately, the mode setting code itself won't get much more
complicated.
What is going to be difficult now is supporting hardware MPEG
acceleration
( does ANY Xwindows support this? Xinside maybe? ), hardware 3D.. any
other hardware that gives better functionality..
: 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).
Since drivers are loaded dynamically, or even statically when compiling
the
kernel, these would be chipset specific ( maybe a chipset/ramdac/clock
seperation for support of the greatest number of cards ). Just so long
as the spec is there so people ( like I'd love to do over this summer,
once
classes are over ) can get as much as possible out of their cards..
: 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.
However, we could have the means to work around this, by having the
means
to use NDA'd drivers with a standard DDI interface?
: Mom: "If your friend Timmy jumped off a cliff, would you?"
: 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..
Actually, as it turns out, it was getting the tuples by reading ports
instead of going through the BIOS. As to why, I don't know..
: ] It is fun, isn't it.. :)
: Thinking... too bad so few people are succeptible to addiction.
Hopefully this will remain at least somewhat thoughtful and we don't
need to try to pound each other into the ground. Accept my apologies
for
my attempts.