On Mon, 24 Mar 2003, Malcolm Stevens wrote:
Some more info... Hope it helps.
1920x1440 @ 75Hz is the one that has problems. 1920x1440 @ 60Hz looks good. I pulled the modeline info from the source code and specified the 60Hz one and that looks good.
1920x1440 @ 75Hz is 297 MHz bandwidth. That's alot. It may very well be that your card doesn't work so well up there. Even more likely that the monitor doesn't.
Does it work at 75 Hz with the binary drivers? Are you sure it's really running at 75 Hz? That driver will edit the modelines.
I have to double check. I'm learning some of this on the fly, more and more, as I'm beginning to realize.
The 3123 nvidia driver is still slow. It's slow to the point that xterms don't scroll fast enough to follow the cursor smoothly.
Are you sure you're running 3123? Comparing 3123 to the "nv" driver I would expect "nv" to be a little faster (~20%) than 3123 for scrolls, but 3123 is probably about twice as fast for text rendering.
This one I did double check. The log and /proc all agree and I removed the 4191 files just to make sure. I'll try the quantitative stuff tomorrow.
Thanks, Malcolm
You can get quantitative data with x11perf.
x11perf -scroll500 x11perf -ftext
I don't know anything about Cadence's software. It sounds like they're just doing something stupid.
Mark.
Next problem that I'll throw out in the hopes that you may have some
ideas: background... Cadence has recently ported their IC tools to
linux and that's the real reason I'm putting so much effort into
getting linux set up nicely. I've been using these tools on suns for a
long time and I've noticed that if anything is going to expose bugs in
the OS, particularly X stuff, then these tools are going to do it. The
nvidia driver seems to have no problems except speed with these tools
but the nv driver has problems. This is not dependent on resolution
but I'm quite sure it worked ok in 4.2.0 (I'm going to go back and
verify that). Using Cadence tools with the nv driver in 4.3.0 is 1-2
orders of magnitude slower than the nvidia driver. The tools have
their own "cursor" that should follow the X cursor with no lag. A slow
system, or slow network, will show a slight lag from the X cursor to
the tool's own cursor (the nvidia driver is slow but still barely
usable). The lag is a few seconds with the nv driver and completely
unusable. The X process eats up CPU with nothing visibly happening.
Please let me know if you have any ideas where I could look for causes,
fixes, etc.
Thanks, Malcolm
On Saturday, March 22, 2003, at 10:02 PM, Mark Vojkovich wrote:
I've just tried these modes on my GeForce2 MX:
2048x1536 @ 60 Hz (266.9 MHz) 1920x1440 @ 60 Hz (234.0 MHz)
and both worked fine with the "nv" driver for me. You're saying they work fine for you in the "nvidia" driver but not "nv"? Are they the same refresh rate in both cases? Note that your monitor claims it doesn't have enough bandwidth for either of these modes (max 210 pixel clock).
oc(II) NV(0): Ranges: V min: 48 V max: 160 Hz, H min: 30 H max: 121 kHz, PixClk max 210 MHz
I could see the case where the "nvidia" driver would lower the
refresh rate automatically because of that but the "nv" driver
wouldn't.
The ghosting you are describing is typical of the monitor or
monitor cable not being able to support such high frequencies, leading
to artifacts. My monitor claims to have 250 MHz bandwidth. It
looks OK in both these modes.
Mark.
On Sat, 22 Mar 2003, Malcolm Stevens wrote:
Regarding: nv driver misbehaves on geforce 2 MX @ greater than 1600x1200 Email: [EMAIL PROTECTED]
_______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
