Hi Abraham,
> Yes, there is a problem with the i830 driver if you only have 1M stolen
> memory in your BIOS. I'll fix this as soon as I get time (and as soon as I
> start working again in January).
>
> If you're really anxious to get the driver going, you can try this hack:
>
> Edit xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c
>
> (it might also be i810_driver.c - can't remember) and the search for the
> part where it initializes StolenSize. After it initialized it, set it to 0
> (pI810->StolenSize = 0). That should solve the problem although it's going
> to waste 1MB of your memory.
I tried. This doesn't work.
> Iirc the code checks whether you have stolen memory or not and if you do
> have, it tries to use it for the frame buffer (which of course won't work if
> you only have 1MB stolen memory).
I also had a look at the code. If you have a "VideoRam"
declaration in your XF86Config-4, it actually doesn't bother
about `pI810->StolenSize' at all. In fact, setting it to 0
makes matters worse, because then even a depth of 8 doesn't
work anymore. (It dies somewhere quite late in PreInit.)
As I have tried to explain before, I believe that the
problem is NOT in the driver actually having a problem with
only 1MB stolen memory. The problem - as far as I
understand it - is that the BIOS *assumes* that only a
restricted number of video modes are available.
In PreInit, there is this loop at line 821 in
`i830_driver.c' (this is in the tree tagged xf-4_1_99_2)
where the driver uses the VESA function 0x4f01 (by way of
the function I830VESAGetModeInfo()) to determine the legal
video modes at the default colour depth. It seems to me
that the BIOS here simply does not provide a video mode with
a resolution higher than 640x480 at depth 16 and 24. In
other words, I don't think that the problem is really in the
driver, but that it is in what the BIOS reports. Is it
possible that the BIOS determines the available video modes
in dependence on the GMCH setting of the amount of stolen
memory?
BTW, there are two points about the code which I don't
really understand:
* At the beginning of the mentioned loop that queries video
modes, there is the following code:
pVesa->pInt->num = 0x10;
pVesa->pInt->ax = 0x5f28;
pVesa->pInt->bx = 0x8000 | i;
pVesa->pInt->cx = 0x8000; /* Current display device */
xf86ExecX86int10_wrapper (pVesa->pInt,pScrn);
if(pVesa->pInt->ax != 0x005f) continue;
What does the 10h function 0x5f28 do? Usually, the
function numbers start with 0x4f, don't they? (Mind you,
I am pretty clueless about this whole VESA business.)
* Why do you run a loop trying all video modes numbered from
0 to 0x7f instead of only looping over the modes in the
list provided by `VBEInfoBlock.VideoModePtr'? (The latter
seems to be at least more efficient.)
Cheers,
Manuel
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
