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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |