[Nouveau] GeForce FX5200 dual DVI & Samsung 204b
pq at iki.fi
Tue Sep 28 07:02:27 PDT 2010
On Tue, 28 Sep 2010 12:43:12 +0200
Grzesiek Sójka <pld at pfu.pl> wrote:
> On 09/27/10 23:41, Pekka Paalanen wrote:
> > Are you saying that forcing a low-refresh-rate mode via video=
> > kernel argument does not help?
> > But you still do get a good picture on the framebuffer console,
> > do you not? In that case, X is overriding what kernel thinks is
> > the best mode, so you should clean up the X config.
> > If wiping the X config does not help, post kernel and X logs.
> 1. At the moment I try to get a proper image on the console. I
> put the comment about the X-log only to explain why I thing that
> there is something wrong with PixClk. Actually the screen blinks
> in the some way at the console and when I run the X-server. I was
> trying to play with the ModeLine but it seems to be ignored. For
> example whatever i put +hsync +vsync or -hsync -vsync I always
> get at the OSD info that both polarisation are positive. So it
> looks like all the timings and etc. are set by the nouveau.ko not
> by the xorg nouveau driver.
Are you sure X even runs and doesn't die too soon?
Anyway, one thing at a time, better disable X for now to debug this.
You said you have dual monitors, does the problem occur with only one?
> 2. Whatever I put to the video= I always get the some problem. It
> looks a little bit like only the resolutions is taken and all the
> rest is ignored. I do not have the way to check it but my LCD
> always claims that the mode is 1600x1200 at 60 horizontal 74.9KHz
> and both polarizations positive. It does not display the PixClk.
I forgot about the dual monitors. When you have more than one
output active, it is best to be explicit on which output is being
set via video= argument, see Forcing Modes at
My idea with video= was the timings are (sometimes?) computed
with a standard formula, CVT or GTF.
I would expect lower resolution or refresh to produce lower
pixel clock. Experimenting with non-standard modes might be
> So the situation is very strange. I think that the good start
> would be checking what are the current rates of the vertical,
> horizontal and pixclk. Is it a way to force nouveau.ko to put it
> into the dmesg?? If not then maybe I could just hard-code
> something like: printk("h=%d,V=%d,P=%d, ???
> into the source tree. The question is where to put it and what
> are the names of the appropriate variables.
Nouveau kernel module has reg_debug option which would show
the raw values being programmed to hardware. drm.ko has the
debug parameter, for which I don't have the documentation at
hand here. It is a bitmask, too. Someone else should guide
you with the source tree.
I think it would be best to make a report in bugzilla,
where you can attach kernel and X logs. X is by default
more verbose, like you said. In X, Option "ModeDebug" "true"
in the Device section will give even more information. This
should be done with otherwise minimal xorg.conf.
Did you ever need anything special with the proprietary
driver, like ModeLines or EDID data from file in xorg.conf?
PS. samsung syncmaster 204b, eh? I got one today, I just need
to replace all the capacitors to get it working. Cheap caps
syndrome, I assume.
More information about the Nouveau