On 2/22/07, Antonino A. Daplas <[email protected]> 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
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[email protected]> wrote:
> >
> > 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
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[email protected]> 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
On 2/22/07, Antonino A. Daplas <[email protected]> wrote:
> On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta 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 ...
>
> 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
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[email protected]> wrote:
> > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta 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 ...
> >
> > 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?
>
> > 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
On 2/23/07, Antonino A. Daplas <[email protected]> wrote:
> On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > 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
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> On 2/23/07, Antonino A. Daplas <[email protected]> wrote:
> > On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > > 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.
>
> > 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.
>
Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.
Tony
On 2/24/07, Antonino A. Daplas <[email protected]> wrote:
> On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> >
> > 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.
> >
>
> 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
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[email protected]> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > 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.
> > >
> >
> > 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
On 2/24/07, Antonino A. Daplas <[email protected]> wrote:
> On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> >
> > 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
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[email protected]> wrote:
> > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> > >
> > > 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
On 2/25/07, Antonino A. Daplas <[email protected]> wrote:
> On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> >
> > 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
On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote:
> On 2/25/07, Antonino A. Daplas <[email protected]> wrote:
> > On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> > >
> > > 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