Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!solace!nntp.uio.no!news.cais.net!newsfeed.internetmci.com!solaris.cc.vt.edu!not-for-mail From: erik@fenris.campus.vt.edu () 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 Followup-To: 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 Date: 22 Apr 1996 02:20:26 GMT Organization: A random machine somewhere Lines: 439 Message-ID: <4leqda$9ob@solaris.cc.vt.edu> 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> NNTP-Posting-Host: shadowlands.campus.vt.edu NNTP-Posting-User: erik X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14715 comp.os.linux.development.system:22004 comp.os.linux.x:29931 comp.os.linux.hardware:36935 comp.os.linux.setup:51549 comp.unix.bsd.386bsd.misc:765 comp.unix.bsd.bsdi.misc:3411 comp.unix.bsd.netbsd.misc:3259 comp.unix.bsd.freebsd.misc:17877 Terry Lambert (terry@lambert.org) wrote: : erik@fenris.campus.vt.edu wrote: : ] 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 Those things on my Stealth 24 looked a lot more complicated than PALs to me. Unless you are referring to chipsets as PALs, which is a nonstandard use to say the least. : 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). 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. 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. 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 .. But what ends up happening is that the user has to get asked, or conservative settings need to be followed. 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. 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. : 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? 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.. : 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 am still claiming that PAL is an improper term. We are talking about video cards here, not mid level CpE projects. And using proper vocabulary is significant because otherwise we might be arguing over apples and oranges and not be aware of it. : 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. Well, if you wanted to use blipvert, fine. That would be a lot better, while not perfect, than using a term that is already allocated. : 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. Wrong. 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 ). How are these less useful to a system just because the bios doesn't tell the driver what type of Blipvert is hooked up? Maybe Blipvert 1 returns a 1 in a revision register, blipvert 2 returns a 4 ( just for incompatibility ) and the super Blipvert uses something else. The register specs document all this. : ] 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. : ] : Simple: because they neglected to engineer a software access : ] : path other than the BIOS to the mode-table-to-clock-setting : ] : circuitry. : ] 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. 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. : ] 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. : 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. 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. 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. the UNIVBE driver for DOS does this the same way. 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 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. EEPROM is typically used to store configuration values on cards. Hell, my NE2000 has it, my SMC 9194 card has it, and the Diamond Stealth 24 says when you update the mode table that it is "writing to EEPROM". Does present a nice case for it being an EEPROM. I can't find a reference to an EAROM in the stuff I have at hand.. Maybe a definition would help? : 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. 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. : 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. 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. 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. 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_? 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. : ] 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. : 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: I suppose that file says to read values X Y and Z from the BIOS? Or does it say to send values to ports and see what you get back? 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.. : ] 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. Ok.. In the case of Xfree or something like SVGALIB or GGI, the developers are doing this because they want their card supported ( typically ). Now if I were being paid to do this.. definitely.. I'd be more than willing to write code to HUNT for this table, find it in whatever non-standard location, and make it was easy as possible for the (l)user. : 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. 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. : 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. : 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. There goes all the modeline stuff.. and most of the time people don't need to adjust these modes.. but sometimes for me the screen is way off.. it's because I aknowledge that i can't afford a really spiffy monitor and make do with this old CTX junk heap. (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 ? ) : It's a poor design that has to ask a human a question to get an : answer about itself. It depends on whether or not it can get the answer and whether or not the human can give the answer better or in a way more suitable to the human. : ] 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. Yep, as above you need to have a new format for each chipset, with a new way of reading it. You arne't getting rid of any work for yourself.. And if the vendor doesn't give you information on what the chipset interface is, you are still just as screwed. : 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. : ] 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. : 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. I'll tell you.. every card I've used on my machine, I've ended up adjusting the position of the screen. I did it with a stealth 24, I did it with the 9440 ( which looks really NASTY in some modes if you don't ), and even a mach64. This was all DOS based settings.. actually the mach64 settings in the control panel let you adjust your screen position, how nice of ATI to provide that :) : 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 :) ) : 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 :( ). : 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. : 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, 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 Yep, but that configuration software has to store the updated table somewhere.. in a configuration file for a protected mode driver ( in which case, it would use values from that instead of from your spiffy bios table ). : 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 ). Another thing you can do with a form of device independence behind an API, is to use some interesting tricks to get the mode setting code for a card without knowing any of the hardware. :-) ( IO traps.. etc ). Of course, you don't get the acceleration features, and I doubt that win95 would let me do fun things in ring 0, to rip that from the trident drivers, so it's not a be all end all solution. : ] 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. : 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.. : 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 ). : Other than the "I must take you down a peg to prove my unrelated : point", this has been an enjoyable discussion. 8-). It is fun, isn't it.. :)