From: Giuseppe Bilotta <hidden> Date: 2007-02-22 15:55:59
On 2/22/07, Antonino A. Daplas [off-list ref] wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
nvidiafb: Device ID: 10de0112
fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
fbmon: trying to fix monitor timings
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: From EDID
H: 30-75KHz V: 60-60Hz DCLK: 170MHz
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
Detailed Timings
160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync
Supported VESA Modes
Manufacturer's mask: 0
Standard Timings
1600x1200@60Hz
========================================
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
--
Giuseppe "Oblomov" Bilotta
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-22 16:18:48
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
On 2/22/07, Antonino A. Daplas [off-list ref] wrote:
quoted
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
Okay.
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
nvidiafb: Device ID: 10de0112
fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
fbmon: trying to fix monitor timings
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: From EDID
H: 30-75KHz V: 60-60Hz DCLK: 170MHz
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
Detailed Timings
160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync
Supported VESA Modes
Manufacturer's mask: 0
Standard Timings
1600x1200@60Hz
========================================
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work. You might want to change vfmin and vfmax to 59 and 61
respectively just to get leeway for mode calculation errors. This is in
drivers/video/fbmon.c, particularly b[5] and b[6] in this code:
case FBMON_FIX_TIMINGS:
printk("fbmon: trying to fix monitor timings\n");
b = edid + DETAILED_TIMING_DESCRIPTIONS_START;
for (i = 0; i < 4; i++) {
if (!(edid_is_serial_block(b) ||
edid_is_ascii_block(b) ||
edid_is_monitor_block(b) ||
edid_is_timing_block(b))) {
b[0] = 0x00;
b[1] = 0x00;
b[2] = 0x00;
b[3] = 0xfd;
b[4] = 0x00;
b[5] = 60; /* vfmin */
b[6] = 60; /* vfmax */
b[7] = 30; /* hfmin */
b[8] = 75; /* hfmax */
b[9] = 17; /* pixclock - 170 MHz*/
b[10] = 0; /* GTF */
break;
}
b += DETAILED_TIMING_DESCRIPTION_SIZE;
}
Also try doing fbset 640x480-60, 800x600-60, 1024x768-60 and
1280x1024-60, and if they displayed correctly, we can add these modes to
your EDID block.
Tony
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-22 17:00:48
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
On 2/22/07, Antonino A. Daplas [off-list ref] wrote:
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
BTW, you can also use CVT modes for nvidiafb, even if the mode in
question is not present in the EDID block. For example:
video=nvidiafb:1024x768M@60 or 1600x1200M@60
(The 'M' tells fb_find_mode to do a CVT calculation instead).
If you use a reduced-blanking CVT mode, it might even reduce the snow of
your DVI even at the highest resolution. So:
video=nvidiafb:1600x1200MR@60
(The additional 'R' will do reduced-blanking CVT calculation)
Tony
From: Giuseppe Bilotta <hidden> Date: 2007-02-22 19:08:46
On 2/22/07, Antonino A. Daplas [off-list ref] wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
quoted
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min and max as you suggested:
You might want to change vfmin and vfmax to 59 and 61
and even the M and MR methods which you suggested in the other email.
Since nvidiafb is being loaded from the command line because it's a
blacklisted module otherwise, I've been using the mode_option option.
However, neither the mode_option nor fbset seem to give me anything
not snowy.
Damn.
--
Giuseppe "Oblomov" Bilotta
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-22 23:31:36
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
On 2/22/07, Antonino A. Daplas [off-list ref] wrote:
quoted
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
quoted
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min and max as you suggested:
Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support? So this is still a valid
fix?
quoted
You might want to change vfmin and vfmax to 59 and 61
and even the M and MR methods which you suggested in the other email.
Since nvidiafb is being loaded from the command line because it's a
blacklisted module otherwise, I've been using the mode_option option.
However, neither the mode_option nor fbset seem to give me anything
not snowy.
When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?
I presume that X's nv driver or vesafb does not exhibit this problem?
Tony
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Giuseppe Bilotta <hidden> Date: 2007-02-23 13:34:18
On 2/23/07, Antonino A. Daplas [off-list ref] wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
quoted
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min and max as you suggested:
Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support? So this is still a valid
fix?
You're right, I hadn't realized that. I can now access all the sizes
from 640 to 1600, so I would say the fix is valid.
When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage.
I presume that X's nv driver or vesafb does not exhibit this problem?
X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.
--
Giuseppe "Oblomov" Bilotta
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-24 07:02:24
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
On 2/23/07, Antonino A. Daplas [off-list ref] wrote:
quoted
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
quoted
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min and max as you suggested:
Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support? So this is still a valid
fix?
You're right, I hadn't realized that. I can now access all the sizes
from 640 to 1600, so I would say the fix is valid.
Okay, thanks.
quoted
When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage.
quoted
I presume that X's nv driver or vesafb does not exhibit this problem?
X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.
Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.
Tony
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Giuseppe Bilotta <hidden> Date: 2007-02-24 09:16:10
On 2/24/07, Antonino A. Daplas [off-list ref] wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
quoted
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage.
quoted
I presume that X's nv driver or vesafb does not exhibit this problem?
X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.
Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is extremely reduced, to the point of
being barely perceptible during normal usage (not as clean as X, but
still very good).
Also, I'm wondering if it might be worth looking at the progress done
in nouveau, and the drm stuff they've implemented (or at least the new
memory management and maybe some of the 2D stuff).
--
Giuseppe "Oblomov" Bilotta
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-24 21:13:39
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
On 2/24/07, Antonino A. Daplas [off-list ref] wrote:
quoted
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
quoted
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage.
quoted
I presume that X's nv driver or vesafb does not exhibit this problem?
X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.
Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is extremely reduced,
I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption. It also incorporates Luca's i2c fix.
Tony
From: Giuseppe Bilotta <hidden> Date: 2007-02-25 10:26:59
On 2/24/07, Antonino A. Daplas [off-list ref] wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
quoted
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is extremely reduced,
I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption. It also incorporates Luca's i2c fix.
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.
--
Giuseppe "Oblomov" Bilotta
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-25 11:08:15
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
On 2/24/07, Antonino A. Daplas [off-list ref] wrote:
quoted
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
quoted
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is extremely reduced,
I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption. It also incorporates Luca's i2c fix.
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:
if (par->chan[conn - 1].par)
edid = fb_ddc_read(&par->chan[conn - 1].adapter);
and make sure CONFIG_FIRMWARE_EDID=y.
Tony
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Giuseppe Bilotta <hidden> Date: 2007-02-25 13:16:59
On 2/25/07, Antonino A. Daplas [off-list ref] wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
quoted
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:
if (par->chan[conn - 1].par)
edid = fb_ddc_read(&par->chan[conn - 1].adapter);
and make sure CONFIG_FIRMWARE_EDID=y.
With this patch, I don't get any dmesg info about my monitor EDID, but
I still get the snow. Could it be that there's something else on my
system which is setting the video to some absurd timings when I
switchg on the framebuffer console? I'm running an up-to-date debian
unstable.
--
Giuseppe "Oblomov" Bilotta
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-02-26 12:44:12
On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote:
On 2/25/07, Antonino A. Daplas [off-list ref] wrote:
quoted
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
quoted
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:
if (par->chan[conn - 1].par)
edid = fb_ddc_read(&par->chan[conn - 1].adapter);
and make sure CONFIG_FIRMWARE_EDID=y.
With this patch, I don't get any dmesg info about my monitor EDID, but
I still get the snow. Could it be that there's something else on my
system which is setting the video to some absurd timings when I
switchg on the framebuffer console? I'm running an up-to-date debian
unstable.
At this point, I don't know. You're the first person to report this
kind of problem. I'm still studying the nvidiafb and Xorg source code.
Tony