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!solace!nntp.uio.no!news.cais.net!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: Toward a protected mode hardware driver standard
Date: Wed, 24 Apr 1996 14:07:54 -0700
Organization: Me
Lines: 59
Message-ID: <317E982A.10EE232F@lambert.org>
References: <317C0A31.676F6C66@lambert.org> <317D90C6.274931F9@lambert.org> <317DA6C0.6F96A274@lambert.org> <stephenkDqCr4u.Bp2@netcom.com>
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:14857 comp.os.linux.development.system:22277 comp.os.linux.x:30147 comp.os.linux.hardware:37200 comp.os.linux.setup:52060 comp.unix.bsd.386bsd.misc:834 comp.unix.bsd.bsdi.misc:3503 comp.unix.bsd.netbsd.misc:3354 comp.unix.bsd.freebsd.misc:18101
Stephen Knilans wrote:
] >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.
[ ... ]
] 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.
The reason for a Windows95 driver would be to provide a general
framework driver.
All card vendors who met the framework criteria would not need
to write drivers... as long as their clock, ramdac, etc was already
supported.
You want to do this for them so that Diamond (only a for instance)
doesn't end up feeling like they are writing drivers for competitors.
] 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!
Until P7 doesn't support x86 backward compatability. Or you plug
the card into your 21066 PCI Alpha box. Or into your PCI
PowerMac. 8-(.
Driver component abstraction is about the best you will get,
unless you want to change the problem from "BIOS vs. x86 protected
mode" into "x86 BIOS and protected mode vs. all other processors".
] >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!
Not after only 5 seconds, with only minor frequency variations,
instead of hughe non-syncable swings.
If it's a big worry, fall back to the tables. 8-(.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.