So my problem continues.
> They're based on what the nvidia proprietary driver itself refuses to do,
I see, thanks.
> though, I'm not 100% sure that I had nv44 in my sample when I made that
> change.
Looks like it limits to 155M in the nv44 case too, so your change is totally
correct.
> It might be using a reduced-blanking mode,
Indeed it does, thanks. I had ruled out this too early as highly improbable.
> check your Xorg.0.log to be sure. See the "-logverbose" option if you don't
> get all the timings printed out with the default verbosity level.
It does tell at least on level 9, thanks.
However, what it doesn't tell is the timing actually used. Anyone more familiar
with the relevant reverse engineering methods (MmioTrace or whatever) to find
out?
The other problem is that nouveaufb doesn't (like matroxfb) provide a method of
specifying the exact timing to use (and I would presumably need it in order not
to change between FB console and X11).
One would come to think that video=1600x1200RM would result in a
reduced-blanking mode, but drm.debug=7 shows it actually does not.
Reading the source of drm_fb_helper.c reveals that it's almost impossible to
achieve rb=1.
Any chance of implementing implicit reduced blanking in nouveau? If someone
could hint me at where to architecturally correctly put it in I will be happy
to start implementing it myself.
I'm afraid more people than me will run into this and will regard the
(absolutely plausible) TDMS bandwidth limiting as a regression ("Help! Help! My
1600x1200 used to work, but now it's broken!") when there's no reduced-blanking
workaround.
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
