Blanky rivafb vs snowy nvidiafb with 2.6.12

Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Antonino A. Daplas]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Antonino A. Daplas]

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.
> 

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Antonino A. Daplas]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Antonino A. Daplas]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Antonino A. Daplas]

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

 

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta]

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")

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Antonino A. Daplas]

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

Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta]

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