* Blanky rivafb vs snowy nvidiafb with 2.6.12 @ 2005-09-28 14:12 Giuseppe Bilotta 2005-09-28 21:01 ` Antonino A. Daplas 0 siblings, 1 reply; 12+ messages in thread From: Giuseppe Bilotta @ 2005-09-28 14:12 UTC (permalink / raw) To: linux-kernel Hello all, I have a Dell Inspiron 8200 with an nVidia GeForce2 Go video card. There are currently two Linux kerenl framebuffer drivers that I can try to use (rivafb and nvidiafb) but they both have issues: * rivafb works when compiled in, but not when compiled as a module: in the latter case, as soon as the fb is touched (even just by a fbset -i) the screen goes unrecoverably blank, although the computer is still usable (blindly). Interestingly, enabling the very verbose debug output allows the module to work, but as soon as scrolling beings the screen is continuously filled by the (very verbose) debug output and scrolls on forever. * I have thus tried the new nvidiafb driver, which seems to work ok, except for the minor detail that the display is extremely snowy. Attempts to change the timing options with fbset fail: fbset seems to accept the settings, no error message is given, but nothing is changed. The X nv driver select the correct timings, so I tried modeline2fb to make fbset use those, but still nothing changes. Any suggestions? -- Giuseppe "Oblomov" Bilotta "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-28 14:12 Blanky rivafb vs snowy nvidiafb with 2.6.12 Giuseppe Bilotta @ 2005-09-28 21:01 ` Antonino A. Daplas 2005-09-29 11:41 ` Giuseppe Bilotta 0 siblings, 1 reply; 12+ messages in thread From: Antonino A. Daplas @ 2005-09-28 21:01 UTC (permalink / raw) To: Giuseppe Bilotta; +Cc: linux-kernel Giuseppe Bilotta wrote: > Hello all, > > * I have thus tried the new nvidiafb driver, which seems to work ok, > except for the minor detail that the display is extremely snowy. > Attempts to change the timing options with fbset fail: fbset seems to > accept the settings, no error message is given, but nothing is > changed. The X nv driver select the correct timings, so I tried > modeline2fb to make fbset use those, but still nothing changes. > What's the dmesg output? What's fbset -i output? Can you try doing fbset -accel false and see if it makes a difference? Tony ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-28 21:01 ` Antonino A. Daplas @ 2005-09-29 11:41 ` Giuseppe Bilotta 2005-09-29 12:39 ` Antonino A. Daplas 2005-09-29 12:40 ` Antonino A. Daplas 0 siblings, 2 replies; 12+ messages in thread From: Giuseppe Bilotta @ 2005-09-29 11:41 UTC (permalink / raw) To: linux-kernel On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: > Giuseppe Bilotta wrote: >> Hello all, >> > >> * I have thus tried the new nvidiafb driver, which seems to work ok, >> except for the minor detail that the display is extremely snowy. >> Attempts to change the timing options with fbset fail: fbset seems to >> accept the settings, no error message is given, but nothing is >> changed. The X nv driver select the correct timings, so I tried >> modeline2fb to make fbset use those, but still nothing changes. >> > > What's the dmesg output? """ nvidiafb: nVidia device/chipset 10DE0112 nvidiafb: nVidia Corporation NV11 [GeForce2 Go] nvidiafb: EDID found from BUS2 nvidiafb: CRTC 1 is currently programmed for DFP nvidiafb: Using DFP on CRTC 1 Panel size is 1600 x 1200 nvidiafb: MTRR set to ON Console: switching to colour frame buffer device 200x75 nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000) """ (do you need more?) > What's fbset -i output? Right after modprobing nvidiafb: """ mode "1600x1200-61" # D: 160.000 MHz, H: 75.758 kHz, V: 60.606 Hz geometry 1600 1200 1600 20889 8 timings 6250 256 64 46 1 192 3 accel true rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name : NV11 Address : 0xe0000000 Size : 33554432 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 8 YPanStep : 1 YWrapStep : 0 LineLength : 1600 MMIO Address: 0xfc000000 MMIO Size : 16777216 Accelerator : Unknown (43) """ After trying fbset "1600x1200": """ mode "1600x1200-61" # D: 160.000 MHz, H: 75.758 kHz, V: 60.606 Hz geometry 1600 1200 1920 17408 8 timings 6250 256 64 46 1 192 3 accel true rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name : NV11 Address : 0xe0000000 Size : 33554432 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 8 YPanStep : 1 YWrapStep : 0 LineLength : 1920 MMIO Address: 0xfc000000 MMIO Size : 16777216 Accelerator : Unknown (43) """ The "1600x1200" mode is: """ mode "1600x1200" geometry 1600 1200 1920 17467 8 timings 6172 304 64 46 1 192 3 hsync high vsync high endmode """ So as you can see the problem is that the timings are NOT set by fbset. No error messages or anything. > Can you try doing fbset -accel false and see if it makes a difference? Nope, same thing. Also with modprobe nvidiafb noaccel=1. -- Giuseppe "Oblomov" Bilotta "I weep for our generation" -- Charlie Brown ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-29 11:41 ` Giuseppe Bilotta @ 2005-09-29 12:39 ` Antonino A. Daplas 2005-09-29 12:40 ` Antonino A. Daplas 1 sibling, 0 replies; 12+ messages in thread From: Antonino A. Daplas @ 2005-09-29 12:39 UTC (permalink / raw) To: Giuseppe Bilotta; +Cc: linux-kernel Giuseppe Bilotta wrote: > On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: > >> Giuseppe Bilotta wrote: >>> Hello all, >>> >>> * I have thus tried the new nvidiafb driver, which seems to work ok, >>> except for the minor detail that the display is extremely snowy. >>> Attempts to change the timing options with fbset fail: fbset seems to >>> accept the settings, no error message is given, but nothing is >>> changed. The X nv driver select the correct timings, so I tried >>> modeline2fb to make fbset use those, but still nothing changes. >>> >> What's the dmesg output? > > """ > nvidiafb: nVidia device/chipset 10DE0112 > nvidiafb: nVidia Corporation NV11 [GeForce2 Go] > nvidiafb: EDID found from BUS2 > nvidiafb: CRTC 1 is currently programmed for DFP > nvidiafb: Using DFP on CRTC 1 > Panel size is 1600 x 1200 > nvidiafb: MTRR set to ON > Console: switching to colour frame buffer device 200x75 > nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000) > """ > > (do you need more?) > >> What's fbset -i output? > > Right after modprobing nvidiafb: > > """ > mode "1600x1200-61" > # D: 160.000 MHz, H: 75.758 kHz, V: 60.606 Hz > geometry 1600 1200 1600 20889 8 > timings 6250 256 64 46 1 192 3 > accel true > rgba 8/0,8/0,8/0,0/0 > endmode > > Frame buffer device information: > Name : NV11 > Address : 0xe0000000 > Size : 33554432 > Type : PACKED PIXELS > Visual : PSEUDOCOLOR > XPanStep : 8 > YPanStep : 1 > YWrapStep : 0 > LineLength : 1600 > MMIO Address: 0xfc000000 > MMIO Size : 16777216 > Accelerator : Unknown (43) > """ > > After trying fbset "1600x1200": > > """ > mode "1600x1200-61" > # D: 160.000 MHz, H: 75.758 kHz, V: 60.606 Hz > geometry 1600 1200 1920 17408 8 > timings 6250 256 64 46 1 192 3 > accel true > rgba 8/0,8/0,8/0,0/0 > endmode > > Frame buffer device information: > Name : NV11 > Address : 0xe0000000 > Size : 33554432 > Type : PACKED PIXELS > Visual : PSEUDOCOLOR > XPanStep : 8 > YPanStep : 1 > YWrapStep : 0 > LineLength : 1920 > MMIO Address: 0xfc000000 > MMIO Size : 16777216 > Accelerator : Unknown (43) > """ > > The "1600x1200" mode is: > > """ > mode "1600x1200" > geometry 1600 1200 1920 17467 8 > timings 6172 304 64 46 1 192 3 > hsync high > vsync high > endmode > """ > > So as you can see the problem is that the timings are NOT set by > fbset. No error messages or anything. > >> Can you try doing fbset -accel false and see if it makes a difference? > > Nope, same thing. Also with modprobe nvidiafb noaccel=1. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-29 11:41 ` Giuseppe Bilotta 2005-09-29 12:39 ` Antonino A. Daplas @ 2005-09-29 12:40 ` Antonino A. Daplas 2005-09-29 15:43 ` Giuseppe Bilotta 1 sibling, 1 reply; 12+ messages in thread From: Antonino A. Daplas @ 2005-09-29 12:40 UTC (permalink / raw) To: Giuseppe Bilotta; +Cc: linux-kernel Giuseppe Bilotta wrote: > On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: > >> Giuseppe Bilotta wrote: > > So as you can see the problem is that the timings are NOT set by > fbset. No error messages or anything. > Sorry about the blank reply, hit send accidentally. Probably, the EDID block is incomplete, so nvidiafb is refusing custom modes. You can change the #undef DEBUG to #define DEBUG in drivers/video/fbmon.c to see verbose output of the EDID block in dmesg. Then, can you recompile without the DDC/I2C support, and boot with: video=nvidiafb:1600x1200-60, then play with fbset later on. If possible, you can also get the latest git snapshot then boot with: video=nvidiafb:1600x1200MR Note the appended MR - it's CVT with reduced blanking - which is for LCD displays especially those manufactured by Dell since they are the proponents of CVT. Tony ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-29 12:40 ` Antonino A. Daplas @ 2005-09-29 15:43 ` Giuseppe Bilotta 2005-09-29 20:47 ` Antonino A. Daplas 0 siblings, 1 reply; 12+ messages in thread From: Giuseppe Bilotta @ 2005-09-29 15:43 UTC (permalink / raw) To: linux-kernel On Thu, 29 Sep 2005 20:40:49 +0800, Antonino A. Daplas wrote: > Giuseppe Bilotta wrote: >> On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: >> >>> Giuseppe Bilotta wrote: >> >> So as you can see the problem is that the timings are NOT set by >> fbset. No error messages or anything. > > Sorry about the blank reply, hit send accidentally. > > Probably, the EDID block is incomplete, so nvidiafb is refusing > custom modes. You can change the #undef DEBUG to #define DEBUG > in drivers/video/fbmon.c to see verbose output of the EDID block in > dmesg. Here you are: """ nvidiafb: nVidia device/chipset 10DE0112 nvidiafb: nVidia Corporation NV11 [GeForce2 Go] nvidiafb: EDID found from BUS2 ======================================== Display Information (EDID) ======================================== EDID Version 1.3 Manufacturer: SHP Model: 138e Serial#: 0 Year: 1990 Week 0 Display Characteristics: Monitor Operating Limits: Supported VESA Modes Manufacturer's mask: 0 Standard Timings 1600x1200@60Hz Detailed Timings 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync Extrapolated H: 75-75KHz V: 60-60Hz DCLK: 162MHz Digital Display Input Sync: Max H-size in cm: 30 Max V-size in cm: 23 Gamma: 2.20 DPMS: Active no, Suspend yes, Standby yes RGB Color Display Chroma RedX: 0.599 RedY: 0.335 GreenX: 0.313 GreenY: 0.552 BlueX: 0.150 BlueY: 0.145 WhiteX: 0.313 WhiteY: 0.328 First DETAILED Timing is preferred Supported VESA Modes Manufacturer's mask: 0 Standard Timings 1600x1200@60Hz Detailed Timings 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync ======================================== nvidiafb: CRTC 1 is currently programmed for DFP nvidiafb: Using DFP on CRTC 1 Panel size is 1600 x 1200 nvidiafb: MTRR set to ON nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000) """ > Then, can you recompile without the DDC/I2C support, and boot with: > > video=nvidiafb:1600x1200-60, then play with fbset later on. Remember I'm using nvidiafb as a module, it's not compiled in. So what I do is modprobe nvidiafb Is there a way to specifiy resolution when loading nvidiafb this way? Presently, when compiling without DDC support, I get this: """ mode "640x480-60" # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz geometry 640 480 640 32767 8 timings 39721 40 24 32 11 96 2 accel true rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name : NV11 Address : 0xe0000000 Size : 33554432 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 8 YPanStep : 1 YWrapStep : 0 LineLength : 0 MMIO Address: 0xfc000000 MMIO Size : 16777216 Accelerator : Unknown (43) """ and then, after fbset "1600x1200" """ mode "1600x1200-60" # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz geometry 1600 1200 1920 17408 8 timings 6172 304 64 46 1 192 3 hsync high vsync high accel true rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name : NV11 Address : 0xe0000000 Size : 33554432 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 8 YPanStep : 1 YWrapStep : 0 LineLength : 1920 MMIO Address: 0xfc000000 MMIO Size : 16777216 Accelerator : Unknown (43) """ but a borked screen (see further down) BTW, I think that having it in module form may be part of the problem: even the old rivafb acted differently when in module form (as I mentioned in my original post) BTW #2: There are two interesting differences between the (modularized) nvidiafb in Debian and the one from my kernel: 1. Debian's nvidiafb resets the console font to 200x75 on load, while the one from my kernel doesn't 2. If I try to change resolution or color depth when using my kernel, the screen gets garbled, and there is no way to restore it. > If possible, you can also get the latest git snapshot then boot with: > > video=nvidiafb:1600x1200MR > > Note the appended MR - it's CVT with reduced blanking - which is > for LCD displays especially those manufactured by Dell since they > are the proponents of CVT. I'm afraid this will have to wait. And while we're talking about Dell: my configuration (GeForce2 Go on Dell Inspiron 8200 with UXGA monitor 15" at 1600x1200) is known to be borky even with nVidia's own driver for Windows XP --not all versions work correctly. -- Giuseppe "Oblomov" Bilotta [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-29 15:43 ` Giuseppe Bilotta @ 2005-09-29 20:47 ` Antonino A. Daplas 2005-09-30 8:53 ` Giuseppe Bilotta 0 siblings, 1 reply; 12+ messages in thread From: Antonino A. Daplas @ 2005-09-29 20:47 UTC (permalink / raw) To: Giuseppe Bilotta; +Cc: linux-kernel Giuseppe Bilotta wrote: > On Thu, 29 Sep 2005 20:40:49 +0800, Antonino A. Daplas wrote: > >> Giuseppe Bilotta wrote: >>> On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: >>> >>>> Giuseppe Bilotta wrote: >>> So as you can see the problem is that the timings are NOT set by >>> fbset. No error messages or anything. >> Sorry about the blank reply, hit send accidentally. >> >> Probably, the EDID block is incomplete, so nvidiafb is refusing >> custom modes. You can change the #undef DEBUG to #define DEBUG >> in drivers/video/fbmon.c to see verbose output of the EDID block in >> dmesg. > > Here you are: > > """ > nvidiafb: nVidia device/chipset 10DE0112 > nvidiafb: nVidia Corporation NV11 [GeForce2 Go] > nvidiafb: EDID found from BUS2 > ======================================== > Display Information (EDID) > ======================================== > EDID Version 1.3 > Manufacturer: SHP > Model: 138e > Serial#: 0 > Year: 1990 Week 0 > Display Characteristics: > Monitor Operating Limits: Supported VESA Modes > Manufacturer's mask: 0 > Standard Timings > 1600x1200@60Hz > Detailed Timings > 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync > > Extrapolated > H: 75-75KHz V: 60-60Hz DCLK: 162MHz > Digital Display Input > Sync: > Max H-size in cm: 30 > Max V-size in cm: 23 > Gamma: 2.20 > DPMS: Active no, Suspend yes, Standby yes > RGB Color Display > Chroma > RedX: 0.599 RedY: 0.335 > GreenX: 0.313 GreenY: 0.552 > BlueX: 0.150 BlueY: 0.145 > WhiteX: 0.313 WhiteY: 0.328 > First DETAILED Timing is preferred > Supported VESA Modes > Manufacturer's mask: 0 > Standard Timings > 1600x1200@60Hz > Detailed Timings > 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync > > ======================================== > nvidiafb: CRTC 1 is currently programmed for DFP > nvidiafb: Using DFP on CRTC 1 > Panel size is 1600 x 1200 > nvidiafb: MTRR set to ON > nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000) > """ The EDID supports only one mode, and no min/max vsync and hsync, so using other custom modes will not be supported. > >> Then, can you recompile without the DDC/I2C support, and boot with: >> >> video=nvidiafb:1600x1200-60, then play with fbset later on. > > Remember I'm using nvidiafb as a module, it's not compiled in. So what > I do is > > modprobe nvidiafb > > Is there a way to specifiy resolution when loading nvidiafb this way? Not currently, but you can add this at the end of drivers/video/nvidia/nvidia.c: module_param(mode_option, charp, 0); MODULE_PARM_DESC(mode_option, "Specify initial video mode"); Then load nvidiafb like this: modprobe nvidiafb mode_option=1600x1200 > Presently, when compiling without DDC support, I get this: > > """ > mode "640x480-60" > # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz > geometry 640 480 640 32767 8 > timings 39721 40 24 32 11 96 2 > accel true > rgba 8/0,8/0,8/0,0/0 > endmode > > Frame buffer device information: > Name : NV11 > Address : 0xe0000000 > Size : 33554432 > Type : PACKED PIXELS > Visual : PSEUDOCOLOR > XPanStep : 8 > YPanStep : 1 > YWrapStep : 0 > LineLength : 0 > MMIO Address: 0xfc000000 > MMIO Size : 16777216 > Accelerator : Unknown (43) > """ > > and then, after fbset "1600x1200" > > """ > mode "1600x1200-60" > # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz > geometry 1600 1200 1920 17408 8 > timings 6172 304 64 46 1 192 3 > hsync high > vsync high > accel true > rgba 8/0,8/0,8/0,0/0 > endmode > > Frame buffer device information: > Name : NV11 > Address : 0xe0000000 > Size : 33554432 > Type : PACKED PIXELS > Visual : PSEUDOCOLOR > XPanStep : 8 > YPanStep : 1 > YWrapStep : 0 > LineLength : 1920 > MMIO Address: 0xfc000000 > MMIO Size : 16777216 > Accelerator : Unknown (43) > """ > > but a borked screen (see further down) > Yes, unfortunately, nvidiafb's hardware initialization routine may disrupt the hardware state, so you need something that will use the framebuffer, such as fbcon. > BTW, I think that having it in module form may be part of the problem: > even the old rivafb acted differently when in module form (as I > mentioned in my original post) Yes, that in itself is weird. > > BTW #2: There are two interesting differences between the > (modularized) nvidiafb in Debian and the one from my kernel: > > 1. Debian's nvidiafb resets the console font to 200x75 on load, while > the one from my kernel doesn't > If a vt already exists and it has a defined font, fbcon will use that font. If there is not vt yet, or no defined font, fbcon will use one of the compiled font, usually 8x16. > 2. If I try to change resolution or color depth when using my kernel, > the screen gets garbled, and there is no way to restore it. > Yes, rivafb has the ability to save the VGA state on the first open, and restore on the last close. So rivafb, at least with some cards, using fbset without fbcon will bring you back a working VGA console. nvidiafb does not have this capability. However, if fbcon is also loaded, and you have a garbled screen after fbset, then it is a bug. >> If possible, you can also get the latest git snapshot then boot with: >> >> video=nvidiafb:1600x1200MR >> >> Note the appended MR - it's CVT with reduced blanking - which is >> for LCD displays especially those manufactured by Dell since they >> are the proponents of CVT. > > I'm afraid this will have to wait. That's okay. I'm not expecting too much from this anyway. I was thinking that the snowy screen might be due to the mode maximizing the bandwidth of the DVI. So a reduced-blanking calculation, which is not as bandwidth intensive, might be helpful. > > And while we're talking about Dell: my configuration (GeForce2 Go on > Dell Inspiron 8200 with UXGA monitor 15" at 1600x1200) is known to be > borky even with nVidia's own driver for Windows XP --not all versions > work correctly. > Hmm... But X's nv works, right? Tony ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-29 20:47 ` Antonino A. Daplas @ 2005-09-30 8:53 ` Giuseppe Bilotta 2005-10-01 5:49 ` Antonino A. Daplas 0 siblings, 1 reply; 12+ messages in thread From: Giuseppe Bilotta @ 2005-09-30 8:53 UTC (permalink / raw) To: linux-kernel On Fri, 30 Sep 2005 04:47:44 +0800, Antonino A. Daplas wrote: > Giuseppe Bilotta wrote: >> On Thu, 29 Sep 2005 20:40:49 +0800, Antonino A. Daplas wrote: >> >>> Giuseppe Bilotta wrote: >>>> On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: >>>> >>>>> Giuseppe Bilotta wrote: >>>> So as you can see the problem is that the timings are NOT set by >>>> fbset. No error messages or anything. >>> Sorry about the blank reply, hit send accidentally. >>> >>> Probably, the EDID block is incomplete, so nvidiafb is refusing >>> custom modes. You can change the #undef DEBUG to #define DEBUG >>> in drivers/video/fbmon.c to see verbose output of the EDID block in >>> dmesg. >> >> Here you are: >> >> """ >> nvidiafb: nVidia device/chipset 10DE0112 >> nvidiafb: nVidia Corporation NV11 [GeForce2 Go] >> nvidiafb: EDID found from BUS2 >> ======================================== >> Display Information (EDID) >> ======================================== >> EDID Version 1.3 >> Manufacturer: SHP >> Model: 138e >> Serial#: 0 >> Year: 1990 Week 0 >> Display Characteristics: >> Monitor Operating Limits: Supported VESA Modes >> Manufacturer's mask: 0 >> Standard Timings >> 1600x1200@60Hz >> Detailed Timings >> 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync >> >> Extrapolated >> H: 75-75KHz V: 60-60Hz DCLK: 162MHz >> Digital Display Input >> Sync: >> Max H-size in cm: 30 >> Max V-size in cm: 23 >> Gamma: 2.20 >> DPMS: Active no, Suspend yes, Standby yes >> RGB Color Display >> Chroma >> RedX: 0.599 RedY: 0.335 >> GreenX: 0.313 GreenY: 0.552 >> BlueX: 0.150 BlueY: 0.145 >> WhiteX: 0.313 WhiteY: 0.328 >> First DETAILED Timing is preferred >> Supported VESA Modes >> Manufacturer's mask: 0 >> Standard Timings >> 1600x1200@60Hz >> Detailed Timings >> 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync >> >> ======================================== >> nvidiafb: CRTC 1 is currently programmed for DFP >> nvidiafb: Using DFP on CRTC 1 >> Panel size is 1600 x 1200 >> nvidiafb: MTRR set to ON >> nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000) >> """ > > The EDID supports only one mode, and no min/max vsync and hsync, > so using other custom modes will not be supported. Exactly as you predicted. What I don't understand, however, is why nvidiafb and xorg's nv give different results. Remember, xorg ends up using (**) NV(0): *Default mode "1600x1200": 162.0 MHz, 75.0 kHz, 60.0 Hz (II) NV(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync xorg DDC repports the following: """ (II) NV(0): I2C bus "DDC" initialized. (II) NV(0): Probing for EDID on I2C bus A... (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. (II) NV(0): ... none found (II) NV(0): Probing for EDID on I2C bus B... (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. (--) NV(0): DDC detected a DFP: (II) NV(0): Manufacturer: SHP Model: 138e Serial#: 0 (II) NV(0): Year: 1990 Week: 0 (II) NV(0): EDID Version: 1.3 (II) NV(0): Digital Display Input (II) NV(0): Max H-Image Size [cm]: horiz.: 30 vert.: 23 (II) NV(0): Gamma: 2.20 (II) NV(0): DPMS capabilities: StandBy Suspend; RGB/Color Display (II) NV(0): First detailed timing is preferred mode (II) NV(0): redX: 0.599 redY: 0.335 greenX: 0.312 greenY: 0.552 (II) NV(0): blueX: 0.150 blueY: 0.145 whiteX: 0.312 whiteY: 0.328 (II) NV(0): Manufacturer's mask: 0 (II) NV(0): Supported Future Video Modes: (II) NV(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) NV(0): Supported additional Video Mode: (II) NV(0): clock: 160.0 MHz Image Size: 304 x 228 mm (II) NV(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2112 h_border: 0 (II) NV(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (--) NV(0): CRTC 1 is currently programmed for DFP (II) NV(0): Using DFP on CRTC 1 (--) NV(0): Panel size is 1600 x 1200 (--) NV(0): VideoRAM: 32768 kBytes """ and my Modelines go simply like this: """ SubSection "Display" Depth 1 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubSection """ (for Depth = 1, 4, 8, 15, 16, 24, the latter being the default) >>> Then, can you recompile without the DDC/I2C support, and boot with: >>> >>> video=nvidiafb:1600x1200-60, then play with fbset later on. >> >> Remember I'm using nvidiafb as a module, it's not compiled in. So what >> I do is >> >> modprobe nvidiafb >> >> Is there a way to specifiy resolution when loading nvidiafb this way? > > Not currently, but you can add this at the end of drivers/video/nvidia/nvidia.c: > > module_param(mode_option, charp, 0); > MODULE_PARM_DESC(mode_option, "Specify initial video mode"); > > Then load nvidiafb like this: > > modprobe nvidiafb mode_option=1600x1200 Nice one, I'll give it a shot. > Yes, unfortunately, nvidiafb's hardware initialization routine > may disrupt the hardware state, so you need something that will > use the framebuffer, such as fbcon. D'oh. D'oh. D'oh. I *really* need someone to repeatedly and savagely hit me on the head with a gigantic, purple-and-yellow CLUEBAT. *sigh* Somehow, I just assumed that modprobing for the framebuffer driver just loaded everything. But fbcon was *not* automatically load. Indeed, modprobing for fbcon allows me to load nvidiafb OR rivafb without any more screen garbling/blanking problems! This allowed me to test the rivafb driver. Some interesting results: rivafb reports this: """ rivafb: nVidia device/chipset 10DE0112 rivafb: nVidia Corporation NV11 [GeForce2 Go] rivafb: On a laptop. Assuming Digital Flat Panel rivafb: Detected CRTC controller 1 being used rivafb: RIVA MTRR set to ON rivafb: could not retrieve EDID from DDC/I2C rivafb: setting virtual Y resolution to 52428 Console: switching to colour frame buffer device 80x30 rivafb: PCI nVidia NV11 framebuffer ver 0.9.5b (32MB @ 0xE0000000) rivafb: mode 1600x1200x16 rejected...resolution too high to fit into video memory! """ Notice how rivafb can't read the EDID from DDC/I2C -- and remark that I also have problems reading the EDID with get-edid. Also interesting is that rivafb won't let me get to 16 bit depth or higher. By constrast, nvidiafb will get me even up to 32 bit depth. Now, when not using DCC with nvidiafb, I get no flickering up to 16 bits. I do get very slight snow at 24 or 32 bits. This *might* be solvable with that git patch you mentioned. >> BTW, I think that having it in module form may be part of the problem: >> even the old rivafb acted differently when in module form (as I >> mentioned in my original post) > > Yes, that in itself is weird. A posteriori, it's not weird at all :) It's just that with fbcon modular as well, it has to be loaded manually. However, this set-up uses different screen resolutions for each tty. > However, if fbcon is also loaded, and you have a garbled screen after > fbset, then it is a bug. No bug there, it seems :) >>> If possible, you can also get the latest git snapshot then boot with: >>> >>> video=nvidiafb:1600x1200MR >>> >>> Note the appended MR - it's CVT with reduced blanking - which is >>> for LCD displays especially those manufactured by Dell since they >>> are the proponents of CVT. >> >> I'm afraid this will have to wait. > > That's okay. I'm not expecting too much from this anyway. I was > thinking that the snowy screen might be due to the mode maximizing > the bandwidth of the DVI. So a reduced-blanking calculation, which > is not as bandwidth intensive, might be helpful. Could be. Especially since I'm only getting very slight snow now, and only with deep screens (24 or 32) >> And while we're talking about Dell: my configuration (GeForce2 Go on >> Dell Inspiron 8200 with UXGA monitor 15" at 1600x1200) is known to be >> borky even with nVidia's own driver for Windows XP --not all versions >> work correctly. > > Hmm... But X's nv works, right? Yes. The interesting thing now is that: 1. nv works, and gets the timing right from DDC 2. rivafb works, but can't read the EDID 3. nvidiafb can read the EDID, but it gets the timings wrong. -- Giuseppe "Oblomov" Bilotta "I'm never quite so stupid as when I'm being smart" --Linus van Pelt ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-09-30 8:53 ` Giuseppe Bilotta @ 2005-10-01 5:49 ` Antonino A. Daplas 2005-10-01 7:07 ` Giuseppe Bilotta 0 siblings, 1 reply; 12+ messages in thread From: Antonino A. Daplas @ 2005-10-01 5:49 UTC (permalink / raw) To: Giuseppe Bilotta; +Cc: linux-kernel Giuseppe Bilotta wrote: > On Fri, 30 Sep 2005 04:47:44 +0800, Antonino A. Daplas wrote: > >> Giuseppe Bilotta wrote: >>> On Thu, 29 Sep 2005 20:40:49 +0800, Antonino A. Daplas wrote: >>> >>>> Giuseppe Bilotta wrote: >>>>> On Thu, 29 Sep 2005 05:01:15 +0800, Antonino A. Daplas wrote: >>>>> >>>>>> Giuseppe Bilotta wrote: > > What I don't understand, however, is why nvidiafb and xorg's nv give > different results. Remember, xorg ends up using > > (**) NV(0): *Default mode "1600x1200": 162.0 MHz, 75.0 kHz, 60.0 Hz > > (II) NV(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 > 1201 1204 1250 +hsync +vsync > Looks like the nv driver just ignored the EDID and used one of its built-in VESA modes. If you notice, X's EDID ouput is the same as nvidiafb's. But the resulting timings are different. In contrast, nvidiafb will attempt to use the EDID, and only as a last resort, use one of the timings in the global mode database. > """ > > and my Modelines go simply like this: > """ > SubSection "Display" > Depth 1 > Modes "1600x1200" "1024x768" "800x600" "640x480" > EndSubSection > """ > (for Depth = 1, 4, 8, 15, 16, 24, the latter being the default) If you don't have a "Modeline" section in Xorg.conf, X will use one of its timings. > >> Yes, unfortunately, nvidiafb's hardware initialization routine >> may disrupt the hardware state, so you need something that will >> use the framebuffer, such as fbcon. > > D'oh. D'oh. D'oh. > > I *really* need someone to repeatedly and savagely hit me on the head > with a gigantic, purple-and-yellow CLUEBAT. *sigh* > > Somehow, I just assumed that modprobing for the framebuffer driver > just loaded everything. But fbcon was *not* automatically load. > Indeed, modprobing for fbcon allows me to load nvidiafb OR rivafb > without any more screen garbling/blanking problems! > :-) Yes, many have been burned by this assumption. If you do want 2.4 behavior, you can compile fbcon statically, nvidiafb as a module. Doing modprobe nvidiafb will automatically give you a framebuffer console. > This allowed me to test the rivafb driver. > > Some interesting results: rivafb reports this: > > """ > rivafb: nVidia device/chipset 10DE0112 > rivafb: nVidia Corporation NV11 [GeForce2 Go] > rivafb: On a laptop. Assuming Digital Flat Panel > rivafb: Detected CRTC controller 1 being used > rivafb: RIVA MTRR set to ON > rivafb: could not retrieve EDID from DDC/I2C > rivafb: setting virtual Y resolution to 52428 > Console: switching to colour frame buffer device 80x30 > rivafb: PCI nVidia NV11 framebuffer ver 0.9.5b (32MB @ 0xE0000000) > rivafb: mode 1600x1200x16 rejected...resolution too high to fit into > video memory! > """ > > Notice how rivafb can't read the EDID from DDC/I2C -- and remark that > I also have problems reading the EDID with get-edid. Also interesting read-edid though uses the Video BIOS to grab the EDID. So even your card's BIOS is having problems doing i2c/ddc. > is that rivafb won't let me get to 16 bit depth or higher. By Hmm, I'll check on that again. >>>> If possible, you can also get the latest git snapshot then boot with: >>>> >>>> video=nvidiafb:1600x1200MR >>>> >>>> Note the appended MR - it's CVT with reduced blanking - which is >>>> for LCD displays especially those manufactured by Dell since they >>>> are the proponents of CVT. >>> I'm afraid this will have to wait. >> That's okay. I'm not expecting too much from this anyway. I was >> thinking that the snowy screen might be due to the mode maximizing >> the bandwidth of the DVI. So a reduced-blanking calculation, which >> is not as bandwidth intensive, might be helpful. > > Could be. Especially since I'm only getting very slight snow now, and > only with deep screens (24 or 32) Yes, it does look like that the snow can be due to bandwidth limitation. > >>> And while we're talking about Dell: my configuration (GeForce2 Go on >>> Dell Inspiron 8200 with UXGA monitor 15" at 1600x1200) is known to be >>> borky even with nVidia's own driver for Windows XP --not all versions >>> work correctly. >> Hmm... But X's nv works, right? > > Yes. The interesting thing now is that: > > 1. nv works, and gets the timing right from DDC > 2. rivafb works, but can't read the EDID Oh well, I think rivafb and nvidiafb have different i2c timeouts. I believe the timeouts in nvidiafb are more correct. Tony ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-10-01 5:49 ` Antonino A. Daplas @ 2005-10-01 7:07 ` Giuseppe Bilotta 2005-10-01 10:49 ` Antonino A. Daplas 0 siblings, 1 reply; 12+ messages in thread From: Giuseppe Bilotta @ 2005-10-01 7:07 UTC (permalink / raw) To: linux-kernel On Sat, 01 Oct 2005 13:49:59 +0800, Antonino A. Daplas wrote: > Looks like the nv driver just ignored the EDID and used one of > its built-in VESA modes. If you notice, X's EDID ouput is the same > as nvidiafb's. But the resulting timings are different. > > In contrast, nvidiafb will attempt to use the EDID, and only as a last > resort, use one of the timings in the global mode database. I see. And when EDID is enabled for the module, it won't let me touch those timings at all. Maybe a "noddc" or "noedid" module option for when EDID support is compiled in and one wants to work without it? >> D'oh. D'oh. D'oh. >> >> I *really* need someone to repeatedly and savagely hit me on the head >> with a gigantic, purple-and-yellow CLUEBAT. *sigh* >> >> Somehow, I just assumed that modprobing for the framebuffer driver >> just loaded everything. But fbcon was *not* automatically load. >> Indeed, modprobing for fbcon allows me to load nvidiafb OR rivafb >> without any more screen garbling/blanking problems! > > :-) Yes, many have been burned by this assumption. If you do want > 2.4 behavior, you can compile fbcon statically, nvidiafb as a module. > Doing modprobe nvidiafb will automatically give you a framebuffer > console. Yes, after I got the idea that came as an obvious conclusion ... maybe this should be a FAQ? Documented in the help for fbmod? >> Notice how rivafb can't read the EDID from DDC/I2C -- and remark that >> I also have problems reading the EDID with get-edid. Also interesting > > read-edid though uses the Video BIOS to grab the EDID. So even your > card's BIOS is having problems doing i2c/ddc. Yep, and as I already said it's a known problem with my configuration (it's not clear whether the problem is the video card, with the montitor, or somewhere inbetween). >> is that rivafb won't let me get to 16 bit depth or higher. By > > Hmm, I'll check on that again. That'd be nice. > Oh well, I think rivafb and nvidiafb have different i2c timeouts. I believe > the timeouts in nvidiafb are more correct. Given that nvidiafb manages to read the edid and rivafb doesn't, I would say so too :) maybe get-edid needs fixes in that direction too? Anyway, it looks like I won't have problems using nvidiafb at 16 bits depth without EDID for the moment ... can I still use X.org's nv at 24 bits at the same time? Can they cooperate on the framebuffer? IIRC there was an option to let nv use the Linux-managed framebuffer ... Oh yes: """ Option "UseFBDev" "true" """ Will this create problems when the FBDev is at a different bitdepth? WIll this slow down either of the sides? -- Giuseppe "Oblomov" Bilotta "Da grande lotterò per la pace" "A me me la compra il mio babbo" (Altan) ("When I grow up, I will fight for peace" "I'll have my daddy buy it for me") ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-10-01 7:07 ` Giuseppe Bilotta @ 2005-10-01 10:49 ` Antonino A. Daplas 2005-10-02 15:13 ` Giuseppe Bilotta 0 siblings, 1 reply; 12+ messages in thread From: Antonino A. Daplas @ 2005-10-01 10:49 UTC (permalink / raw) To: Giuseppe Bilotta; +Cc: linux-kernel Giuseppe Bilotta wrote: > On Sat, 01 Oct 2005 13:49:59 +0800, Antonino A. Daplas wrote: > >> Looks like the nv driver just ignored the EDID and used one of >> its built-in VESA modes. If you notice, X's EDID ouput is the same >> as nvidiafb's. But the resulting timings are different. >> >> In contrast, nvidiafb will attempt to use the EDID, and only as a last >> resort, use one of the timings in the global mode database. > > I see. And when EDID is enabled for the module, it won't let me touch > those timings at all. Yes. But if the EDID block specified a usable hsync and vsync range, the timings can be customized. In your case it does not. > Maybe a "noddc" or "noedid" module option for > when EDID support is compiled in and one wants to work without it? It is a good idea. Especially since I've already encountered a lot of crappy EDID blocks. > >>> D'oh. D'oh. D'oh. >>> >>> I *really* need someone to repeatedly and savagely hit me on the head >>> with a gigantic, purple-and-yellow CLUEBAT. *sigh* >>> >>> Somehow, I just assumed that modprobing for the framebuffer driver >>> just loaded everything. But fbcon was *not* automatically load. >>> Indeed, modprobing for fbcon allows me to load nvidiafb OR rivafb >>> without any more screen garbling/blanking problems! >> :-) Yes, many have been burned by this assumption. If you do want >> 2.4 behavior, you can compile fbcon statically, nvidiafb as a module. >> Doing modprobe nvidiafb will automatically give you a framebuffer >> console. > > Yes, after I got the idea that came as an obvious conclusion ... maybe > this should be a FAQ? Documented in the help for fbmod? > I documented it in feature-list-2.6.txt, but it is still in the -mm tree. >>> Notice how rivafb can't read the EDID from DDC/I2C -- and remark that >>> I also have problems reading the EDID with get-edid. Also interesting >> read-edid though uses the Video BIOS to grab the EDID. So even your >> card's BIOS is having problems doing i2c/ddc. > > Yep, and as I already said it's a known problem with my configuration > (it's not clear whether the problem is the video card, with the > montitor, or somewhere inbetween). > >>> is that rivafb won't let me get to 16 bit depth or higher. By >> Hmm, I'll check on that again. > > That'd be nice. > >> Oh well, I think rivafb and nvidiafb have different i2c timeouts. I believe >> the timeouts in nvidiafb are more correct. > > Given that nvidiafb manages to read the edid and rivafb doesn't, I > would say so too :) maybe get-edid needs fixes in that direction too? get-edid is meant to be a generic reader, that's why it uses the BIOS. nvidiafb uses i2c/ddc and the method is different from manufacturer to manufacturer, chipset to chipset. > > Anyway, it looks like I won't have problems using nvidiafb at 16 bits > depth without EDID for the moment ... can I still use X.org's nv at 24 > bits at the same time? Can they cooperate on the framebuffer? IIRC Yes, you can have nvidiafb and nv with differing visuals. This should not be a problem. > there was an option to let nv use the Linux-managed framebuffer ... > > Oh yes: > """ > Option "UseFBDev" "true" > """ The "UseFBDev" option was meant to restore the framebuffer console when switching from X to vt. This option is unnecessary in 2.6 kernels. The console layer now detects an X<->console switch, so it can properly inform fbcon and the drivers that it needs to restore the state, or not touch the hardware when X owns the vt. > > Will this create problems when the FBDev is at a different bitdepth? It will only slow down the console switch. But it's preferrable to set it to false. > WIll this slow down either of the sides? > It should not. Tony ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 2005-10-01 10:49 ` Antonino A. Daplas @ 2005-10-02 15:13 ` Giuseppe Bilotta 0 siblings, 0 replies; 12+ messages in thread From: Giuseppe Bilotta @ 2005-10-02 15:13 UTC (permalink / raw) To: linux-kernel On Sat, 01 Oct 2005 18:49:08 +0800, Antonino A. Daplas wrote: > Giuseppe Bilotta wrote: >> On Sat, 01 Oct 2005 13:49:59 +0800, Antonino A. Daplas wrote: >> >>> Looks like the nv driver just ignored the EDID and used one of >>> its built-in VESA modes. If you notice, X's EDID ouput is the same >>> as nvidiafb's. But the resulting timings are different. >>> >>> In contrast, nvidiafb will attempt to use the EDID, and only as a last >>> resort, use one of the timings in the global mode database. >> >> I see. And when EDID is enabled for the module, it won't let me touch >> those timings at all. > > Yes. But if the EDID block specified a usable hsync and vsync range, the > timings can be customized. In your case it does not. /me is wondering if it would be possible to hack the EDID block and fix it ... and whether it's worth the risk. >> Maybe a "noddc" or "noedid" module option for >> when EDID support is compiled in and one wants to work without it? > > It is a good idea. Especially since I've already encountered a lot of > crappy EDID blocks. That'd be nice :) Thank you very much for all your help and information. I can now exploit my eye-destroying 133dpi in console too :) -- Giuseppe "Oblomov" Bilotta "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-10-02 15:14 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-09-28 14:12 Blanky rivafb vs snowy nvidiafb with 2.6.12 Giuseppe Bilotta 2005-09-28 21:01 ` Antonino A. Daplas 2005-09-29 11:41 ` Giuseppe Bilotta 2005-09-29 12:39 ` Antonino A. Daplas 2005-09-29 12:40 ` Antonino A. Daplas 2005-09-29 15:43 ` Giuseppe Bilotta 2005-09-29 20:47 ` Antonino A. Daplas 2005-09-30 8:53 ` Giuseppe Bilotta 2005-10-01 5:49 ` Antonino A. Daplas 2005-10-01 7:07 ` Giuseppe Bilotta 2005-10-01 10:49 ` Antonino A. Daplas 2005-10-02 15:13 ` Giuseppe Bilotta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).