Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Bryan Mayland <bmayland@leoninedev.com>]

Gerd Knorr wrote:

> Well, vesafb really depends on what the vesa bios says...

    Exactly my problem.  In my laptop, I have a NeoMagic 2160 which does not have use
the last 64k of video for sound buffer like the NeoMagic 256es do yet it still
reports that the memory is not video memory.  Both XFree86 and SVGALib hard code the
amout of available video memory based on the PCI id of the neomagic device, which
tells me that there might not be a way to detect it properly.  What I'm suggesting is
that we "Avoid the probe!" (which is fun to say), and add a way for the user to
override the amount of memory detected by the VESA int 0x10 call.  There is only
about 10 lines of code requited to make the change, and it can't break anything if
you don't turn it on.

    I wish there was a way to detect that the code wrapped memory before the hardware
did, but that would be un-possible to probe (AFAIK).  You can detect that ywrap isn't
working properly by writing a magic number to offset 0, and attempt to read if from
offset [memsize], and see if you get the same value back.  This doesn't fix the
problem, it just assertains if it is working properly or not.

> That's why it has all may-have-problems features turned off by default:
> no ywrap, no mtrr.  At least it was this way last time I touched it.

    I was pretty suprised ywrap worked at all on my system.  The speed increased over
"redraw" is quite dramatic.

    So what do you say.  Can we use my patch to allow the user to override the VESA
detected memory size... or does anyone else have a better plan?

Bry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/