Hi Lee,I believe I want to use int10, function 0x4f, subfunction 0, as is done in VBEExtendedInit. There may be
Unfortunately your patch is backwards. Furthermore I'd personally prefer unified over context diffs.
Lee Olsen writes:
> Hello all;
> > The vesa driver's probe only looks for a vga. If you have a real stone > age original vga, you get
> "No screens found". The vesa probe needs to look for the vesa signature > in the bios, and that
> means libint10.a and libvbe.a must be able to run without referencing > screens or entities, which
> they both do.
You mean you want to map the BIOS memory and search it for the signature.
other, less intrusive ways.
> > The diffs that follow avoid entity and screen references for indexes > less than zero and behaveNow that I rechecked my vesa driver diffs, you're right. I'm chasing a zoom problem and
> as before for positive values.My copy of the vesa driver has some > multihead isa stuff in it, so
I have sepent some time thinking about multihead ISA. The only chance for it to work appeared to be if ISA cards
are capable of remapping their registers. This is scary as
there is no range they can do this savely (except for the
8514 regsters). However I never had any cards with docs that I was able to try it so I gave up on it.
Furthermore I would have expected that at boot time both
cards would have their default registers VGA enabled
which will definitely produce problems during POSTing.
Not to speak of the problem that arise if both cards map
their ROM into the same range.
Therefore I'd expect that this has only a chance to work
if you are able to disable the standard VGA registers and
BIOS on one card entirely (using jumpers) in which case I
don't understand how the VESA driver would be of any help
for such a card.
not doing any multihead stuff there.
I don't expect to run multiple isa VGA cards in the same box. I don't see how to remap
VGA resources either. I do expect 8514, VGA, and mono to coexist. If there are other
isa cards that can disable VGA features like the Graphics Ultra Pro, they can be added to the list.
> I'll save that for later. Since these are independent, I'm presenting > them without the multiheadThe diffs I provided are a minimal set that allowed the probe to run. This is the kind of feedback
> clutter. I'm not sure I got everything, but it tests correctly for pure > isa vga, pure isa vesa, and
> pci/agp/no isa. I don't think my bios will let me put an isa video card > in the pci/agp box.
> > The two line vbeModes.c change fixes VBEFindSupportedDepths reporting > zero for depths
> les than 15. The symptom I saw is a 512k card requesting a depth of 16, > resulting in "No usable
> modes."
> > Enjoy
> Lee
> > diff -c helper_exec.c*
> *** helper_exec.c Mon Mar 29 11:35:02 2004
> --- helper_exec.c.orig Tue Dec 23 14:32:38 2003
> ***************
> *** 581,587 ****
> unsigned char* base;
> int i;
> > ! if (!save && !pInt->BIOSScratch)
> return;
> > base = xf86MapVidMem(pInt->scrnIndex, VIDMEM_MMIO, 0, pagesize);
> --- 581,588 ----
> unsigned char* base;
> int i;
> > ! if (!xf86IsEntityPrimary(pInt->entityIndex)
> ! || (!save && !pInt->BIOSScratch))
> return;
I'd say this is not valid. xf86Int10SaveRestoreBIOSVars()
copies the physical BIOS variable area to and from the scratch
area. This physical area exists only once and belongs to the primary card.
The physical BIOS area is set up during posting. Therefore
the values are only meaningful for the card that got posted,
not any other card.
I was hoping for. What is the right way to do this?
Enjoy Lee
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
