Return to BSD News archive
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 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!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!in2.uu.net!news1.digital.com!decwrl!amd!netcomsv!uu4news.netcom.com!netcomsv!uu3news.netcom.com!ixnews1.ix.netcom.com!netcom.com!stephenk From: stephenk@netcom.com (Stephen Knilans) Subject: Re: Toward a protected mode hardware driver standard Message-ID: <stephenkDqCr4u.Bp2@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <317C0A31.676F6C66@lambert.org> <317D90C6.274931F9@lambert.org> <317DA6C0.6F96A274@lambert.org> Date: Wed, 24 Apr 1996 05:55:42 GMT Lines: 60 Sender: stephenk@netcom.netcom.com Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14737 comp.os.linux.development.system:22033 comp.os.linux.x:29954 comp.os.linux.hardware:36960 comp.os.linux.setup:51605 comp.unix.bsd.386bsd.misc:774 comp.unix.bsd.bsdi.misc:3423 comp.unix.bsd.netbsd.misc:3272 comp.unix.bsd.freebsd.misc:17907 In article <317DA6C0.6F96A274@lambert.org> Terry Lambert <terry@lambert.org> writes: >Formerly a subthread of "Re: Why to not buy a Matrox Millenium". > > >Erik Stahlman wrote: >] Terry Lambert (terry@lambert.org) wrote: > >Yes. Rough consensus and working code. The way IETF standards >are forged. The way Adaptec took over the SCSI market. 8-). > >Probably the most convincing argument would be to jointly >work with the manufacturer and build a BIOS design and build >a Windows 95 driver for them, using the same modules. > >This is less than optimal for Linux or FreeBSD, since it would >mean wedging the same dynamic submodule loader so the modules >were OS independent (or not -- though it's less attractive that >way) into the Linux and FreeBSD systems. > Why complicate matters? Rather than having a disk based driver setup that means NO general universal compatibility(heck, you wouldn't even know the media type), you could simply put the code on the ROM on the card. You COULD setup a special address sequence that could switch the protected code into place. The only thing that would be needed is a well defined API, and a consensus. You wouldn't need ANY loaders! A register could be checked. if it fails, use as NOW, and pray it works. If the register returned a code indicating that the card was good, switch the API, use IT, and all is well! >] : Catch-22: how do I set graphics mode to use the interface >] : to tell the software 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? > >Yeah. Fallback first to potentially intrusive probes, then to >known intrusive probes (anything that works is better than >anthing that doesn't). >] 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. > >Much as I hate to publically discuss potential improvements for >Windows 95 (;-)), this could be handled by a trail-and-error >for frequencies for > 640x480 once the card was known, using a >"click here if you can see this" dialog that times out after 5 >seconds (default). Some cards go CRAZY with this though! >