Distribution: gentoo Hardware Environment: dual Athlon MP 2000+ nVidia 6800 video card CTX LCD FlatView P922E monitor Problem Description: When using nvidiafb the following happens: On setting the video mode, the kernel changes into a 1280x1024 video mode, which matches my LCD monitor. However, the display is shifted to the right, so that text begins at about half the monitor. The first 4 characters of each line are doubled, for instance "Hello world" would appear as "HellHello world". Some of the text that doesn't fit on the screen isn't visible, with the rest wrapping around and appearing on the left side of the screen. I have found a patch addressing an issue that sounds exactly like this for a laptop, however, as far as I can see, the 2.6.13 kernel already has that fix, but my problem happens anyway: http://www.mail-archive.com/git-commits-head%40vger.kernel.org/msg00081.html Steps to reproduce: enable nvidiafb, boot
Created attachment 5836 [details] VESA Coordinated Video Timings Support
Created attachment 5837 [details] Calculate timings using CVT if with flatpanel display and no EDID
Okay, it does sound a timings problem. Unfortunately, nvidiafb (and most drivers) will get the mode timings from the global mode database if the EDID block was not probed. However, most of the entries in the global mode database are made for CRT monitors, and will have problems displaying in digital displays. One solution is to use VESA CVT to calculate the timings instead of adding entries to the global mode database. One good thing about the VESA CVT is that it can calculate timings for digital displays and CRT's. Apply the two patches and reboot. If you want, you can force nvidiafb to use CVT by adding this in your kernel config: video=nvidiafb:1280x1024MR@60 Post your dmesg afterwards.
Applied the patches, unfortunately the problem persists. There are no visible changes as far as I can see. Here are the nvidiafb related lines from dmesg, will add the whole thing as attachment: [4294667.296000] Linux version 2.6.13 (root@alice) (gcc version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #2 SMP Thu Sep 1 19:28:45 CEST 2005 [4294667.296000] Kernel command line: BOOT_IMAGE=nVidia-2.6.13 root=343 video=nvidiafb:1280x1024MR@60 [4294670.719000] nvidiafb: nVidia device/chipset 10DE0041 [4294670.719000] nvidiafb: nVidia Corporation NV40 [GeForce 6800] [4294670.724000] nvidiafb: CRTC0 not found [4294670.728000] nvidiafb: CRTC1 not found [4294670.842000] nvidiafb: EDID found from BUS1 [4294670.858000] nvidiafb: CRTC 0 is currently programmed for DFP [4294670.858000] nvidiafb: Using DFP on CRTC 0 [4294670.858000] Panel size is 1280 x 1024 [4294670.859000] nvidiafb: MTRR set to ON [4294670.859000] fbcvt: 1280x1024@60: CVT Name - 1.310M4-R [4294670.870000] Console: switching to colour frame buffer device 160x64 [4294670.870000] nvidiafb: PCI nVidia NV4 framebuffer (64MB @ 0xF0000000)
Created attachment 5851 [details] dmesg output after applying the patches
I don't think the CVT patch will help in your case since the EDID was successfully probed by the driver. The EDID is preferred to the CVT, unless it's overriden. And you still have display problems. Can you open drivers/video/fbmon.c and change this line: #undef DEBUG to #define DEBUG Then post your dmesg output again (just the parts about nvidiafb and edid). Also, does X's nv driver work with your machine?
Ok, just checked. nv indeed works, and the VESA console also works. I don't really like VESA because it's slow though, but other than that it looks just fine. Here's the nvidiafb log: [4294671.227000] nvidiafb: nVidia device/chipset 10DE0041 [4294671.227000] nvidiafb: nVidia Corporation NV40 [GeForce 6800] [4294671.231000] nvidiafb: CRTC0 not found [4294671.235000] nvidiafb: CRTC1 not found [4294671.348000] nvidiafb: EDID found from BUS1 [4294671.348000] ======================================== [4294671.348000] Display Information (EDID) [4294671.348000] ======================================== [4294671.348000] EDID Version 1.3 [4294671.348000] Manufacturer: CTX [4294671.349000] Model: 4002 [4294671.349000] Serial#: 0 [4294671.349000] Year: 2003 Week 0 [4294671.349000] Monitor Name: CTX P922 DVI [4294671.349000] ASCII Block: [4294671.349000] Display Characteristics: [4294671.349000] Monitor Operating Limits: From EDID [4294671.349000] H: 30-66KHz V: 59-61Hz DCLK: 110MHz [4294671.349000] Digital Display Input [4294671.349000] Sync: [4294671.349000] Max H-size in cm: 38 [4294671.349000] Max V-size in cm: 31 [4294671.349000] Gamma: 2.20 [4294671.349000] DPMS: Active yes, Suspend no, Standby no [4294671.349000] RGB Color Display [4294671.349000] Chroma [4294671.349000] RedX: 0.634 RedY: 0.354 [4294671.349000] GreenX: 0.304 GreenY: 0.580 [4294671.349000] BlueX: 0.143 BlueY: 0.102 [4294671.349000] WhiteX: 0.310 WhiteY: 0.329 [4294671.349000] First DETAILED Timing is preferred [4294671.349000] Supported VESA Modes [4294671.349000] 640x480@60Hz [4294671.349000] 800x600@60Hz [4294671.349000] 1024x768@60Hz [4294671.350000] Manufacturer's mask: 0 [4294671.350000] Standard Timings [4294671.350000] 1280x1024@60Hz [4294671.350000] Detailed Timings [4294671.350000] 108 MHz 1280 1328 1440 1688 1024 1025 1028 1066 +HSync +VSync [4294671.350000] [4294671.350000] ======================================== [4294671.366000] nvidiafb: CRTC 0 is currently programmed for DFP [4294671.366000] nvidiafb: Using DFP on CRTC 0 [4294671.366000] Panel size is 1280 x 1024 [4294671.367000] nvidiafb: MTRR set to ON [4294671.367000] fbcvt: 1280x1024@60: CVT Name - 1.310M4-R [4294671.378000] Console: switching to colour frame buffer device 160x64 [4294671.378000] nvidiafb: PCI nVidia NV4 framebuffer (64MB @ 0xF0000000) And here's the log from the kernel I'm currently running with vesafb, in case it gives you any information: vesafb: NVIDIA Corporation, nv40 Board - p212-0 , Chip Rev (OEM: NVIDIA) vesafb: VBE version: 3.0 vesafb: protected mode interface info at c000:ce20 vesafb: pmi: set display start = c00cce56, set palette = c00ccec0 vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da vesafb: hardware supports DCC2 transfers vesafb: monitor limits: vf = 61 Hz, hf = 66 kHz, clk = 110 MHz vesafb: scrolling: ywrap using protected mode interface, yres_virtual=2048 Console: switching to colour frame buffer device 160x64 vesafb: framebuffer at 0xf0000000, mapped to 0xf8880000, using 10240k, total 131072k fb0: VESA VGA frame buffer device
Can you try adjusting your timings using fbset. For example, convert the timings in Xorg/XFree86 to framebuffer modeline. Then use that with fbset and see if it actually makes a difference. If possible, disable other framebuffer drivers in your kernel config.
Ok, will try. The kernel with nvidiafb doesn't have any other framebuffer drivers enabled.
Aargh, I don't get it. Been messing with it for quite a while, and here's what I get: Under nvidiafb the default mode is: mode "1280x1024-60" # D: 91.000 MHz, H: 63.195 kHz, V: 59.957 Hz geometry 1280 1024 1280 32767 8 timings 10989 48 80 20 3 32 7 hsync high extsync true accel true rgba 8/0,8/0,8/0,0/0 endmode Under VESA it is: mode "1280x1024-60" # D: 108.003 MHz, H: 63.983 kHz, V: 60.021 Hz geometry 1280 1024 1280 2048 32 timings 9259 248 48 38 1 112 3 hsync high vsync high rgba 8/16,8/8,8/0,8/24 endmode xorg says: (**) NV(0): *Default mode "1280x1024": 157.5 MHz, 91.1 kHz, 85.0 Hz (II) NV(0): Modeline "1280x1024" 157.50 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync From that I calculate: mode "1280x1024" # D: 157.50 MHz, H: 91.15 kHz, V: 85.02 Hz geometry 1280 1024 1280 1024 32 timings 6349 224 64 160 44 1 3 endmode Actual mode that results when I set it: mode "1280x1024-60" # D: 108.003 MHz, H: 63.983 kHz, V: 60.021 Hz geometry 1280 1024 1280 1024 32 timings 9259 248 48 38 1 112 3 hsync high vsync high accel true rgba 8/16,8/8,8/0,8/24 endmode Geometry is set, but timings are bizarrely ignored. The screen now moves to the left, and text starts at about 1/4 from the left. Character duplication is reduced to 1 character. Now it blinks every 2 seconds, though. After lots of testing, I'm still failing at changing the timings. Any ideas?
Okay. I'll send you a test patch later that will use vesafb to set the initial mode of nvidiafb.
Ok, but if by "send" you mean email, my vadim.ws address is currently not working due to the server being dead.
Created attachment 5873 [details] Use vesa for mode setting Try this patch for nvidia. It uses the VESA framebuffer to set the initial mode of nvidiafb. So you have to boot with something like this: video=nvidiafb vga=0xnnn This is untested and the info that you get from fbset -i may not be correct (it's just for show), but send it anyway. Also, you won't be able to change the mode.
Created attachment 5874 [details] Use vesa for mode setting 2 Use this patch instead
Ok, tried that with vba=0x31B (1280x1024, 16M) Video mode changes early during the kernel's boot (earlier than where nvidiafb used to do it), screen goes completely black and that's it. There are no signs of that the kernel continues booting. only nvidiafb was enabled in the config, vesafb was not. But since it builds correctly I suppose that is fine? Also, makeing it build required setting CONFIG_KALLSYMS_EXTRA_PASS, as recommended by the error message I got.
Can you try booting with fbcon=map:9? You'll get no display, but you should be able to boot. Then just blindly login to X or something and post dmesg and fbset -1.
Created attachment 6211 [details] Manipulate VGA registers as closely as possible as the nv driver Can you try this patch? This patch is against the latest 2.6.14-rc3. Please let me know if this fixes your problem. Thanks
Any follow ups on this? Can you either try the latest patch, or use linux-2.6. 14-rc5-mm1?
My ACER TM 630 with nVidia GeForce2 Go and a 1400x1050 LCD needs the following mode line in modedb.c. All other existing mode lines in 2.6.14 produce a really bad flicker. I used the timings reported by the Xorg nv driver. Using this mode line I get the perfect image: /* 1400x1050 @ 75 Hz, 81.5 kHz +hsync +vsync*/ NULL, 75, 1400, 1050, 6418, 128, 40, 12, 0, 112, 3, FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
Created attachment 6607 [details] modedb update or if you prefer a patch...
/* 1400x1050 @ 75 Hz, 81.5 kHz +hsync +vsync*/ NULL, 75, 1400, 1050, 6418, 128, 40, 12, 0, 112, 3, FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED Is EDID available with your particular card? Can you check dmesg?
dmesg | grep -i edid did not return anything. I had enabled DEBUG in fbmon and nvidiafb once but there was never any information about EDID in dmesg. So I guess EDID does not work. I have also disabled EDID in Xorg because it never worked.
> I had enabled DEBUG in fbmon and nvidiafb once but > there was never any information about EDID in dmesg. So I guess EDID does not > work. I have also disabled EDID in Xorg because it never worked. I really hate it when manufacturers create a nonstandard mode and does not make it known to drivers such as via EDID. Anyway, can you try one last thing? Can you boot with: video=nvidiafb:1400x1050M@75 or video=nvidiafb:1400x1050MR@75 (You need at least a 2.6.14 kernel) If none of the above works, then I guess it's just right to include your laptop's mode in the global mode database.
You can also try different refresh rates, ie, 60Hz seems more appropriate for laptop displays. 1400x1050M@60 1400x1050MR@60
Antonio, I had tried exactly all this before I patched my kernel. I had also tried with vesafb - no luck either. Please note that even with my patch I need to boot with video=nvidiafb:1400x1050MR@75 I noticed that before the patch, the driver always fell back to this 60Hz mode which causes the bad flickering. I actually guess the panel totally failed to sync, as there were flickering vertical stripes as well.: mode "1400x1050-60" # D: 101.010 MHz, H: 64.750 kHz, V: 59.954 Hz geometry 1400 1050 1408 23738 8 timings 9900 80 48 3 23 32 4 hsync high accel true rgba 8/0,8/0,8/0,0/0 endmode which seems to correspond to the following mode in the modedb: /* 1400x1050 @ 60 Hz, 64.75 kHz +hsync +vsync*/ NULL, 60, 1400, 1050, 9259, 128, 40, 12, 0, 112, 3, FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED I agree it's terrible that the vendors do this. Maybe there should be kconfig options to enable or disable individual modes or even specify a custom one.
> I had tried exactly all this before I patched my kernel. I had also tried > with > vesafb - no luck either. Well, 1400x1050 is not a standard VESA mode so, VESA does not have an id for it. You may get lucky if the vendor provides its own OEM id. > Please note that even with my patch I need to boot with > video=nvidiafb:1400x1050MR@75 Surprised. If you append an M after the xres and yres of the mode option, it automatically calculates the timings (using CVT) instead of searching the mode database. Can you grep your dmesg for 'fbcvt'?
But then why does it only work if I apply the patch? $ dmesg | grep fbcvt fbcvt: 1400x1050@60: CVT Name - 1.470M3-R fbcvt: Refresh rate not CVT standard fbcvt: 60Hz refresh rate advised for reduced blanking fbcvt: 1400x1050@75: CVT Name - Not a CVT standard - 1.470 Mega Pixel Image
> But then why does it only work if I apply the patch? I don't know. The only possible thing I can think of is that nvidiafb refused the CVT mode. But that is impossible if the display has no EDID block. You can confirm by defining DEBUG in modedb.c and posting your dmesg again. Also, send the output of fbset -i. I want to confirm if the mode actually came from the CVT calculation. > $ dmesg | grep fbcvt > fbcvt: 1400x1050@60: CVT Name - 1.470M3-R > fbcvt: Refresh rate not CVT standard The above message is because nvidiafb uses the panel xres and yres to compute a reduced blanking cvt mode. This only happens if the display has no edid block. > fbcvt: 60Hz refresh rate advised for reduced blanking > fbcvt: 1400x1050@75: CVT Name - Not a CVT standard - 1.470 Mega Pixel Image The above message is from your boot mode option. This mode should override the first CVT calculation.
Now, I am definitely embarassed. It works on a vanilla kernel with video=nvidiafb:1400x1050MR@75 I could have sworn I tried that extensively! Apparently I messed up. mode "1400x1050-75" # D: 127.259 MHz, H: 81.576 kHz, V: 74.978 Hz geometry 1400 1050 1408 23738 8 timings 7858 80 48 3 31 32 4 hsync high accel true rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name : NV11 Address : 0xe8000000 Size : 33554432 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 8 YPanStep : 1 YWrapStep : 0 LineLength : 1408 MMIO Address: 0xe1000000 MMIO Size : 16777216 Accelerator : Unknown (43) from dmesg (not those weird more 'names'): nvidiafb: nVidia device/chipset 10DE0112 nvidiafb: CRTC 1 is currently programmed for DFP nvidiafb: Using DFP on CRTC 1 Panel size is 1400 x 1050 nvidiafb: MTRR set to ON modedb fb_find_mode: CVT mode 1400x1050@60Hz reduced blanking fbcvt: 1400x1050@60: CVT Name - 1.470M3-R modedb fb_try_mode: Trying mode <89>