Hi there, Im using GeForce FX5200 dual DVI graphics adapter connected with two Samsung 204b monitors. At the moment I'm using binary nvidia drivers and everything works fine but I'm forced to switch to nouveau. Unfortunately there are problems. It seems that nouveau.ko wrongly detects the PixelClock of my monitors. More precisely, after loading of nouveu.ko the screen starts to blink. According to my experience the problem is too hight PixelClock. Moreover, in the /var/log/Xorg.0.log you can find the line: NOUVEAU(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 175 MHz which is false. The maximum PixClk for Sumsung 204b is 162MHz. I was trying to play with the video= kernel parameter but there is no way to force the PixClk. I was also trying to edit the suitable ModeLine in the drivers/gpu/drm/drm_edid_modes.h but I thing nouveau.ko ignores it. So my question is what to change (in the kernel source) to override the detection and force MaxPixelClock to 162MHz just to make sure that the problem is related to PixelClock. To build the kernel I used the kernel tree downloaded from nouveau about one week ago. Thanks in advance for any help.
On Sat, 25 Sep 2010 16:04:23 +0200 Grzesiek S?jka <pld at pfu.pl> wrote:> Im using GeForce FX5200 dual DVI graphics adapter connected with > two Samsung 204b monitors. At the moment I'm using binary nvidia > drivers and everything works fine but I'm forced to switch to > nouveau. Unfortunately there are problems. It seems that > nouveau.ko wrongly detects the PixelClock of my monitors. More > precisely, after loading of nouveu.ko the screen starts to blink. > According to my experience the problem is too hight PixelClock. > Moreover, in the /var/log/Xorg.0.log you can find the line: > > NOUVEAU(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 > kHz, PixClock max 175 MHz > > which is false. The maximum PixClk for Sumsung 204b is 162MHz. I > was trying to play with the video= kernel parameter but there is > no way to force the PixClk.Are you saying that forcing a low-refresh-rate mode via videokernel 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. Cheers. -- Pekka Paalanen http://www.iki.fi/pq/
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. 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. 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.
By the way: There is now direct implication between the refresh rate and the PixelClock. In theory you can do arbitrary low resolution/refresh rate by arbitrary high PixelClock. Only thing is that setting to high values of PixelClock does not make any sense.
On 10/05/10 23:53, Grzesiek S?jka wrote:> On 10/05/10 23:45, Marcin Slusarz wrote: >> Just a quick note: this BUG should be easily fixable by applying >> the same fix Francisco did for amd-k7-agp.c/amd_insert_memory to >> amd_remove_memory. > I was the one that reported the problem leading to this patch and at the > moment all my kernels are patched with it.Sorry, I misunderstood your comment. Just ignore my previous answer.