On 24 Sep 2002, James D Strandboge wrote:
> I have a Dell Inspiron 8200. lspci -vv gives:
>
> nVidia Corporation NV11 [GeForce2 Go] (rev b2) (prog-if 00 [VGA])
>
> I have been waiting to try the newest nv driver so I wouldn't have to
> use the binary only nvidia driver. I installed Branden Robinson's
> debian 4.2.1 pre release X packages and have X running quite well, with
> a couple of issues.
>
> 1. If I blank the screen (with bios function key mapping-- ie Fn+D)
> when I return to X, the top half of the screen is on the bottom and vice
> versa. I can chvt to a tty and come back and it is restored, but it is
> slightly annoying and the nvidia binary drivers did not have this
> problem.
There's nothing that can be done about that. The bios changes
things and the nv driver has no way of knowing about it so it can't
reinitialize. Changing VTs forces the nv driver to reinit the hardware
so it clears it up. A kernel module is required to catch the blanking
events.
>
> 2. 16 bit color depth at 1400x1050 (max resolution of the laptop) looks
> great, but 24 bit has problems with gradients (eg background in
> nautilus)-- they appear 'barred'. I tried different modelines and
> options in XF86Config-4 to no avail. Is this a known issue?
I don't recall seeing that problem with the nv driver. Does
it do that from startup or only after doing bios-related hotkey
switches? Flat panel scaling is not used in the nv - it always
runs in the native resolution and centers the image if the programmed
resolution is smaller than the panel - and there should be no problems
in that mode. When scaling at high resolutions the hardware can
drop to a lower-bandwidth mode where it has lower color accuracy.
Maybe the bios can set up something like that if you did a hotkey
switch. When that happens does VT switching fix it? If it's banding
from startup, I'll have to try to repro that.
>
> Finally, this is not a problem, but more a question about the driver.
> The driver is noticably slower if I don't have ShadowFB enabled. In the
> Xfree86.0.log, it says:
>
> (**) NV(0): Option "ShadowFB" "on"
> (**) NV(0): Using SW cursor
> (**) NV(0): Using "Shadow Framebuffer" - acceleration disabled
> (--) NV(0): Linear framebuffer at 0xE0000000
> (--) NV(0): MMIO registers at 0xFC000000
>
> Note, 'acceleration is disabled.' I am assuming this means 2D
> acceleration, but having ShadowFB enabled is much better. With it
> disabled, launching a gnome-terminal is slow with high cpu usage until
> it pops up (about 2 seconds), and closing windows is also slow (via the
> 'X' button in sawfish). Should ShadowFB typically be enabled with this
> driver? The performance is perfectly acceptable with it enabled.
Something is amiss. What does /proc/mtrr say?
The 2D acceleration should clobber ShadowFB. Could you send
me the Xfree86.0.log from a run without ShadowFB?
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
