Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!actcsiro!news.nsw.CSIRO.AU!wabbit.its.uow.edu.au!news.ci.com.au!newshost.telstra.net!act.news.telstra.net!vic.news.telstra.net!news.mira.net.au!news.vbc.net!samba.rahul.net!rahul.net!a2i!news.PBI.net!decwrl!spool.mu.edu!howland.reston.ans.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: Toward a protected mode hardware driver standard
Date: Tue, 23 Apr 1996 20:57:52 -0700
Organization: Me
Lines: 366
Message-ID: <317DA6C0.6F96A274@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> <317D90C6.274931F9@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:14859 comp.os.linux.development.system:22279 comp.os.linux.x:30150 comp.os.linux.hardware:37201 comp.os.linux.setup:52065 comp.unix.bsd.386bsd.misc:835 comp.unix.bsd.bsdi.misc:3504 comp.unix.bsd.netbsd.misc:3355 comp.unix.bsd.freebsd.misc:18102
Formerly a subthread of "Re: Why to not buy a Matrox Millenium".
Erik Stahlman wrote:
] Terry Lambert (terry@lambert.org) wrote:
] : 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.
I was unaware of the support for multiple frequencies for a
given resoloution in the new interface.
Even so, this is a monitor selection issue, if the card
exports enough information, like we want.
] [ 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?
I've run Novell Server ODI drivers for network cards in
FreeBSD. Unfortunately, since I was employed at Novell/USG
(the former USL) at the time, I can't distribute the code...
I would have to rewrite it from scratch, something I hate to
do. Once I've proven concept, I tend to lose interest, so
it would fall into the category of "work".
In a more general sense, this is what's called a "kernel
emulation environment". Really, this would apply to using
commercial SCO and SVR4 drivers, as well as Windows 95 or
Windows NT VXD's in your kernel.
The problem with NDIS drivers (or video drivers, or other
VXD's or .386 Portable Executables) is first that most
UNIX-like OS's don't support kernel paging by segment ID,
and second, that most of these drivers assume a *great deal*
about implementation architecture.
I think that ELF is capable of enabling kernel paging (though
this is not yet available in FreeBSD or Linux, or UnixWare,
for that matter).
On the other hand, I think it would be a mistake to adopt some
aspects of Windows 95 or Windows NT system architecture. The
use of code thunks in Windows 95 is particularly inept, for
example.
] 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.
Yes. Video drivers are one place you could get a big win;
it would require PE reading capability (I've decoded most
of the PE data information in the process of writing a tool
to do profiling of VXD's, since I need it to interpret the
profiling data), and breaking the kernel up by segment
identifier, at least for the video driver, if not the whole
kernel.
] 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..
Actually, I'd think the video BIOS would want to reference
the tables as well; this would save the manufacturers a lot
of duplication of effort in their designs.
] 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..
Yes. I think this is desirable with or without the ability
to read the necessary information out of the ROM. The probe
code should be seperable, even if the probe is just a bunch
of memory tupple reads on an ideally designed card.
[ ... moving DDX into the kernel: the Linux GGI 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?
I have only a rough idea... I know there is a /dev/bit,
/dev/bitblt, /dev/screen, /dev/vga, /dev/vgactl, /dev/vgaiob,
/dev/vgaiow, /dev/vgaiol, etc.
The file /lib/vgadb provides a database of known monitors and
controllers (if the card manufacturers do what we've suggested
so far, all they need are the monitors). Here's an excerpt from
the man page at http://plan9.bell-labs.com/magic/man2html/6/vgadb
The VGA database, /lib/vgadb, consists of two parts,
the first describing how to identify and program a
VGA controller and the second describing the timing
parameters for known monitors to be loaded into a
VGA controller to give a particular resolution and
refresh rate. Conventionally, at system boot, the
program aux/vga (see vga(8)) uses the monitor type
in /env/monitor, the display resolution in /env/vgasize,
and the VGA controller information in the database to
find a matching monitor entry and initialize the VGA
controller accordingly.
So, as your suggestion, they use a controller chip type, a
RAMDAC controller type, a clock generator type (which might
be a synthetic clock using a PLL -- boy was I out to lunch
on PAL -- my name memory sucks 8-)), and a hardware graphics
cursor type.
] Maybe we should move this to a thread something like: a
] common API for kernel level SVGA support.
Already got it -- I don't want to limit it to video, though. 8-).
] 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-) )
The Plan 9 interface provides bitblt, bitbltclip, clipline,
point, segment, polysegment, arc, circle, disc, ellipse,
texture, border, string, strsize, strwidth, and Fcode
functions. Not enough to fix the Matrox 3D problem. 8-(.
] 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.
This is till somewhat dangerous for some hardware, where a
read of a port can cause the hardware to set up something
else (ie: FDC status port), but it's certainly less obtrusive
than a write.
The FreeBSD Com4: problem was a result of the ATI Mach32 use
of the 2e8 port range without having had the mode selected
to enable the use of that port. It's a bug in the Mach32
chipset, or at the very least, in the card implementation
(since it *could* be worked around).
] 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.
Why? (just joking... sorta 8-)).
They have to be dealt with as destrive probes, in some cases.
Since the probe is entirely seperable from the driver
implementation (ideally, you would not page in the driver
unless the probe came true, and onece in, you would discard
the pages containing the probe from the kernel), this should
not impact the overall design.
] : 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..
Only the ones who don't want to have to write their own drivers
any more. 8-) 8-).
But there should be a reliable vendor-independent way of doing
a protected mode card identification and much of the protected
mode driver work... if not, they have to carry around a driver
(which should be OS independent, even if it means changes to
Linux and FreeBSD to get there).
] : 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.
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.
] : 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).
Beats a reboot/rebbot-to-safe-mode/reboot all to heck.
] : ] 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..
Heck, forget that! A "run this X program in a 640x480 server
to pick a higher resoloution" whould save the user all but
the actual run time.
Plus it would give a place for popups for things like SMBFS
user authentication... something that's preventing SMBFS from
being useful on all but single-user, no-remote login, no NFS
export machines.
] 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.
Yes. General category: Productization.
] 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..
Even non-free OS environemnts (UnixWare, Solaris, Win95, Win NT,
etc.).
] hopefully 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.
Yes. Big "if", I suppose...
] Fortunately, the mode setting code itself won't get much more
] complicated.
And can be shared for those with and without protected mode
capability lists for the OS.
] : 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 think I'd like to be conservative... and create a default
640x480 driver teo ensure minimal usability. This is probably
the lowest common denominator that can be safely supported on
all cards. It would probably have to rely on the ability to
call INT 10 calls from protected mode -- not a full VM86()
tunk interface, but close enough to make it worth doing
the right thing.
] : 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?
Yes... to route around the damage, so to speak. ;-).
] : ] 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.
Mutual, I'm sure. 8-).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.