Skip to contentSkip to conversation

nvidiafb: allow ignoring EDID info

PATCH In review Giuseppe Bilotta 7 participants 42 messages Jan 28, 2007 – Feb 26, 2007 2 messages not in the archive Framebuffer layer

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 nvidiafb: allow ignoring EDID info

From: Giuseppe Bilotta <[email protected]>

Some nVidia video cards have broken EDID information. Using nvidiafb with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console framebuffer to use wrong timing information, causing the display to be extremely 'snowy'. Since most distribution kernels are compiled with CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia framebuffer on said broken system without recompiling the kernel (or at least the nvidiafb module).

Solve the issue by introducing a new boolean module parameter (useedid) which can be set to 0 to prevent the driver from using the EDID information.

---

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C altogether.

drivers/video/nvidia/nv_i2c.c +11 -0
index 8454adf..6387f2b 100644
@@ -25,6 +25,8 @@
 
 #include "../edid.h"
 
+extern int useedid;
+
 static void nvidia_gpio_setscl(void *data, int state)
 {
        struct nvidia_i2c_chan *chan = data;
@@ -128,6 +130,9 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, const char *name)
 
 void nvidia_create_i2c_busses(struct nvidia_par *par)
 {
+       if (!useedid)
+               return;
+
        par->bus = 3;
 
        par->chan[0].par = par;
@@ -146,6 +151,9 @@ void nvidia_create_i2c_busses(struct nvidia_par *par)
 
 void nvidia_delete_i2c_busses(struct nvidia_par *par)
 {
+       if (!useedid)
+               return;
+
        if (par->chan[0].par)
                i2c_del_adapter(&par->chan[0].adapter);
        par->chan[0].par = NULL;
@@ -195,6 +203,9 @@ static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
 
 int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
 {
+       if (!useedid)
+               return -1;
+
        struct nvidia_par *par = info->par;
        u8 *edid = NULL;
        int i;
drivers/video/nvidia/nvidia.c +8 -0
index 538e947..179fd67 100644
@@ -83,6 +83,9 @@ static int bpp __devinitdata = 8;
 #ifdef CONFIG_MTRR
 static int nomtrr __devinitdata = 0;
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+int useedid __devinitdata = 1;
+#endif
 
 static char *mode_option __devinitdata = NULL;
 
@@ -1506,6 +1509,11 @@ module_param(nomtrr, bool, 0);
 MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) "
                 "(default=0)");
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+module_param(useedid, bool, 0);
+MODULE_PARM_DESC(useedid, "Use EDID to detect video modes (0 or 1) "
+                "(default=1, use EDID)");
+#endif
 
 MODULE_AUTHOR("Antonino Daplas");
 MODULE_DESCRIPTION("Framebuffer driver for nVidia graphics chipset");
Signature · 1 line
Giuseppe "Oblomov" Bilotta
#1 lore raw

Am Sonntag 28 Januar 2007 schrieb Giuseppe Bilotta:

Quoted 5 lines

From: Giuseppe Bilotta <[email protected]>

Solve the issue by introducing a new boolean module parameter (useedid) which can be set to 0 to prevent the driver from using the EDID information.

I don't know whether this is possible, but wouldn't be a cleaner approach be to put this parameter to something fb specific and not nvidia specific? As Nvidia fb proabably isn't the only one using edid and so it wouldn't be necessary to introduce such a parameter for every fb driver...

Signature · 3 lines
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V
#2 lore raw
In reply to Giuseppe Bilotta
Quoted 10 lines · On Sun, 28 Jan 2007 11:48:59 +0100 Giuseppe Bilotta…

From: Giuseppe Bilotta <[email protected]>

Some nVidia video cards have broken EDID information. Using nvidiafb with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console framebuffer to use wrong timing information, causing the display to be extremely 'snowy'. Since most distribution kernels are compiled with CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia framebuffer on said broken system without recompiling the kernel (or at least the nvidiafb module).

Quoted 7 lines

Solve the issue by introducing a new boolean module parameter (useedid) which can be set to 0 to prevent the driver from using the EDID information.

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C altogether.

That's a pretty sad solution. Is it possible to detect these bad cards at runtime via ther behaviour? If not, can we generate a blacklist for the known-bad cards based on PCI IDs or something?

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

Quoted 81 lines
drivers/video/nvidia/nv_i2c.c +11 -0
index 8454adf..6387f2b 100644
@@ -25,6 +25,8 @@
 
 #include "../edid.h"
 
+extern int useedid;
+
 static void nvidia_gpio_setscl(void *data, int state)
 {
        struct nvidia_i2c_chan *chan = data;
@@ -128,6 +130,9 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, const char *name)
 
 void nvidia_create_i2c_busses(struct nvidia_par *par)
 {
+       if (!useedid)
+               return;
+
        par->bus = 3;
 
        par->chan[0].par = par;
@@ -146,6 +151,9 @@ void nvidia_create_i2c_busses(struct nvidia_par *par)
 
 void nvidia_delete_i2c_busses(struct nvidia_par *par)
 {
+       if (!useedid)
+               return;
+
        if (par->chan[0].par)
                i2c_del_adapter(&par->chan[0].adapter);
        par->chan[0].par = NULL;
@@ -195,6 +203,9 @@ static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
 
 int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
 {
+       if (!useedid)
+               return -1;
+
        struct nvidia_par *par = info->par;
        u8 *edid = NULL;
        int i;
drivers/video/nvidia/nvidia.c +8 -0
index 538e947..179fd67 100644
@@ -83,6 +83,9 @@ static int bpp __devinitdata = 8;
 #ifdef CONFIG_MTRR
 static int nomtrr __devinitdata = 0;
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+int useedid __devinitdata = 1;
+#endif
 
 static char *mode_option __devinitdata = NULL;
 
@@ -1506,6 +1509,11 @@ module_param(nomtrr, bool, 0);
 MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) "
                 "(default=0)");
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+module_param(useedid, bool, 0);
+MODULE_PARM_DESC(useedid, "Use EDID to detect video modes (0 or 1) "
+                "(default=1, use EDID)");
+#endif
 
 MODULE_AUTHOR("Antonino Daplas");
 MODULE_DESCRIPTION("Framebuffer driver for nVidia graphics chipset");
Signature · 8 lines
-- 
Giuseppe "Oblomov" Bilotta

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

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

#3 lore raw
Quoted 16 lines
Quoted 8 lines

Some nVidia video cards have broken EDID information. Using nvidiafb with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console framebuffer to use wrong timing information, causing the display to be extremely 'snowy'. Since most distribution kernels are compiled with CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia framebuffer on said broken system without recompiling the kernel (or at least the nvidiafb module).

Quoted 7 lines

Solve the issue by introducing a new boolean module parameter (useedid) which can be set to 0 to prevent the driver from using the EDID information.

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C altogether.

Quoted 6 lines

That's a pretty sad solution. Is it possible to detect these bad cards at runtime via ther behaviour? If not, can we generate a blacklist for the known-bad cards based on PCI IDs or something?

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

Dave.

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

#4 lore raw
Quoted 20 lines · On Mon, 29 Jan 2007 11:12:57 +1100 "Dave Airlie" <[email protected]> wrote:
Quoted 20 lines
Quoted 8 lines

Some nVidia video cards have broken EDID information. Using nvidiafb with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console framebuffer to use wrong timing information, causing the display to be extremely 'snowy'. Since most distribution kernels are compiled with CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia framebuffer on said broken system without recompiling the kernel (or at least the nvidiafb module).

Quoted 7 lines

Solve the issue by introducing a new boolean module parameter (useedid) which can be set to 0 to prevent the driver from using the EDID information.

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C altogether.

That's a pretty sad solution. Is it possible to detect these bad cards at runtime via ther behaviour? If not, can we generate a blacklist for the known-bad cards based on PCI IDs or something?

Quoted 7 lines
Quoted 2 lines

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

oh. I'll take that as an ack :(

(where'd my cc go?)

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

#5 lore raw
In reply to Dave Airlie
Quoted 20 lines · On Mon, 29 Jan 2007 11:12:57 +1100 "Dave Airlie" <[email protected]> wrote:
Quoted 20 lines
Quoted 8 lines

Some nVidia video cards have broken EDID information. Using nvidiafb with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console framebuffer to use wrong timing information, causing the display to be extremely 'snowy'. Since most distribution kernels are compiled with CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia framebuffer on said broken system without recompiling the kernel (or at least the nvidiafb module).

Quoted 7 lines

Solve the issue by introducing a new boolean module parameter (useedid) which can be set to 0 to prevent the driver from using the EDID information.

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C altogether.

That's a pretty sad solution. Is it possible to detect these bad cards at runtime via ther behaviour? If not, can we generate a blacklist for the known-bad cards based on PCI IDs or something?

Quoted 6 lines
Quoted 2 lines

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so this patch should be some generic thing, available to all drivers, no?

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

#6 lore raw
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so this patch should be some generic thing, available to all drivers, no?

It should be in the fb layer not card specific.. as it may happen on any card...

Dave.

#7 lore raw
Quoted 11 lines · Dave Airlie
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so this patch should be some generic thing, available to all drivers, no?

It should be in the fb layer not card specific.. as it may happen on any card...

Although solving the problem at the fb layer level is probably the correct/best way to do it, I am not aware of people having problems with broken EDIDs and non-nVidia cards. By contrast, workarounds for nVidia and broken EDIDs is a very common thing to do even on Windows. Both the Windows and the Linux proprietary drivers need SoftEDID specifications to work around these problems. I don't know if this is just because of the way the driver are written, though, or if nVidia cards are particularly unable to handle monitors with broken EDIDs.

Plus, providing an fb-layer-level solution is way beyond my kernel programming experience :)

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#8 lore raw

Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto:

Quoted 11 lines · Dave Airlie
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so this patch should be some generic thing, available to all drivers, no?

Quoted 6 lines
Quoted 1 line

It should be in the fb layer not card specific.. as it may happen on any card...

Although solving the problem at the fb layer level is probably the correct/best way to do it, I am not aware of people having problems with broken EDIDs and non-nVidia cards. By contrast, workarounds for nVidia and broken EDIDs is a very common thing to do even on Windows.

Not all drivers have support for reading EDID information, so in many cases it just "works". My old monitor had garbage in the EDID eeprom and I had to pass "ignore_edid" to radeonfb (before I reprogrammed the eeprom that is :P).

Quoted 2 lines

Plus, providing an fb-layer-level solution is way beyond my kernel programming experience :)

I'll try to code something in the weekend.

Luca

Signature · 7 lines
Do, or do not. There is no try.

-------------------------------------------------------------------------
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
#9 lore raw

Il Tue, Jan 30, 2007 at 09:33:01PM +0100, Luca Tettamanti ha scritto:

Quoted 24 lines

Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto:

Quoted 11 lines · Dave Airlie
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

Because most users won't even be aware of the module option: they'll just know that their card doesn't work right.

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so this patch should be some generic thing, available to all drivers, no?

Quoted 6 lines
Quoted 1 line

It should be in the fb layer not card specific.. as it may happen on any card...

Although solving the problem at the fb layer level is probably the correct/best way to do it, I am not aware of people having problems with broken EDIDs and non-nVidia cards. By contrast, workarounds for nVidia and broken EDIDs is a very common thing to do even on Windows.

Not all drivers have support for reading EDID information, so in many cases it just "works". My old monitor had garbage in the EDID eeprom and I had to pass "ignore_edid" to radeonfb (before I reprogrammed the eeprom that is :P).

Quoted 4 lines
Quoted 2 lines

Plus, providing an fb-layer-level solution is way beyond my kernel programming experience :)

I'll try to code something in the weekend.

I'm somewhat stuck. fbmon has the library functions to parse and optionally fix EDID block, but it lacks the knowledge of the source of the data; IOW it's not possible to ignore the EDID coming from a certain head, the flag would be global (which may be less that optimal with multi-head setups).
So instead of adding an option I'd use the existing broken EDID db, adding another state (say 'unfixable') which causes the data to be discarded. Comments?

Giuseppe, can you send me the EDID block of your monitor?

Luca

Signature · 1 line
Sbagliare ? umano, ma per incasinare davvero le cose serve un computer.
#10 lore raw
Quoted 1 line · Luca Tettamanti

Giuseppe, can you send me the EDID block of your monitor?

I'd gladly do it, if I knew how to retrieve it ... because apparently, get-edid doesn't work, even though both the nv driver for X and nvidiafb manage to retrieve it.

This is the output from get-edid

"""
get-edid: get-edid version 1.4.1

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
	Function supported
	Call successful

	VBE version 300
	VBE string at 0x11110 "NVidia"

VBE/DDC service about to be called
Report DDC capabilities

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful

Monitor and video card combination does not support DDC1 transfers Monitor and video card combination does not support DDC2 transfers 0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called

	Read EDID

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
	Function supported
	Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
"""

Anything else I can try?

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#11 lore raw

Il Sun, Feb 04, 2007 at 10:17:08PM +0100, Giuseppe Bilotta ha scritto:

Quoted 6 lines · Luca Tettamanti
Quoted 1 line

Giuseppe, can you send me the EDID block of your monitor?

I'd gladly do it, if I knew how to retrieve it ... because apparently, get-edid doesn't work, even though both the nv driver for X and nvidiafb manage to retrieve it.

get-edid uses the BIOS, while the other two talk directly over the I2C bus.

Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID block, which resides at address 0x50:

i2cdump N 0x50 (where N is the bus number)

If you are unshure about bus number try with all the available /dev/i2c-* devices (you may want to unload HW monitor drivers first, so you don't poke at random stuff).

Luca
[1] lm-sensors package, at least on Debian.

Signature · 8 lines
La somma dell'intelligenza sulla terra è una costante.
La popolazione è in aumento.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
#12 lore raw
Quoted 11 lines · Luca Tettamanti

get-edid uses the BIOS, while the other two talk directly over the I2C bus.

Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID block, which resides at address 0x50:

i2cdump N 0x50 (where N is the bus number)

If you are unshure about bus number try with all the available /dev/i2c-* devices (you may want to unload HW monitor drivers first, so you don't poke at random stuff).

No luck. i2c-dev and dependencies are loaded
""" lsmod | grep i2c reports """

i2c_i801                7404  0
i2c_isa                 5152  0
i2c_piix4               8140  0
i2c_algo_pcf            6180  0
i2c_algo_pca            5380  0
i2c_algo_bit            8424  0
i2c_dev                 8548  0
i2c_core               19680  7

i2c_i801,i2c_isa,i2c_piix4,i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev """"

There is no such thing as /dev/i2c* UNLESS I load nvidiafb. When I load that, I get three busses (i2c-0, -1, and -2), but i2cdump N 0x50 gives me a nice tableau of X's all around, for all values of N. This is using kernel 2.6.18-3 stock Debian kernel. I'll keep trying with some variations, to see if I can get more sensible information.

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#13 lore raw
Quoted 24 lines · Luca Tettamanti
Quoted 11 lines

get-edid uses the BIOS, while the other two talk directly over the I2C bus.

Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID block, which resides at address 0x50:

i2cdump N 0x50 (where N is the bus number)

If you are unshure about bus number try with all the available /dev/i2c-* devices (you may want to unload HW monitor drivers first, so you don't poke at random stuff).

No luck. i2c-dev and dependencies are loaded
""" lsmod | grep i2c reports """

i2c_i801                7404  0
i2c_isa                 5152  0
i2c_piix4               8140  0
i2c_algo_pcf            6180  0
i2c_algo_pca            5380  0
i2c_algo_bit            8424  0
i2c_dev                 8548  0
i2c_core               19680  7
Quoted 8 lines

i2c_i801,i2c_isa,i2c_piix4,i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev """"

There is no such thing as /dev/i2c* UNLESS I load nvidiafb. When I load that, I get three busses (i2c-0, -1, and -2), but i2cdump N 0x50 gives me a nice tableau of X's all around, for all values of N. This is using kernel 2.6.18-3 stock Debian kernel. I'll keep trying with some variations, to see if I can get more sensible information.

There is no stand alone nvidia card i2c driver. Its the issue of sharing device interfaces with the same hardware problem again!!! There is a patch for DRI and fbdev but it really looks like we need a generic solution.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

#14 lore raw

Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:

Quoted 27 lines
Quoted 27 lines · Luca Tettamanti
Quoted 11 lines

get-edid uses the BIOS, while the other two talk directly over the I2C bus.

Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID block, which resides at address 0x50:

i2cdump N 0x50 (where N is the bus number)

If you are unshure about bus number try with all the available /dev/i2c-* devices (you may want to unload HW monitor drivers first, so you don't poke at random stuff).

No luck. i2c-dev and dependencies are loaded
""" lsmod | grep i2c reports """

i2c_i801                7404  0
i2c_isa                 5152  0
i2c_piix4               8140  0
i2c_algo_pcf            6180  0
i2c_algo_pca            5380  0
i2c_algo_bit            8424  0
i2c_dev                 8548  0
i2c_core               19680  7

i2c_i801,i2c_isa,i2c_piix4,i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev """"

Quoted 8 lines
Quoted 5 lines

There is no such thing as /dev/i2c* UNLESS I load nvidiafb. When I load that, I get three busses (i2c-0, -1, and -2), but i2cdump N 0x50 gives me a nice tableau of X's all around, for all values of N. This is using kernel 2.6.18-3 stock Debian kernel. I'll keep trying with some variations, to see if I can get more sensible information.

There is no stand alone nvidia card i2c driver. Its the issue of sharing device interfaces with the same hardware problem again!!!

Nah, nvidiafb registers the I2C busses, you can drive them with whatever you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming from the BIOS, we do VBE calls in real mode during early kernel setup.

Luca

Signature · 7 lines
Se non sei parte della soluzione, allora sei parte del problema.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
#15 lore raw
Quoted 8 lines · Luca Tettamanti

Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:

Quoted 2 lines

There is no stand alone nvidia card i2c driver. Its the issue of sharing device interfaces with the same hardware problem again!!!

Nah, nvidiafb registers the I2C busses, you can drive them with whatever you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming from the BIOS, we do VBE calls in real mode during early kernel setup.

So what am I supposed to do to dump it, since neither i2cdump neither get-edid seem to work?

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#16 lore raw

Sorry for the delay.

Il Thu, Feb 08, 2007 at 01:19:08AM +0100, Giuseppe Bilotta ha scritto:

Quoted 5 lines · Luca Tettamanti
Quoted 4 lines

Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:

Quoted 2 lines

There is no stand alone nvidia card i2c driver. Its the issue of sharing device interfaces with the same hardware problem again!!!

Quoted 7 lines
Quoted 4 lines

Nah, nvidiafb registers the I2C busses, you can drive them with whatever you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming from the BIOS, we do VBE calls in real mode during early kernel setup.

So what am I supposed to do to dump it, since neither i2cdump neither get-edid seem to work?

Good question :)

The following patch fixes a real bug in SCL control and add a few debug info. Can you try it?

drivers/video/nvidia/nv_i2c.c +17 -10
index 8454adf..ca8bd7e 100644
@@ -25,6 +25,12 @@
 
 #include "../edid.h"
 
+#define DDC_SDA_READ_MASK  (1 << 3)
+#define DDC_SCL_READ_MASK  (1 << 2)
+#define DDC_SDA_WRITE_MASK (1 << 4)
+#define DDC_SCL_WRITE_MASK (1 << 5)
+
+
 static void nvidia_gpio_setscl(void *data, int state)
 {
 	struct nvidia_i2c_chan *chan = data;
@@ -35,9 +41,9 @@ static void nvidia_gpio_setscl(void *data, int state)
 	val = VGA_RD08(par->PCIO, 0x3d5) & 0xf0;
 
 	if (state)
-		val |= 0x20;
+		val |= DDC_SDA_WRITE_MASK;
 	else
-		val &= ~0x20;
+		val &= ~DDC_SDA_WRITE_MASK;
 
 	VGA_WR08(par->PCIO, 0x3d4, chan->ddc_base + 1);
 	VGA_WR08(par->PCIO, 0x3d5, val | 0x1);
@@ -53,9 +59,9 @@ static void nvidia_gpio_setsda(void *data, int state)
 	val = VGA_RD08(par->PCIO, 0x3d5) & 0xf0;
 
 	if (state)
-		val |= 0x10;
+		val |= DDC_SDA_WRITE_MASK;
 	else
-		val &= ~0x10;
+		val &= ~DDC_SDA_WRITE_MASK;
 
 	VGA_WR08(par->PCIO, 0x3d4, chan->ddc_base + 1);
 	VGA_WR08(par->PCIO, 0x3d5, val | 0x1);
@@ -68,11 +74,9 @@ static int nvidia_gpio_getscl(void *data)
 	u32 val = 0;
 
 	VGA_WR08(par->PCIO, 0x3d4, chan->ddc_base);
-	if (VGA_RD08(par->PCIO, 0x3d5) & 0x04)
+	if (VGA_RD08(par->PCIO, 0x3d5) & DDC_SCL_READ_MASK)
 		val = 1;
 
-	val = VGA_RD08(par->PCIO, 0x3d5);
-
 	return val;
 }
 
@@ -83,7 +87,7 @@ static int nvidia_gpio_getsda(void *data)
 	u32 val = 0;
 
 	VGA_WR08(par->PCIO, 0x3d4, chan->ddc_base);
-	if (VGA_RD08(par->PCIO, 0x3d5) & 0x08)
+	if (VGA_RD08(par->PCIO, 0x3d5) & DDC_SDA_READ_MASK)
 		val = 1;
 
 	return val;
@@ -188,7 +192,7 @@ static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
 
 	if (i2c_transfer(&chan->adapter, msgs, 2) == 2)
 		return buf;
-	dev_dbg(&chan->par->pci_dev->dev, "Unable to read EDID block.\n");
+	dev_warn(&chan->par->pci_dev->dev, "Unable to read EDID block.\n");
 	kfree(buf);
 	return NULL;
 }
@@ -208,7 +212,10 @@ int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
 
 	if (!edid && conn == 1) {
 		/* try to get from firmware */
-		const u8 *e = fb_firmware_edid(info->device);
+		const u8 *e;
+		printk("I2C probe failed for connector %d, falling back to firmware\n", conn);
+		
+		e = fb_firmware_edid(info->device);
 
 		if (e != NULL)
 			edid = kmemdup(e, EDID_LENGTH, GFP_KERNEL);

Luca

Signature · 10 lines
"La teoria e` quando sappiamo come funzionano le cose ma non funzionano.
 La pratica e` quando le cose funzionano ma non sappiamo perche`.
 Abbiamo unito la teoria e la pratica: le cose non funzionano piu` e non
 sappiamo il perche`." -- A. Einstein

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
#17 lore raw

(some of you might get this mail in double copy , sorry)

Quoted 1 line · Luca Tettamanti

Sorry for the delay.

Ditto!

It also seemed that my kernel compiling sk1llz had gone AWL, I couldn't get the newly compiled kernel to run, until I realized the initrd.img was mislinked. Anyway.

Your patch has an immediately visible effect of reducing snow: it seems that now that you fixed the access bug the EDID is properly /not/ used. dmesg | grep nvidiafb now claims the following:

"""

nvidiafb: Device ID: 10de0112
nvidiafb 0000:01:00.0: Unable to read EDID block.
nvidiafb 0000:01:00.0: Unable to read EDID block.
nvidiafb 0000:01:00.0: Unable to read EDID block.

(it actually gave the "I2C probe failed ..." message on console, but it's not appearing in the dmesg, obviously, since it's a simple printk)

nvidiafb 0000:01:00.0: Unable to read EDID block. nvidiafb 0000:01:00.0: Unable to read EDID block. nvidiafb 0000:01:00.0: Unable to read EDID block.
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
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)

"""

So the EDID still seems to be totally inaccessible (which means I can't really tell why/when/where it's b0rked).

Finally, as I mentioned, console still has a little snow. It's barely perceptible in common console usage because the monitor is mostly black, but can get annoying with fullscreen apps à la mc.

This extra snow *might* be the effect of bandwidth limits Antonino Daplas was referring to in this lkml message:
http://lkml.org/lkml/2005/10/1/7 but I'll have to enquire on this further.

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#18 lore raw

Il Tue, Feb 13, 2007 at 10:25:41AM +0100, Giuseppe Bilotta ha scritto:

Quoted 35 lines · Luca Tettamanti
Quoted 1 line

Sorry for the delay.

Ditto!

It also seemed that my kernel compiling sk1llz had gone AWL, I couldn't get the newly compiled kernel to run, until I realized the initrd.img was mislinked. Anyway.

Your patch has an immediately visible effect of reducing snow: it seems that now that you fixed the access bug the EDID is properly /not/ used. dmesg | grep nvidiafb now claims the following:

"""

nvidiafb: Device ID: 10de0112
nvidiafb 0000:01:00.0: Unable to read EDID block.
nvidiafb 0000:01:00.0: Unable to read EDID block.
nvidiafb 0000:01:00.0: Unable to read EDID block.

(it actually gave the "I2C probe failed ..." message on console, but it's not appearing in the dmesg, obviously, since it's a simple printk)

nvidiafb 0000:01:00.0: Unable to read EDID block. nvidiafb 0000:01:00.0: Unable to read EDID block. nvidiafb 0000:01:00.0: Unable to read EDID block.
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
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)

Quoted 1 line

"""

Ok, now I'm confused O_o
The patch should be correct, but I fail to see how EDID reading succeded before.

Quoted 6 lines

So the EDID still seems to be totally inaccessible (which means I can't really tell why/when/where it's b0rked).

Finally, as I mentioned, console still has a little snow. It's barely perceptible in common console usage because the monitor is mostly black, but can get annoying with fullscreen apps à la mc.

Maybe the snow was caused by the driver hammering the I2C bus. Just guessing...

Can you send me X.org log?

Luca

Signature · 8 lines
Alcuni pensano che io sia una persona orribile, ma non e` vero. Ho il
cuore di un ragazzino - in un vaso sulla scrivania.

-------------------------------------------------------------------------
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
#19 lore raw
Quoted 4 lines · Luca Tettamanti

Ok, now I'm confused O_o
The patch should be correct, but I fail to see how EDID reading succeded before.

Sorry, but I have no idea on that :P

Quoted 2 lines

Maybe the snow was caused by the driver hammering the I2C bus. Just guessing...

It it was so, it wouldn't appear when I disabled EDID parsing because it wouldn't touch the I2C bus at all. But it appears just the same.

Quoted 1 line

Can you send me X.org log?

X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux oblomov 2.6.18-4-686 #1 SMP Fri Feb 2 15:10:49 UTC 2007 i686
Build Date: 03 February 2007
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 13 10:09:25 2007 (==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"

(**) |-->Screen "Inspiron built-in monitor" (0)
(**) |   |-->Monitor "Dell Inspiron 8200 built-in monitor"
(**) |   |-->Device "NVIDIA Corporation NV11 [GeForce2 Go]"
(**) |-->Input Device "Inspiron built-in keyboard"
(**) |-->Input Device "Inspiron built-in touchpad"
(**) |-->Input Device "ACECAD Tablet"
(**) FontPath set to:
	unix/:7100,
	/usr/lib/X11/fonts/TrueType,
	/usr/share/fonts/X11/Type1,
	/usr/lib/X11/fonts/Speedo,
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi

(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
X.Org Video Driver: 1.0
X.Org XInput driver : 0.6
X.Org Server Extension : 0.3
X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.5
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Video Driver, version 1.0

(--) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,1a30 card 0000,0000 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card 0000,0000 rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:2: chip 8086,2487 card 8086,4541 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card 0000,0000 rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1013,5959 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5421 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0112 card 1028,00d4 rev b2 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 10b7,9200 card 1028,00d4 rev 78 class 02,00,00 hdr 00 (II) PCI: 02:01:0: chip 104c,ac42 card e000,0000 rev 00 class 06,07,00 hdr 82 (II) PCI: 02:01:1: chip 104c,ac42 card e800,0000 rev 00 class 06,07,00 hdr 82 (II) PCI: 02:01:2: chip 104c,8027 card 1028,00d4 rev 00 class 0c,00,10 hdr 80 (II) PCI: End of PCI scan
(II) Intel Bridge workaround enabled
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,7), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range:

	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set)
(II) Bus 1 I/O range:
	[0] -1	0	0x0000c000 - 0x0000c0ff (0x100) IX[B]
	[1] -1	0	0x0000c400 - 0x0000c4ff (0x100) IX[B]
	[2] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[3] -1	0	0x0000cc00 - 0x0000ccff (0x100) IX[B]
(II) Bus 1 non-prefetchable memory range:
	[0] -1	0	0xfc000000 - 0xfdffffff (0x2000000) MX[B]
(II) Bus 1 prefetchable memory range:
	[0] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B]
(II) Subtractive PCI-to-PCI bridge:
(II) Bus 2: bridge is at (0:30:0), (0,2,16), BCTRL: 0x0006 (VGA_EN is cleared)
(II) Bus 2 I/O range:
	[0] -1	0	0x0000e000 - 0x0000e0ff (0x100) IX[B]
	[1] -1	0	0x0000e400 - 0x0000e4ff (0x100) IX[B]
	[2] -1	0	0x0000e800 - 0x0000e8ff (0x100) IX[B]
	[3] -1	0	0x0000ec00 - 0x0000ecff (0x100) IX[B]
	[4] -1	0	0x0000f000 - 0x0000f0ff (0x100) IX[B]
	[5] -1	0	0x0000f400 - 0x0000f4ff (0x100) IX[B]
	[6] -1	0	0x0000f800 - 0x0000f8ff (0x100) IX[B]
	[7] -1	0	0x0000fc00 - 0x0000fcff (0x100) IX[B]
(II) Bus 2 non-prefetchable memory range:
	[0] -1	0	0xf4000000 - 0xfbffffff (0x8000000) MX[B]
(II) Bus 2 prefetchable memory range:
	[0] -1	0	0x30000000 - 0x34ffffff (0x5000000) MX[B]

(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge:
(II) Bus 3: bridge is at (2:1:0), (2,3,6), BCTRL: 0x05c0 (VGA_EN is cleared) (II) Bus 3 I/O range:

	[0] -1	0	0x0000e000 - 0x0000e0ff (0x100) IX[B]
	[1] -1	0	0x0000e400 - 0x0000e4ff (0x100) IX[B]
(II) Bus 3 non-prefetchable memory range:
	[0] -1	0	0xf4000000 - 0xf5ffffff (0x2000000) MX[B]
(II) Bus 3 prefetchable memory range:
	[0] -1	0	0x30000000 - 0x31ffffff (0x2000000) MX[B]
(II) PCI-to-CardBus bridge:
(II) Bus 7: bridge is at (2:1:1), (2,7,10), BCTRL: 0x05c0 (VGA_EN is cleared)
(II) Bus 7 I/O range:
	[0] -1	0	0x0000e800 - 0x0000e8ff (0x100) IX[B]
(II) Bus 7 non-prefetchable memory range:
	[0] -1	0	0xf6000000 - 0xf7ffffff (0x2000000) MX[B]
(II) Bus 7 prefetchable memory range:
	[0] -1	0	0x32000000 - 0x33ffffff (0x2000000) MX[B]
(--) PCI:*(1:0:0) nVidia Corporation NV11 [GeForce2 Go] rev 178, Mem @
0xfc000000/24, 0xe0000000/27
(II) Addressable bus resource ranges are
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
	[1] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) PCI Memory resource overlap reduced 0xe8000000 from 0xebffffff to
0xe7ffffff
(II) Active PCI resource ranges:
	[0] -1	0	0xf8ff8000 - 0xf8ffbfff (0x4000) MX[B]
	[1] -1	0	0xf8fff000 - 0xf8fff7ff (0x800) MX[B]
	[2] -1	0	0xf8fffc00 - 0xf8fffc7f (0x80) MX[B]
	[3] -1	0	0x35000000 - 0x350003ff (0x400) MX[B]
	[4] -1	0	0xe8000000 - 0xe7ffffff (0x0) MX[B]O
	[5] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[6] -1	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B](B)
	[7] -1	0	0x0000ec80 - 0x0000ecff (0x80) IX[B]
	[8] -1	0	0x0000dc00 - 0x0000dc7f (0x80) IX[B]
	[9] -1	0	0x0000d400 - 0x0000d4ff (0x100) IX[B]
	[10] -1	0	0x0000dc80 - 0x0000dcbf (0x40) IX[B]
	[11] -1	0	0x0000d800 - 0x0000d8ff (0x100) IX[B]
	[12] -1	0	0x0000bfa0 - 0x0000bfaf (0x10) IX[B]
	[13] -1	0	0x00000374 - 0x00000374 (0x1) IX[B]
	[14] -1	0	0x00000170 - 0x00000170 (0x1) IX[B]
	[15] -1	0	0x000003f4 - 0x000003f4 (0x1) IX[B]
	[16] -1	0	0x000001f0 - 0x000001f0 (0x1) IX[B]
	[17] -1	0	0x0000bf20 - 0x0000bf3f (0x20) IX[B]
	[18] -1	0	0x0000bf80 - 0x0000bf9f (0x20) IX[B]
(II) Active PCI resource ranges after removing overlaps:
	[0] -1	0	0xf8ff8000 - 0xf8ffbfff (0x4000) MX[B]
	[1] -1	0	0xf8fff000 - 0xf8fff7ff (0x800) MX[B]
	[2] -1	0	0xf8fffc00 - 0xf8fffc7f (0x80) MX[B]
	[3] -1	0	0x35000000 - 0x350003ff (0x400) MX[B]
	[4] -1	0	0xe8000000 - 0xe7ffffff (0x0) MX[B]O
	[5] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[6] -1	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B](B)
	[7] -1	0	0x0000ec80 - 0x0000ecff (0x80) IX[B]
	[8] -1	0	0x0000dc00 - 0x0000dc7f (0x80) IX[B]
	[9] -1	0	0x0000d400 - 0x0000d4ff (0x100) IX[B]
	[10] -1	0	0x0000dc80 - 0x0000dcbf (0x40) IX[B]
	[11] -1	0	0x0000d800 - 0x0000d8ff (0x100) IX[B]
	[12] -1	0	0x0000bfa0 - 0x0000bfaf (0x10) IX[B]
	[13] -1	0	0x00000374 - 0x00000374 (0x1) IX[B]
	[14] -1	0	0x00000170 - 0x00000170 (0x1) IX[B]
	[15] -1	0	0x000003f4 - 0x000003f4 (0x1) IX[B]
	[16] -1	0	0x000001f0 - 0x000001f0 (0x1) IX[B]
	[17] -1	0	0x0000bf20 - 0x0000bf3f (0x20) IX[B]
	[18] -1	0	0x0000bf80 - 0x0000bf9f (0x20) IX[B]
(II) OS-reported resource ranges after removing overlaps with PCI:
	[0] -1	0	0x00100000 - 0x34ffffff (0x34f00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
	[0] -1	0	0x00100000 - 0x34ffffff (0x34f00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf8ff8000 - 0xf8ffbfff (0x4000) MX[B]
	[5] -1	0	0xf8fff000 - 0xf8fff7ff (0x800) MX[B]
	[6] -1	0	0xf8fffc00 - 0xf8fffc7f (0x80) MX[B]
	[7] -1	0	0x35000000 - 0x350003ff (0x400) MX[B]
	[8] -1	0	0xe8000000 - 0xe7ffffff (0x0) MX[B]O
	[9] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[10] -1	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B](B)
	[11] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[12] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[13] -1	0	0x0000ec80 - 0x0000ecff (0x80) IX[B]
	[14] -1	0	0x0000dc00 - 0x0000dc7f (0x80) IX[B]
	[15] -1	0	0x0000d400 - 0x0000d4ff (0x100) IX[B]
	[16] -1	0	0x0000dc80 - 0x0000dcbf (0x40) IX[B]
	[17] -1	0	0x0000d800 - 0x0000d8ff (0x100) IX[B]
	[18] -1	0	0x0000bfa0 - 0x0000bfaf (0x10) IX[B]
	[19] -1	0	0x00000374 - 0x00000374 (0x1) IX[B]
	[20] -1	0	0x00000170 - 0x00000170 (0x1) IX[B]
	[21] -1	0	0x000003f4 - 0x000003f4 (0x1) IX[B]
	[22] -1	0	0x000001f0 - 0x000001f0 (0x1) IX[B]
	[23] -1	0	0x0000bf20 - 0x0000bf3f (0x20) IX[B]
	[24] -1	0	0x0000bf80 - 0x0000bf9f (0x20) IX[B]

(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3

(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/lib/xorg/modules/linux/libdrm.so (II) Module drm: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3

(II) Loading extension XFree86-DRI
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.3
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "freetype"
(II) Loading /usr/lib/xorg/modules/fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
compiled for 7.1.1, module version = 2.1.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.5
(II) Loading font FreeType
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3

(==) AIGLX enabled
(II) Loading extension GLX
(II) LoadModule: "record"
(II) Loading /usr/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.13.0 Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.3
(II) Loading extension RECORD
(II) LoadModule: "speedo"
(WW) Warning, couldn't open module speedo
(II) UnloadModule: "speedo"
(EE) Failed to load module "speedo" (module does not exist, 0) (II) LoadModule: "type1"
(II) Loading /usr/lib/xorg/modules/fonts/libtype1.so (II) Module type1: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.2 Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.5
(II) Loading font Type1
(II) LoadModule: "vbe"
(II) Loading /usr/lib/xorg/modules/libvbe.so
(II) Module vbe: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.1.0
	ABI class: X.Org Video Driver, version 1.0

(II) LoadModule: "nv"
(II) Loading /usr/lib/xorg/modules/drivers/nv_drv.so (II) Module nv: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.2.0 Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 1.0
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input/kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.1.0 Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.6
(II) LoadModule: "synaptics"
(II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so (II) Module synaptics: vendor="The XFree86 Project"
compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 XInput Driver
ABI class: XFree86 XInput driver, version 0.3
(II) LoadModule: "evdev"
(II) Loading /usr/lib/xorg/modules/input/evdev_drv.so (II) Module evdev: vendor="X.Org Foundation"
compiled for 0.0.0, module version = 1.1.0 Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.6
(II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2,

	Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64,
	Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400,
	GeForce2 MX 100/200, GeForce2 Go, Quadro2 MXR/EX/Go,
	GeForce2 Integrated GPU, GeForce2 GTS, GeForce2 Ti, GeForce2 Ultra,
	Quadro2 Pro, GeForce4 MX 460, GeForce4 MX 440, GeForce4 MX 420,
	GeForce4 MX 440-SE, GeForce4 440 Go, GeForce4 420 Go,
	GeForce4 420 Go 32M, GeForce4 460 Go, Quadro4 550 XGL,
	GeForce4 440 Go 64M, Quadro NVS, Quadro4 500 GoGL,
	GeForce4 410 Go 16M, GeForce4 MX 440 with AGP8X,
	GeForce4 MX 440SE with AGP8X, GeForce4 MX 420 with AGP8X,
	GeForce4 MX 4000, GeForce4 448 Go, GeForce4 488 Go, Quadro4 580 XGL,
	Quadro4 NVS 280 SD, Quadro4 380 XGL, Quadro NVS 50 PCI,
	GeForce4 448 Go, GeForce4 MX Integrated GPU, GeForce3,
	GeForce3 Ti 200, GeForce3 Ti 500, Quadro DCC, GeForce4 Ti 4600,
	GeForce4 Ti 4400, GeForce4 Ti 4200, Quadro4 900 XGL, Quadro4 750 XGL,
	Quadro4 700 XGL, GeForce4 Ti 4800, GeForce4 Ti 4200 with AGP8X,
	GeForce4 Ti 4800 SE, GeForce4 4200 Go, Quadro4 700 GoGL,
	Quadro4 980 XGL, Quadro4 780 XGL, GeForce FX 5800 Ultra,
	GeForce FX 5800, Quadro FX 2000, Quadro FX 1000,
	GeForce FX 5600 Ultra, GeForce FX 5600, GeForce FX 5600XT,
	GeForce FX Go5600, GeForce FX Go5650, Quadro FX Go700,
	GeForce FX 5200, GeForce FX 5200 Ultra, GeForce FX 5200,
	GeForce FX 5200LE, GeForce FX Go5200, GeForce FX Go5250,
	GeForce FX 5500, GeForce FX 5100, GeForce FX Go5200 32M/64M,
	Quadro NVS 55/280 PCI, Quadro FX 500/600 PCI,
	GeForce FX Go53xx Series, GeForce FX Go5100, GeForce FX 5900 Ultra,
	GeForce FX 5900, GeForce FX 5900XT, GeForce FX 5950 Ultra,
	GeForce FX 5900ZT, Quadro FX 3000, Quadro FX 700,
	GeForce FX 5700 Ultra, GeForce FX 5700, GeForce FX 5700LE,
	GeForce FX 5700VE, GeForce FX Go5700, GeForce FX Go5700,
	Quadro FX Go1000, Quadro FX 1100, GeForce 6800 Ultra, GeForce 6800,
	GeForce 6800 LE, GeForce 6800 XE, GeForce 6800 XT, GeForce 6800 GT,
	GeForce 6800 GT, GeForce 6800 GS, GeForce 6800 XT, Quadro FX 4000,
	GeForce 6800 GS, GeForce 6800, GeForce 6800 LE, GeForce 6800 XT,
	GeForce Go 6800, GeForce Go 6800 Ultra, Quadro FX Go1400,
	Quadro FX 3450/4000 SDI, Quadro FX 1400, GeForce 6600 GT,
	GeForce 6600, GeForce 6600 LE, GeForce 6600 VE, GeForce Go 6600,
	GeForce 6610 XL, GeForce Go 6600 TE/6200 TE, GeForce 6700 XL,
	GeForce Go 6600, GeForce Go 6600 GT, Quadro FX 550, Quadro FX 550,
	Quadro FX 540, GeForce 6200, GeForce 6500,
	GeForce 6200 TurboCache(TM), GeForce 6200SE TurboCache(TM),
	GeForce 6200 LE, GeForce Go 6200, Quadro NVS 285, GeForce Go 6400,
	GeForce Go 6200, GeForce Go 6400, GeForce 6250, GeForce 6800,
	GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT, GeForce 6200,
	GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX,
	GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800,
	GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE,
	GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400,
	GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M,
	GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT,
	GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT,
	GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT,
	Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560,
	GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS,
	GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M,
	Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500,
	Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100,
	GeForce Go 6150, GeForce Go 6100

(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device (--) Chipset GeForce2 Go found
(II) resource ranges after xf86ClaimFixedResources() call:

	[0] -1	0	0x00100000 - 0x34ffffff (0x34f00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf8ff8000 - 0xf8ffbfff (0x4000) MX[B]
	[5] -1	0	0xf8fff000 - 0xf8fff7ff (0x800) MX[B]
	[6] -1	0	0xf8fffc00 - 0xf8fffc7f (0x80) MX[B]
	[7] -1	0	0x35000000 - 0x350003ff (0x400) MX[B]
	[8] -1	0	0xe8000000 - 0xe7ffffff (0x0) MX[B]O
	[9] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[10] -1	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B](B)
	[11] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[12] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[13] -1	0	0x0000ec80 - 0x0000ecff (0x80) IX[B]
	[14] -1	0	0x0000dc00 - 0x0000dc7f (0x80) IX[B]
	[15] -1	0	0x0000d400 - 0x0000d4ff (0x100) IX[B]
	[16] -1	0	0x0000dc80 - 0x0000dcbf (0x40) IX[B]
	[17] -1	0	0x0000d800 - 0x0000d8ff (0x100) IX[B]
	[18] -1	0	0x0000bfa0 - 0x0000bfaf (0x10) IX[B]
	[19] -1	0	0x00000374 - 0x00000374 (0x1) IX[B]
	[20] -1	0	0x00000170 - 0x00000170 (0x1) IX[B]
	[21] -1	0	0x000003f4 - 0x000003f4 (0x1) IX[B]
	[22] -1	0	0x000001f0 - 0x000001f0 (0x1) IX[B]
	[23] -1	0	0x0000bf20 - 0x0000bf3f (0x20) IX[B]
	[24] -1	0	0x0000bf80 - 0x0000bf9f (0x20) IX[B]
(II) resource ranges after probing:
	[0] -1	0	0x00100000 - 0x34ffffff (0x34f00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf8ff8000 - 0xf8ffbfff (0x4000) MX[B]
	[5] -1	0	0xf8fff000 - 0xf8fff7ff (0x800) MX[B]
	[6] -1	0	0xf8fffc00 - 0xf8fffc7f (0x80) MX[B]
	[7] -1	0	0x35000000 - 0x350003ff (0x400) MX[B]
	[8] -1	0	0xe8000000 - 0xe7ffffff (0x0) MX[B]O
	[9] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[10] -1	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B](B)
	[11] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[12] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[13] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[14] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[15] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[16] -1	0	0x0000ec80 - 0x0000ecff (0x80) IX[B]
	[17] -1	0	0x0000dc00 - 0x0000dc7f (0x80) IX[B]
	[18] -1	0	0x0000d400 - 0x0000d4ff (0x100) IX[B]
	[19] -1	0	0x0000dc80 - 0x0000dcbf (0x40) IX[B]
	[20] -1	0	0x0000d800 - 0x0000d8ff (0x100) IX[B]
	[21] -1	0	0x0000bfa0 - 0x0000bfaf (0x10) IX[B]
	[22] -1	0	0x00000374 - 0x00000374 (0x1) IX[B]
	[23] -1	0	0x00000170 - 0x00000170 (0x1) IX[B]
	[24] -1	0	0x000003f4 - 0x000003f4 (0x1) IX[B]
	[25] -1	0	0x000001f0 - 0x000001f0 (0x1) IX[B]
	[26] -1	0	0x0000bf20 - 0x0000bf3f (0x20) IX[B]
	[27] -1	0	0x0000bf80 - 0x0000bf9f (0x20) IX[B]
	[28] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[29] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]

(II) Setting vga for screen 0.
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/lib/xorg/modules/libint10.so
(II) Module int10: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Video Driver, version 1.0

(II) NV(0): Initializing int10
(II) NV(0): Primary V_BIOS segment is: 0xc000
(--) NV(0): Chipset: "GeForce2 Go"
(**) NV(0): Depth 24, (--) framebuffer bpp 32
(==) NV(0): RGB weight 888
(==) NV(0): Default visual is TrueColor
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/lib/xorg/modules/libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 0.1.0
	ABI class: X.Org Video Driver, version 1.0

(==) NV(0): Using HW cursor
(--) NV(0): Linear framebuffer at 0xE0000000
(--) NV(0): MMIO registers at 0xFC000000
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Loading /usr/lib/xorg/modules/libi2c.so
(II) Module i2c: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.2.0
	ABI class: X.Org Video Driver, version 1.0

(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /usr/lib/xorg/modules/libddc.so
(II) Module ddc: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Video Driver, version 1.0

(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
(II) NV(0): Panel is LVDS
(--) NV(0): VideoRAM: 32768 kBytes
(**) NV(0): Using gamma correction (0.7, 0.7, 0.7)
(WW) NV(0): config file hsync range 30-100kHz not within DDC hsync ranges. (II) NV(0): Dell Inspiron 8200 built-in monitor: Using hsync range of 30.00-100.00 kHz
(II) NV(0): Dell Inspiron 8200 built-in monitor: Using vrefresh value of 60.00 Hz
(II) NV(0): Clock range: 12.00 to 350.00 MHz
(II) NV(0): Not using default mode "640x350" (vrefresh out of range) (II) NV(0): Not using default mode "320x175" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x400" (vrefresh out of range) (II) NV(0): Not using default mode "320x200" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "720x400" (vrefresh out of range) (II) NV(0): Not using default mode "360x200" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x480" (vrefresh out of range) (II) NV(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x480" (vrefresh out of range) (II) NV(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x480" (vrefresh out of range) (II) NV(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1024x768" (vrefresh out of range) (II) NV(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1024x768" (vrefresh out of range) (II) NV(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1024x768" (vrefresh out of range) (II) NV(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1152x864" (vrefresh out of range) (II) NV(0): Not using default mode "576x432" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1280x960" (vrefresh out of range) (II) NV(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x512" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1280x1024" (vrefresh out of range) (II) NV(0): Not using default mode "640x512" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1280x1024" (vrefresh out of range) (II) NV(0): Not using default mode "640x512" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1600x1200" (vrefresh out of range) (II) NV(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1600x1200" (vrefresh out of range) (II) NV(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1600x1200" (vrefresh out of range) (II) NV(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1600x1200" (hsync out of range) (II) NV(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1792x1344" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1792x1344" (unknown reason) (II) NV(0): Not using default mode "896x672" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1792x1344" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1792x1344" (unknown reason) (II) NV(0): Not using default mode "896x672" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1856x1392" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1856x1392" (unknown reason) (II) NV(0): Not using default mode "928x696" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1856x1392" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1856x1392" (unknown reason) (II) NV(0): Not using default mode "928x696" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1920x1440" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1920x1440" (unknown reason) (II) NV(0): Not using default mode "960x720" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1920x1440" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1920x1440" (unknown reason) (II) NV(0): Not using default mode "960x720" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "832x624" (vrefresh out of range) (II) NV(0): Not using default mode "416x312" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1152x768" (vrefresh out of range) (II) NV(0): Not using default mode "576x384" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1152x864" (vrefresh out of range) (II) NV(0): Not using default mode "576x432" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1400x1050" (vrefresh out of range) (II) NV(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1400x1050" (vrefresh out of range) (II) NV(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1400x1050" (vrefresh out of range) (II) NV(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "720x450" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "800x512" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1680x1050" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1680x1050" (unknown reason) (II) NV(0): Not using default mode "840x525" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1920x1200" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1920x1200" (unknown reason) (II) NV(0): Not using default mode "960x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1920x1200" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1920x1200" (unknown reason) (II) NV(0): Not using default mode "960x600" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "1920x1440" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "1920x1440" (unknown reason) (II) NV(0): Not using default mode "960x720" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "2048x1536" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "2048x1536" (unknown reason) (II) NV(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan)
(II) NV(0): Mode "2048x1536" is larger than BIOS programmed panel size of 1600 x 1200. Removing.
(II) NV(0): Not using default mode "2048x1536" (unknown reason) (II) NV(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan)
(II) NV(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan)
(--) NV(0): Virtual size is 1600x1200 (pitch 1600)
(**) 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
(**) NV(0): *Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) NV(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771
777 806 -hsync -vsync
(**) NV(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz
(II) NV(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605
628 +hsync +vsync
(**) NV(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz
(II) NV(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492
525 -hsync -vsync
(**) NV(0): Default mode "1400x1050": 122.0 MHz, 64.9 kHz, 60.0 Hz (II) NV(0): Modeline "1400x1050" 122.00 1400 1488 1640 1880 1050 1052 1064 1082 +hsync +vsync
(**) NV(0): Default mode "1280x1024": 108.0 MHz, 64.0 kHz, 60.0 Hz (II) NV(0): Modeline "1280x1024" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync
(**) NV(0): Default mode "1440x900": 108.8 MHz, 56.9 kHz, 60.2 Hz (II) NV(0): Modeline "1440x900" 108.84 1440 1472 1880 1912 900 918 927 946 +hsync +vsync
(**) NV(0): Default mode "1280x960": 108.0 MHz, 60.0 kHz, 60.0 Hz (II) NV(0): Modeline "1280x960" 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync
(**) NV(0): Default mode "1280x800": 83.5 MHz, 49.7 kHz, 60.0 Hz
(II) NV(0): Modeline "1280x800" 83.46 1280 1344 1480 1680 800 801 804 828
(**) NV(0): Default mode "1280x768": 80.1 MHz, 47.7 kHz, 60.0 Hz
(II) NV(0): Modeline "1280x768" 80.14 1280 1344 1480 1680 768 769 772 795
(++) NV(0): DPI set to (100, 100)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.3

(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/lib/xorg/modules/libxaa.so
(II) Module xaa: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.2.0
	ABI class: X.Org Video Driver, version 1.0

(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Loading /usr/lib/xorg/modules/libramdac.so
(II) Module ramdac: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 0.1.0
	ABI class: X.Org Video Driver, version 1.0
(--) Depth 24 pixmap format is 32 bpp
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
	[0] 0	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B]
	[1] 0	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B]
	[2] -1	0	0x00100000 - 0x34ffffff (0x34f00000) MX[B]E(B)
	[3] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[4] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[5] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[6] -1	0	0xf8ff8000 - 0xf8ffbfff (0x4000) MX[B]
	[7] -1	0	0xf8fff000 - 0xf8fff7ff (0x800) MX[B]
	[8] -1	0	0xf8fffc00 - 0xf8fffc7f (0x80) MX[B]
	[9] -1	0	0x35000000 - 0x350003ff (0x400) MX[B]
	[10] -1	0	0xe8000000 - 0xe7ffffff (0x0) MX[B]O
	[11] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[12] -1	0	0xfc000000 - 0xfcffffff (0x1000000) MX[B](B)
	[13] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
	[14] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
	[15] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
	[16] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[17] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[18] -1	0	0x0000ec80 - 0x0000ecff (0x80) IX[B]
	[19] -1	0	0x0000dc00 - 0x0000dc7f (0x80) IX[B]
	[20] -1	0	0x0000d400 - 0x0000d4ff (0x100) IX[B]
	[21] -1	0	0x0000dc80 - 0x0000dcbf (0x40) IX[B]
	[22] -1	0	0x0000d800 - 0x0000d8ff (0x100) IX[B]
	[23] -1	0	0x0000bfa0 - 0x0000bfaf (0x10) IX[B]
	[24] -1	0	0x00000374 - 0x00000374 (0x1) IX[B]
	[25] -1	0	0x00000170 - 0x00000170 (0x1) IX[B]
	[26] -1	0	0x000003f4 - 0x000003f4 (0x1) IX[B]
	[27] -1	0	0x000001f0 - 0x000001f0 (0x1) IX[B]
	[28] -1	0	0x0000bf20 - 0x0000bf3f (0x20) IX[B]
	[29] -1	0	0x0000bf80 - 0x0000bf9f (0x20) IX[B]
	[30] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
	[31] 0	0	0x000003c0 - 0x000003df (0x20) IS[B](OprU)

(==) NV(0): Write-combining range (0xe0000000,0x2000000) (II) NV(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines
Scanline Image Writes
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
29 256x256 slots
14 512x512 slots
(==) NV(0): Backing store disabled
(==) NV(0): Silken mouse enabled
(**) Option "dpms"
(**) NV(0): DPMS enabled
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(EE) AIGLX: Screen 0 is not DRI capable
(II) Loading local sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so (II) Module GLcore: vendor="X.Org Foundation"

	compiled for 7.1.1, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3

(II) GLX: Initialized MESA-PROXY GL provider for screen 0
(**) Option "CoreKeyboard"
(**) Inspiron built-in keyboard: Core Keyboard
(**) Option "Protocol" "standard"
(**) Inspiron built-in keyboard: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Inspiron built-in keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "inspiron"
(**) Inspiron built-in keyboard: XkbModel: "inspiron"
(**) Option "XkbLayout" "us(intl)"
(**) Inspiron built-in keyboard: XkbLayout: "us(intl)"
(**) Option "CustomKeycodes" "off"
(**) Inspiron built-in keyboard: CustomKeycodes disabled
(II) Synaptics touchpad driver version 0.14.6 (1406)
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(**) Option "SHMConfig" "true"
(**) Option "LeftEdge" "100"
(**) Option "RightEdge" "920"
(**) Option "TopEdge" "70"
(**) Option "BottomEdge" "650"
(**) Option "VertScrollDelta" "10"
(**) Option "HorizScrollDelta" "10"
(**) Option "CircularScrolling" "1"
(**) Option "CircScrollTrigger" "4"
(--) Inspiron built-in touchpad touchpad found
(**) Option "CorePointer"
(**) Inspiron built-in touchpad: Core Pointer
(II) evdev brain: Rescanning devices (1).
(EE) PreInit returned NULL for "ACECAD Tablet"
(II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (II) XINPUT: Adding extended input device "Inspiron built-in touchpad" (type: MOUSE)
(II) XINPUT: Adding extended input device "Inspiron built-in keyboard" (type: KEYBOARD)

   xkb_keycodes             { include "xfree86+aliases(qwerty)" };
   xkb_types                { include "complete" };
   xkb_compatibility        { include "complete" };
   xkb_symbols              { include "pc(pc105)+us(intl)+inet(inspiron)" };
   xkb_geometry             { include "pc(pc104)" };

Synaptics DeviceInit called
SynapticsCtrl called.
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
(II) evdev brain: Rescanning devices (2).
SynapticsCtrl called.
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (3).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (4).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (5).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (6).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (7).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (8).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (9).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (10).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (11).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (12).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found
Synaptics DeviceOff called
(II) Open ACPI successful (/var/run/acpid.socket)
(II) evdev brain: Rescanning devices (13).
Synaptics DeviceOn called
(--) Inspiron built-in touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3"
(--) Inspiron built-in touchpad touchpad found

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#20 lore raw
In reply to Luca Tettamanti
Quoted 8 lines
Quoted 3 lines

There is no stand alone nvidia card i2c driver. Its the issue of sharing device interfaces with the same hardware problem again!!!

Nah, nvidiafb registers the I2C busses, you can drive them with whatever you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming from the BIOS, we do VBE calls in real mode during early kernel setup.

What I meant is we can't load the i2c code seperate from the fbdev driver.

#21 lore raw
In reply to Giuseppe Bilotta

Il Mon, Feb 05, 2007 at 10:28:36PM +0100, Giuseppe Bilotta ha scritto:

Quoted 12 lines · Luca Tettamanti
Quoted 11 lines

get-edid uses the BIOS, while the other two talk directly over the I2C bus.

Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID block, which resides at address 0x50:

i2cdump N 0x50 (where N is the bus number)

If you are unshure about bus number try with all the available /dev/i2c-* devices (you may want to unload HW monitor drivers first, so you don't poke at random stuff).

[...]

Quoted 1 line

There is no such thing as /dev/i2c* UNLESS I load nvidiafb.

Of course :)

Quoted 3 lines

When I
load that, I get three busses (i2c-0, -1, and -2), but i2cdump N 0x50 gives me a nice tableau of X's all around, for all values of N.

There may be a bug in the serial clock line control, at least the code looks strange. I'll check and come back with a patch ASAP.

Luca

Signature · 8 lines
"Sei l'unica donna della mia vita".
(Adamo)

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
#22 lore raw
In reply to Luca Tettamanti
Quoted 25 lines
Quoted 11 lines
Quoted 5 lines

Although solving the problem at the fb layer level is probably the correct/best way to do it, I am not aware of people having problems with broken EDIDs and non-nVidia cards. By contrast, workarounds for nVidia and broken EDIDs is a very common thing to do even on Windows.

Not all drivers have support for reading EDID information, so in many cases it just "works". My old monitor had garbage in the EDID eeprom and I had to pass "ignore_edid" to radeonfb (before I reprogrammed the eeprom that is :P).

Quoted 4 lines
Quoted 2 lines

Plus, providing an fb-layer-level solution is way beyond my kernel programming experience :)

I'll try to code something in the weekend.

I'm somewhat stuck. fbmon has the library functions to parse and optionally fix EDID block, but it lacks the knowledge of the source of the data; IOW it's not possible to ignore the EDID coming from a certain head, the flag would be global (which may be less that optimal with multi-head setups).
So instead of adding an option I'd use the existing broken EDID db, adding another state (say 'unfixable') which causes the data to be discarded. Comments?

Quoted 1 line

Giuseppe, can you send me the EDID block of your monitor?

If you can find post the manufacturer and model number we can place it on the backlist in fbmon. Also we should figure out what is wrong and fix it.

#23 lore raw
Quoted 3 lines · James Simmons

If you can find post the manufacturer and model number we can place it on the backlist in fbmon. Also we should figure out what is wrong and fix it.

It's the UltraSharp UXGA display that used to come with Dell Inspiron 8200, 15" with a resolution of 1600x1200. I've been looking all around for more info on it, but the only things I could find were posts that remarked the problems Windows nVidia drivers have with some of these (no image when running at 1600x1200), and other posts about banded gradients with Windows drivers on Radeon video cards (but I get banded gradients also win my nVidia card, on Linux, regardless of which driver I use, binary, nv or nouveau).

As mentioned in another post in this thread, I can't get any info out of the i2c busses, because even when I have them available (i.e. after loading nvidiafb) I get XXXX all around (on all three of them). Suggestions on how to get the information welcome.

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#24 lore raw
Quoted 14 lines · Giuseppe Bilotta
Quoted 3 lines · James Simmons

If you can find post the manufacturer and model number we can place it on the backlist in fbmon. Also we should figure out what is wrong and fix it.

It's the UltraSharp UXGA display that used to come with Dell Inspiron 8200, 15" with a resolution of 1600x1200. I've been looking all around for more info on it, but the only things I could find were posts that remarked the problems Windows nVidia drivers have with some of these (no image when running at 1600x1200), and other posts about banded gradients with Windows drivers on Radeon video cards (but I get banded gradients also win my nVidia card, on Linux, regardless of which driver I use, binary, nv or nouveau).

Quoted 4 lines

As mentioned in another post in this thread, I can't get any info out of the i2c busses, because even when I have them available (i.e. after loading nvidiafb) I get XXXX all around (on all three of them). Suggestions on how to get the information welcome.

Is this the same monitor you posted here?

http://marc.theaimsgroup.com/?l=linux-kernel&m=112807065616218&w=2

If yes, we already have the manufacturer and model code. The main problem is that the EDID of this display has no sync range (H: 75-75kHz and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID block shouldn't be too hard.

I already have a patch for this which I forgot to send to you before :-). If you can confirm that this is still the same hardware, I'll send you a test patch

Tony

#25 lore raw
Quoted 7 lines · Antonino A. Daplas
Quoted 5 lines · Giuseppe Bilotta

As mentioned in another post in this thread, I can't get any info out of the i2c busses, because even when I have them available (i.e. after loading nvidiafb) I get XXXX all around (on all three of them). Suggestions on how to get the information welcome.

Quoted 8 lines

Is this the same monitor you posted here?

http://marc.theaimsgroup.com/?l=linux-kernel&m=112807065616218&w=2

If yes, we already have the manufacturer and model code. The main problem is that the EDID of this display has no sync range (H: 75-75kHz and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID block shouldn't be too hard.

Yes, that's it! Jeepers, I can't believe that even re-reading the past LKML posts (even those!) I couldn't find the EDID info and how we had gotten them. I guess I need stronger glasses.

Wonder why Luca's proposed patch makes the EDID undetectable, now, and why can't it be retrieved at a later time via i2c. Timeouts too small?

Quoted 3 lines

I already have a patch for this which I forgot to send to you before :-). If you can confirm that this is still the same hardware, I'll send you a test patch

Yes, it's the same hardware. I can try the patch, with or without Luca's.

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#26 lore raw
Quoted 21 lines · Giuseppe Bilotta
Quoted 7 lines · Antonino A. Daplas
Quoted 5 lines · Giuseppe Bilotta

As mentioned in another post in this thread, I can't get any info out of the i2c busses, because even when I have them available (i.e. after loading nvidiafb) I get XXXX all around (on all three of them). Suggestions on how to get the information welcome.

Quoted 8 lines

Is this the same monitor you posted here?

http://marc.theaimsgroup.com/?l=linux-kernel&m=112807065616218&w=2

If yes, we already have the manufacturer and model code. The main problem is that the EDID of this display has no sync range (H: 75-75kHz and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID block shouldn't be too hard.

Yes, that's it! Jeepers, I can't believe that even re-reading the past LKML posts (even those!) I couldn't find the EDID info and how we had gotten them. I guess I need stronger glasses.

Quoted 10 lines

Wonder why Luca's proposed patch makes the EDID undetectable, now, and why can't it be retrieved at a later time via i2c. Timeouts too small?

Quoted 3 lines

I already have a patch for this which I forgot to send to you before :-). If you can confirm that this is still the same hardware, I'll send you a test patch

Yes, it's the same hardware. I can try the patch, with or without Luca's.

Okay. Patch attached. You may want to #define DEBUG in drivers/video/fbmon.c so we can appreciate what happens. Load nvidiafb with DEBUG defined before and after applying the patch, then send your 'dmesg'.

Tony

fbdev: Add Ultrasharp UXGA to broken monitor database

From: <>

This particular monitor does not have a limits block and has only one set of monitor timings. Fix by adding a limits block to the EDID and extend the horizontal sync frequency range to 30 kHz and 75 Khz.

---

 drivers/video/fbmon.c |  168 +++++++++++++++++++++++++++++++++----------------
 1 files changed, 112 insertions(+), 56 deletions(-)
drivers/video/fbmon.c +112 -56
index 6b385c3..05a9464 100644
@@ -48,8 +48,9 @@ #else
 #define DPRINTK(fmt, args...)
 #endif
 
-#define FBMON_FIX_HEADER 1
-#define FBMON_FIX_INPUT  2
+#define FBMON_FIX_HEADER  1
+#define FBMON_FIX_INPUT   2
+#define FBMON_FIX_TIMINGS 3
 
 #ifdef CONFIG_FB_MODE_HELPERS
 struct broken_edid {
@@ -71,6 +72,12 @@ static const struct broken_edid brokendb
 		.model        = 0x5a44,
 		.fix          = FBMON_FIX_INPUT,
 	},
+	/* Sharp UXGA? */
+	{
+		.manufacturer = "SHP",
+		.model        = 0x138e,
+		.fix          = FBMON_FIX_TIMINGS,
+	},
 };
 
 static const unsigned char edid_v1_header[] = { 0x00, 0xff, 0xff, 0xff,
@@ -87,6 +94,55 @@ static void copy_string(unsigned char *c
   while (i-- && (*--s == 0x20)) *s = 0;
 }
 
+static int edid_is_serial_block(unsigned char *block)
+{
+	if ((block[0] == 0x00) && (block[1] == 0x00) &&
+	    (block[2] == 0x00) && (block[3] == 0xff) &&
+	    (block[4] == 0x00))
+		return 1;
+	else
+		return 0;
+}
+
+static int edid_is_ascii_block(unsigned char *block)
+{
+	if ((block[0] == 0x00) && (block[1] == 0x00) &&
+	    (block[2] == 0x00) && (block[3] == 0xfe) &&
+	    (block[4] == 0x00))
+		return 1;
+	else
+		return 0;
+}
+
+static int edid_is_limits_block(unsigned char *block)
+{
+	if ((block[0] == 0x00) && (block[1] == 0x00) &&
+	    (block[2] == 0x00) && (block[3] == 0xfd) &&
+	    (block[4] == 0x00))
+		return 1;
+	else
+		return 0;
+}
+
+static int edid_is_monitor_block(unsigned char *block)
+{
+	if ((block[0] == 0x00) && (block[1] == 0x00) &&
+	    (block[2] == 0x00) && (block[3] == 0xfc) &&
+	    (block[4] == 0x00))
+		return 1;
+	else
+		return 0;
+}
+
+static int edid_is_timing_block(unsigned char *block)
+{
+	if ((block[0] != 0x00) || (block[1] != 0x00) ||
+	    (block[2] != 0x00) || (block[4] != 0x00))
+		return 1;
+	else
+		return 0;
+}
+
 static int check_edid(unsigned char *edid)
 {
 	unsigned char *block = edid + ID_MANUFACTURER_NAME, manufacturer[4];
@@ -104,9 +160,6 @@ static int check_edid(unsigned char *edi
 	for (i = 0; i < ARRAY_SIZE(brokendb); i++) {
 		if (!strncmp(manufacturer, brokendb[i].manufacturer, 4) &&
 			brokendb[i].model == model) {
-			printk("fbmon: The EDID Block of "
-			       "Manufacturer: %s Model: 0x%x is known to "
-			       "be broken,\n",  manufacturer, model);
  			fix = brokendb[i].fix;
  			break;
 		}
@@ -115,8 +168,10 @@ static int check_edid(unsigned char *edi
 	switch (fix) {
 	case FBMON_FIX_HEADER:
 		for (i = 0; i < 8; i++) {
-			if (edid[i] != edid_v1_header[i])
+			if (edid[i] != edid_v1_header[i]) {
 				ret = fix;
+				break;
+			}
 		}
 		break;
 	case FBMON_FIX_INPUT:
@@ -126,14 +181,33 @@ static int check_edid(unsigned char *edi
 		if (b[4] & 0x01 && b[0] & 0x80)
 			ret = fix;
 		break;
+	case FBMON_FIX_TIMINGS:
+		b = edid + DETAILED_TIMING_DESCRIPTIONS_START;
+
+		for (i = 0; i < 4; i++) {
+			if (edid_is_limits_block(b)) {
+				ret = fix;
+				break;
+			}
+
+			b += DETAILED_TIMING_DESCRIPTION_SIZE;
+		}
+
+		break;
 	}
 
+	if (ret)
+		printk("fbmon: The EDID Block of "
+		       "Manufacturer: %s Model: 0x%x is known to "
+		       "be broken,\n",  manufacturer, model);
+
 	return ret;
 }
 
 static void fix_edid(unsigned char *edid, int fix)
 {
-	unsigned char *b;
+	int i;
+	unsigned char *b, csum = 0;
 
 	switch (fix) {
 	case FBMON_FIX_HEADER:
@@ -145,6 +219,37 @@ static void fix_edid(unsigned char *edid
 		b = edid + EDID_STRUCT_DISPLAY;
 		b[0] &= ~0x80;
 		edid[127] += 0x80;
+		break;
+	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;
+		}
+
+		for (i = 0; i < EDID_LENGTH - 1; i++)
+			csum += edid[i];
+
+		edid[127] = 256 - csum;
+		break;
 	}
 }
 
@@ -273,46 +378,6 @@ static void get_chroma(unsigned char *bl
 	DPRINTK("WhiteY:   0.%03d\n", specs->chroma.whitey);
 }
 
-static int edid_is_serial_block(unsigned char *block)
-{
-	if ((block[0] == 0x00) && (block[1] == 0x00) && 
-	    (block[2] == 0x00) && (block[3] == 0xff) &&
-	    (block[4] == 0x00))
-		return 1;
-	else
-		return 0;
-}
-
-static int edid_is_ascii_block(unsigned char *block)
-{
-	if ((block[0] == 0x00) && (block[1] == 0x00) && 
-	    (block[2] == 0x00) && (block[3] == 0xfe) &&
-	    (block[4] == 0x00))
-		return 1;
-	else
-		return 0;
-}
-
-static int edid_is_limits_block(unsigned char *block)
-{
-	if ((block[0] == 0x00) && (block[1] == 0x00) && 
-	    (block[2] == 0x00) && (block[3] == 0xfd) &&
-	    (block[4] == 0x00))
-		return 1;
-	else
-		return 0;
-}
-
-static int edid_is_monitor_block(unsigned char *block)
-{
-	if ((block[0] == 0x00) && (block[1] == 0x00) && 
-	    (block[2] == 0x00) && (block[3] == 0xfc) &&
-	    (block[4] == 0x00))
-		return 1;
-	else
-		return 0;
-}
-
 static void calc_mode_timings(int xres, int yres, int refresh,
 			      struct fb_videomode *mode)
 {
@@ -795,15 +860,6 @@ static void get_monspecs(unsigned char *
 	}
 }
 
-static int edid_is_timing_block(unsigned char *block)
-{
-	if ((block[0] != 0x00) || (block[1] != 0x00) ||
-	    (block[2] != 0x00) || (block[4] != 0x00))
-		return 1;
-	else
-		return 0;
-}
-
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
 	int i;

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1172153358.4306.17.camel@daplas

#29 lore raw
Quoted 2 lines · Antonino A. Daplas

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

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#30 lore raw
Quoted 5 lines · Giuseppe Bilotta
Quoted 2 lines · Antonino A. Daplas

Ah, my fault. Apply this patch on top.

We're getting closer! The patch now works, and the dmesg has the following info:

Okay.

Quoted 52 lines

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)

Quoted 3 lines

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

#31 lore raw
Quoted 8 lines · Antonino A. Daplas
Quoted 3 lines · Giuseppe Bilotta

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:

Quoted 1 line

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.

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#32 lore raw
Quoted 6 lines · Giuseppe Bilotta
Quoted 5 lines · Antonino A. Daplas
Quoted 3 lines · Giuseppe Bilotta

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

Quoted 7 lines
Quoted 3 lines

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 8 lines
Quoted 2 lines

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

#33 lore raw
Quoted 8 lines · Antonino A. Daplas
Quoted 3 lines · Giuseppe Bilotta

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.

Quoted 2 lines

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 1 line

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.

Signature · 7 lines
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
#34 lore raw
Quoted 6 lines · Giuseppe Bilotta
Quoted 5 lines · Antonino A. Daplas
Quoted 3 lines · Giuseppe Bilotta

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:

Quoted 6 lines
Quoted 3 lines

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 8 lines
Quoted 3 lines

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 6 lines
Quoted 1 line

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

#35 lore raw
Quoted 8 lines · Antonino A. Daplas
Quoted 7 lines · Giuseppe Bilotta

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 1 line

I presume that X's nv driver or vesafb does not exhibit this problem?

Quoted 7 lines
Quoted 4 lines

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

Signature · 1 line
Giuseppe "Oblomov" Bilotta
#36 lore raw
Quoted 14 lines · Giuseppe Bilotta
Quoted 13 lines · Antonino A. Daplas
Quoted 11 lines · Giuseppe Bilotta

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 1 line

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.

Quoted 6 lines
Quoted 2 lines

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

nvidiafb: Bring back generic ddc reading

Make nvidiafb use fb_ddc_read(). This patch was submitted before but was reverted due to problems in a non-x86 platform. This includes a fix for that where ddc reading is bypassed if there is no DDC bus (duh).

---

 drivers/video/nvidia/nv_i2c.c |   44 ++---------------------------------------
 1 files changed, 2 insertions(+), 42 deletions(-)
drivers/video/nvidia/nv_i2c.c +2 -42
index b858897..b91d404 100644
@@ -70,8 +70,6 @@ static int nvidia_gpio_getscl(void *data
 	if (VGA_RD08(par->PCIO, 0x3d5) & 0x04)
 		val = 1;
 
-	val = VGA_RD08(par->PCIO, 0x3d5);
-
 	return val;
 }
 
@@ -159,51 +157,13 @@ void nvidia_delete_i2c_busses(struct nvi
 
 }
 
-static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
-{
-	u8 start = 0x0;
-	struct i2c_msg msgs[] = {
-		{
-		 .addr = 0x50,
-		 .len = 1,
-		 .buf = &start,
-		 }, {
-		     .addr = 0x50,
-		     .flags = I2C_M_RD,
-		     .len = EDID_LENGTH,
-		     },
-	};
-	u8 *buf;
-
-	if (!chan->par)
-		return NULL;
-
-	buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
-	if (!buf) {
-		dev_warn(&chan->par->pci_dev->dev, "Out of memory!\n");
-		return NULL;
-	}
-	msgs[1].buf = buf;
-
-	if (i2c_transfer(&chan->adapter, msgs, 2) == 2)
-		return buf;
-	dev_dbg(&chan->par->pci_dev->dev, "Unable to read EDID block.\n");
-	kfree(buf);
-	return NULL;
-}
-
 int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
 {
 	struct nvidia_par *par = info->par;
 	u8 *edid = NULL;
-	int i;
 
-	for (i = 0; i < 3; i++) {
-		/* Do the real work */
-		edid = nvidia_do_probe_i2c_edid(&par->chan[conn - 1]);
-		if (edid)
-			break;
-	}
+	if (par->chan[conn - 1].par)
+		edid = fb_ddc_read(&par->chan[conn - 1].adapter);
 
 	if (!edid && conn == 1) {
 		/* try to get from firmware */
author Applied
#37 lore raw
Quoted 9 lines · Antonino A. Daplas
Quoted 4 lines · Giuseppe Bilotta

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.

Signature · 7 lines
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
#38 lore raw
Quoted 7 lines · Giuseppe Bilotta
Quoted 6 lines · Antonino A. Daplas
Quoted 4 lines · Giuseppe Bilotta

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,

Quoted 7 lines
Quoted 3 lines

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

#39 lore raw
Quoted 7 lines · Antonino A. Daplas
Quoted 3 lines · Giuseppe Bilotta

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:

Quoted 7 lines

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.

Signature · 7 lines
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
#40 lore raw
Quoted 14 lines · Giuseppe Bilotta
Quoted 13 lines · Antonino A. Daplas
Quoted 3 lines · Giuseppe Bilotta

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);
Quoted 8 lines
Quoted 1 line

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

#41 lore raw
In reply to Giuseppe Bilotta
Quoted 4 lines · Giuseppe Bilotta

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

#42 lore raw
In reply to Giuseppe Bilotta

Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto:

Quoted 17 lines · Antonino A. Daplas
Quoted 7 lines · Giuseppe Bilotta
Quoted 5 lines

As mentioned in another post in this thread, I can't get any info out of the i2c busses, because even when I have them available (i.e. after loading nvidiafb) I get XXXX all around (on all three of them). Suggestions on how to get the information welcome.

Quoted 8 lines

Is this the same monitor you posted here?

http://marc.theaimsgroup.com/?l=linux-kernel&m=112807065616218&w=2

If yes, we already have the manufacturer and model code. The main problem is that the EDID of this display has no sync range (H: 75-75kHz and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID block shouldn't be too hard.

Quoted 6 lines

Yes, that's it! Jeepers, I can't believe that even re-reading the past LKML posts (even those!) I couldn't find the EDID info and how we had gotten them. I guess I need stronger glasses.

Wonder why Luca's proposed patch makes the EDID undetectable, now, and why can't it be retrieved at a later time via i2c. Timeouts too small?

Still scratching my head :|

Tony,
this is the patch (modulo cosmetic stuff) that I sent to Giuseppe. I believe it's correct (I cross checked with X.org driver):

drivers/video/nvidia/nv_i2c.c +0 -2
index b858897..7e64341 100644
@@ -70,8 +70,6 @@ static int nvidia_gpio_getscl(void *data)
 	if (VGA_RD08(par->PCIO, 0x3d5) & 0x04)
 		val = 1;
 
-	val = VGA_RD08(par->PCIO, 0x3d5);
-
 	return val;
 }
 

Luca

Signature · 8 lines
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni

-------------------------------------------------------------------------
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
#43 lore raw
Quoted 11 lines · Luca Tettamanti

Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto:

Quoted 2 lines · Antonino A. Daplas
Quoted 1 line · Giuseppe Bilotta

Still scratching my head :|

Tony,
this is the patch (modulo cosmetic stuff) that I sent to Giuseppe. I believe it's correct (I cross checked with X.org driver):

Yes, the patch does look correct. I also don't understand why Giuseppe's hardware failed to do i2c with this...

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