Hi Lee,
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.
>
> The diffs that follow avoid entity and screen references for indexes
> less than zero and behave
> 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.
> I'll save that for later. Since these are independent, I'm presenting
> them without the multihead
> 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.
>
> base = xf86MapVidMem(pInt->scrnIndex, VIDMEM_MMIO, 0, pagesize);
>
> End of helper_exec.c changes
>
For the rest of the diffs:
I guess what you are trying to do is to get the BIOS mapped
although you don't have an entity index (yet).
That's easy for primary cards. For non-primary cards it is
only possible for PCI cards. It looks like you only need
the BIOS, you don't need any int10 functions.
We therefore should check if we can separate out the mapping
part and make it available as a separate function.
>
> diff -bc vbeModes.c*
> *** vbeModes.c Mon Mar 29 15:24:45 2004
> --- vbeModes.c.orig Thu Nov 6 10:38:14 2003
> ***************
> *** 54,61 ****
> depth = 1;
> }
> bpp = mode->BitsPerPixel;
> - if (!depth)
> - depth = bpp;
> VBEFreeModeInfo(mode);
> mode = NULL;
> switch (depth) {
Hm, that one seems to work around a bug in the BIOS I
assume.
Egbert.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
