[PATCH] nvidiafb: allow ignoring EDID info

[PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>

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.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>

---

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


diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index 8454adf..6387f2b 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -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;
diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
index 538e947..179fd67 100644
--- a/drivers/video/nvidia/nvidia.c
+++ b/drivers/video/nvidia/nvidia.c
@@ -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");




-- 
Giuseppe "Oblomov" Bilotta

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Am Sonntag 28 Januar 2007 schrieb Giuseppe Bilotta:
> From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>

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

-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Sun, 28 Jan 2007 11:48:59 +0100
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:

> From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> 
> 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.
> 

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.


> diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
> index 8454adf..6387f2b 100644
> --- a/drivers/video/nvidia/nv_i2c.c
> +++ b/drivers/video/nvidia/nv_i2c.c
> @@ -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;
> diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
> index 538e947..179fd67 100644
> --- a/drivers/video/nvidia/nvidia.c
> +++ b/drivers/video/nvidia/nvidia.c
> @@ -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");
> 
> 
> 
> 
> -- 
> Giuseppe "Oblomov" Bilotta
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Sun, 28 Jan 2007 11:48:59 +0100
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:

> From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> 
> 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.
> 

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.


> diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
> index 8454adf..6387f2b 100644
> --- a/drivers/video/nvidia/nv_i2c.c
> +++ b/drivers/video/nvidia/nv_i2c.c
> @@ -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;
> diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
> index 538e947..179fd67 100644
> --- a/drivers/video/nvidia/nvidia.c
> +++ b/drivers/video/nvidia/nvidia.c
> @@ -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");
> 
> 
> 
> 
> -- 
> Giuseppe "Oblomov" Bilotta
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Dave Airlie]

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

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Dave Airlie]

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <airlied@gmail.com> wrote:

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

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

(where'd my cc go?)

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <airlied@gmail.com> wrote:

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

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <airlied@gmail.com> wrote:

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

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?

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <airlied@gmail.com> wrote:

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

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Dave Airlie]

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

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Dave Airlie]

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

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 1/29/07, Dave Airlie <airlied@gmail.com> wrote:
> > > > 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 :)

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto: 
> On 1/29/07, Dave Airlie <airlied@gmail.com> wrote:
> > > > > 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.

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

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

I'll try to code something in the weekend.

Luca
-- 
Do, or do not. There is no try.

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto: 
> On 1/29/07, Dave Airlie <airlied@gmail.com> wrote:
> > > > > 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.

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

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

I'll try to code something in the weekend.

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Tue, Jan 30, 2007 at 09:33:01PM +0100, Luca Tettamanti ha scritto: 
> Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto: 
> > On 1/29/07, Dave Airlie <airlied@gmail.com> wrote:
> > > > > > 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.
> 
> 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).
> 
> > 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
-- 
Sbagliare ? umano, ma per incasinare davvero le cose serve un computer.

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/4/07, Luca Tettamanti <kronos@people.it> wrote:
> 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?

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Sun, Feb 04, 2007 at 10:17:08PM +0100, Giuseppe Bilotta ha scritto: 
> On 2/4/07, Luca Tettamanti <kronos@people.it> wrote:
> >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.
-- 
La somma dell'intelligenza sulla terra è una costante.
La popolazione è in aumento.

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Sun, Feb 04, 2007 at 10:17:08PM +0100, Giuseppe Bilotta ha scritto: 
> On 2/4/07, Luca Tettamanti <kronos@people.it> wrote:
> >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.
-- 
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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> 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.

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[James Simmons]

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

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.

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[James Simmons]

> On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> > 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.

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.
 

Re: [PATCH] nvidiafb: allow ignoring EDID info

[James Simmons]

> On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> > 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.

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/6/07, James Simmons <jsimmons@infradead.org> wrote:
>
> 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.

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto: 
> 
> > On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> > > 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.
> 
> 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
-- 
Se non sei parte della soluzione, allora sei parte del problema.

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto: 
> 
> > On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> > > 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.
> 
> 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
-- 
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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Mon, Feb 05, 2007 at 10:28:36PM +0100, Giuseppe Bilotta ha scritto: 
> On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> > 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).
[...]
> There is no such thing as /dev/i2c* UNLESS I load nvidiafb.

Of course :)

> 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
-- 
"Sei l'unica donna della mia vita".
(Adamo)

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Mon, Feb 05, 2007 at 10:28:36PM +0100, Giuseppe Bilotta ha scritto: 
> On 2/5/07, Luca Tettamanti <kronos@people.it> wrote:
> > 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).
[...]
> There is no such thing as /dev/i2c* UNLESS I load nvidiafb.

Of course :)

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/8/07, Luca Tettamanti <kronos@people.it> wrote:
> Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:
> > 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?

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[James Simmons]

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

Re: [PATCH] nvidiafb: allow ignoring EDID info

[James Simmons]

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


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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Sorry for the delay.

Il Thu, Feb 08, 2007 at 01:19:08AM +0100, Giuseppe Bilotta ha scritto: 
> On 2/8/07, Luca Tettamanti <kronos@people.it> wrote:
> >Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:
> >> 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?

Good question :)

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

diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index 8454adf..ca8bd7e 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -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
-- 
"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

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Sorry for the delay.

Il Thu, Feb 08, 2007 at 01:19:08AM +0100, Giuseppe Bilotta ha scritto: 
> On 2/8/07, Luca Tettamanti <kronos@people.it> wrote:
> >Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:
> >> 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?

Good question :)

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

diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index 8454adf..ca8bd7e 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -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
-- 
"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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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

On 2/11/07, Luca Tettamanti <kronos@people.it> wrote:
> 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.

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Tue, Feb 13, 2007 at 10:25:41AM +0100, Giuseppe Bilotta ha scritto: 
> On 2/11/07, Luca Tettamanti <kronos@people.it> wrote:
> >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)
> 
> """

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

> 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
-- 
Alcuni pensano che io sia una persona orribile, ma non e` vero. Ho il
cuore di un ragazzino - in un vaso sulla scrivania.

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Tue, Feb 13, 2007 at 10:25:41AM +0100, Giuseppe Bilotta ha scritto: 
> On 2/11/07, Luca Tettamanti <kronos@people.it> wrote:
> >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)
> 
> """

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

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/17/07, Luca Tettamanti <kronos@people.it> wrote:
>
> 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

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

> 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

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote: 
> On 2/6/07, James Simmons <jsimmons@infradead.org> wrote:
> >
> > 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.

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

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote: 
> On 2/6/07, James Simmons <jsimmons@infradead.org> wrote:
> >
> > 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.

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


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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> >
> > 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.

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?

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


-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

On Thu, 2007-02-22 at 09:01 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> > >
> > > 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.
> 
> 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?
> 
> > 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

[-- Attachment #2: fbmon_add_sharp_uxga --]
[-- Type: text/plain, Size: 6257 bytes --]

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.

Signed-off-by: Antonino Daplas <adaplas@gmail.com>
---

 drivers/video/fbmon.c |  168 +++++++++++++++++++++++++++++++++----------------
 1 files changed, 112 insertions(+), 56 deletions(-)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 6b385c3..05a9464 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -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;

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

On Thu, 2007-02-22 at 09:01 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> > >
> > > 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.
> 
> 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?
> 
> > 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

[-- Attachment #2: fbmon_add_sharp_uxga --]
[-- Type: text/plain, Size: 6257 bytes --]

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.

Signed-off-by: Antonino Daplas <adaplas@gmail.com>
---

 drivers/video/fbmon.c |  168 +++++++++++++++++++++++++++++++++----------------
 1 files changed, 112 insertions(+), 56 deletions(-)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 6b385c3..05a9464 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -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;

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

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

[-- Attachment #4: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
>
> Ah, my fault.  Apply this patch on top.

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


ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
nvidiafb: Device ID: 10de0112
fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
fbmon: trying to fix monitor timings
nvidiafb: EDID found from BUS2
========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: SHP
   Model: 138e
   Serial#: 0
   Year: 1990 Week 0
   Display Characteristics:
      Monitor Operating Limits: From EDID
           H: 30-75KHz V: 60-60Hz DCLK: 170MHz
      Digital Display Input
      Sync:
      Max H-size in cm: 30
      Max V-size in cm: 23
      Gamma: 2.20
      DPMS: Active no, Suspend yes, Standby yes
      RGB Color Display
      Chroma
         RedX:     0.599 RedY:     0.335
         GreenX:   0.313 GreenY:   0.552
         BlueX:    0.150 BlueY:    0.145
         WhiteX:   0.313 WhiteY:   0.328
      First DETAILED Timing is preferred
   Detailed Timings
      160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync

   Supported VESA Modes
      Manufacturer's mask: 0
   Standard Timings
      1600x1200@60Hz
========================================
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)




However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...


-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >
> > Ah, my fault.  Apply this patch on top.
> 
> We're getting closer! The patch now works, and the dmesg has the following info:

Okay.

> 
> 
> ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> nvidiafb: Device ID: 10de0112
> fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
> fbmon: trying to fix monitor timings
> nvidiafb: EDID found from BUS2
> ========================================
> Display Information (EDID)
> ========================================
>    EDID Version 1.3
>    Manufacturer: SHP
>    Model: 138e
>    Serial#: 0
>    Year: 1990 Week 0
>    Display Characteristics:
>       Monitor Operating Limits: From EDID
>            H: 30-75KHz V: 60-60Hz DCLK: 170MHz
>       Digital Display Input
>       Sync:
>       Max H-size in cm: 30
>       Max V-size in cm: 23
>       Gamma: 2.20
>       DPMS: Active no, Suspend yes, Standby yes
>       RGB Color Display
>       Chroma
>          RedX:     0.599 RedY:     0.335
>          GreenX:   0.313 GreenY:   0.552
>          BlueX:    0.150 BlueY:    0.145
>          WhiteX:   0.313 WhiteY:   0.328
>       First DETAILED Timing is preferred
>    Detailed Timings
>       160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync
> 
>    Supported VESA Modes
>       Manufacturer's mask: 0
>    Standard Timings
>       1600x1200@60Hz
> ========================================
> nvidiafb: CRTC 1 is currently programmed for DFP
> nvidiafb: Using DFP on CRTC 1
> nvidiafb: Panel size is 1600 x 1200
> nvidiafb: Panel is TMDS
> nvidiafb: MTRR set to ON
> nvidiafb: Flat panel dithering disabled
> Console: switching to colour frame buffer device 200x75
> nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)
> 
> 
> 
> 
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
> 

Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.  You might want to change  vfmin and vfmax to 59 and 61
respectively just to get leeway for mode calculation errors. This is in
drivers/video/fbmon.c, particularly b[5] and b[6] in this code:

	case FBMON_FIX_TIMINGS:
		printk("fbmon: trying to fix monitor timings\n");
		b = edid + DETAILED_TIMING_DESCRIPTIONS_START;
		for (i = 0; i < 4; i++) {
			if (!(edid_is_serial_block(b) ||
			      edid_is_ascii_block(b) ||
			      edid_is_monitor_block(b) ||
			      edid_is_timing_block(b))) {
				b[0] = 0x00; 
				b[1] = 0x00;  
				b[2] = 0x00;
				b[3] = 0xfd;   
				b[4] = 0x00;
				b[5] = 60;   /* vfmin */
				b[6] = 60;   /* vfmax */
				b[7] = 30;   /* hfmin */
				b[8] = 75;   /* hfmax */
				b[9] = 17;   /* pixclock - 170 MHz*/
				b[10] = 0;   /* GTF */
				break;
			}

			b += DETAILED_TIMING_DESCRIPTION_SIZE; 
		}

Also try doing fbset 640x480-60, 800x600-60, 1024x768-60 and
1280x1024-60, and if they displayed correctly, we can add these modes to
your EDID block.

Tony

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >
> > Ah, my fault.  Apply this patch on top.
> 
> We're getting closer! The patch now works, and the dmesg has the following info:

Okay.

> 
> 
> ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> nvidiafb: Device ID: 10de0112
> fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
> fbmon: trying to fix monitor timings
> nvidiafb: EDID found from BUS2
> ========================================
> Display Information (EDID)
> ========================================
>    EDID Version 1.3
>    Manufacturer: SHP
>    Model: 138e
>    Serial#: 0
>    Year: 1990 Week 0
>    Display Characteristics:
>       Monitor Operating Limits: From EDID
>            H: 30-75KHz V: 60-60Hz DCLK: 170MHz
>       Digital Display Input
>       Sync:
>       Max H-size in cm: 30
>       Max V-size in cm: 23
>       Gamma: 2.20
>       DPMS: Active no, Suspend yes, Standby yes
>       RGB Color Display
>       Chroma
>          RedX:     0.599 RedY:     0.335
>          GreenX:   0.313 GreenY:   0.552
>          BlueX:    0.150 BlueY:    0.145
>          WhiteX:   0.313 WhiteY:   0.328
>       First DETAILED Timing is preferred
>    Detailed Timings
>       160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync
> 
>    Supported VESA Modes
>       Manufacturer's mask: 0
>    Standard Timings
>       1600x1200@60Hz
> ========================================
> nvidiafb: CRTC 1 is currently programmed for DFP
> nvidiafb: Using DFP on CRTC 1
> nvidiafb: Panel size is 1600 x 1200
> nvidiafb: Panel is TMDS
> nvidiafb: MTRR set to ON
> nvidiafb: Flat panel dithering disabled
> Console: switching to colour frame buffer device 200x75
> nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE0000000)
> 
> 
> 
> 
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
> 

Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.  You might want to change  vfmin and vfmax to 59 and 61
respectively just to get leeway for mode calculation errors. This is in
drivers/video/fbmon.c, particularly b[5] and b[6] in this code:

	case FBMON_FIX_TIMINGS:
		printk("fbmon: trying to fix monitor timings\n");
		b = edid + DETAILED_TIMING_DESCRIPTIONS_START;
		for (i = 0; i < 4; i++) {
			if (!(edid_is_serial_block(b) ||
			      edid_is_ascii_block(b) ||
			      edid_is_monitor_block(b) ||
			      edid_is_timing_block(b))) {
				b[0] = 0x00; 
				b[1] = 0x00;  
				b[2] = 0x00;
				b[3] = 0xfd;   
				b[4] = 0x00;
				b[5] = 60;   /* vfmin */
				b[6] = 60;   /* vfmax */
				b[7] = 30;   /* hfmin */
				b[8] = 75;   /* hfmax */
				b[9] = 17;   /* pixclock - 170 MHz*/
				b[10] = 0;   /* GTF */
				break;
			}

			b += DETAILED_TIMING_DESCRIPTION_SIZE; 
		}

Also try doing fbset 640x480-60, 800x600-60, 1024x768-60 and
1280x1024-60, and if they displayed correctly, we can add these modes to
your EDID block.

Tony


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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> 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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> >
> > However, I'm still getting the same snowy effects, which doesn't come
> > as a surprise since the actual mode timings used are just the same ...
>
> Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
> 1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
> should work.

No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min and max as you suggested:

>  You might want to change  vfmin and vfmax to 59 and 61

and even the M and MR methods which you suggested in the other email.
Since nvidiafb is being loaded from the command line because it's a
blacklisted module otherwise, I've been using the mode_option option.
However, neither the mode_option nor fbset seem to give me anything
not snowy.

Damn.

-- 
Giuseppe "Oblomov" Bilotta

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: 
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> >>
> >> 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.
> 
> 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):

diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index b858897..7e64341 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -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
-- 
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: 
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> >>
> >> 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.
> 
> 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):

diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index b858897..7e64341 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -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
-- 
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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> > >
> > > However, I'm still getting the same snowy effects, which doesn't come
> > > as a surprise since the actual mode timings used are just the same ...
> >
> > Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
> > 1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
> > should work.
> 
> No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> and they /all/ come up snowy. This is starting to look queerer and
> queerer. I've also tried changing vf min and max as you suggested:

Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support?  So this is still a valid
fix?

> 
> >  You might want to change  vfmin and vfmax to 59 and 61
> 
> and even the M and MR methods which you suggested in the other email.
> Since nvidiafb is being loaded from the command line because it's a
> blacklisted module otherwise, I've been using the mode_option option.
> However, neither the mode_option nor fbset seem to give me anything
> not snowy.

When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?

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

Tony

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> > >
> > > However, I'm still getting the same snowy effects, which doesn't come
> > > as a surprise since the actual mode timings used are just the same ...
> >
> > Yes, because the EDID has only 1 mode entry. But now you can use 'fbset
> > 1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
> > should work.
> 
> No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> and they /all/ come up snowy. This is starting to look queerer and
> queerer. I've also tried changing vf min and max as you suggested:

Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support?  So this is still a valid
fix?

> 
> >  You might want to change  vfmin and vfmax to 59 and 61
> 
> and even the M and MR methods which you suggested in the other email.
> Since nvidiafb is being loaded from the command line because it's a
> blacklisted module otherwise, I've been using the mode_option option.
> However, neither the mode_option nor fbset seem to give me anything
> not snowy.

When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?

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

Tony



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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 21:39 +0100, Luca Tettamanti wrote:
> Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: 
> > On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:

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

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Thu, 2007-02-22 at 21:39 +0100, Luca Tettamanti wrote:
> Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: 
> > On 2/22/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/23/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> > and they /all/ come up snowy. This is starting to look queerer and
> > queerer. I've also tried changing vf min and max as you suggested:
>
> Before we proceed, do you agree that the patch will allow you to change
> video modes without disabling DDC support?  So this is still a valid
> fix?

You're right, I hadn't realized that. I can now access all the sizes
from 640 to 1600, so I would say the fix is valid.

> When does your display become snowy? Is the snow constant or does it
> only snow when doing heavy text operations, such as scrolling?

The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage.

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

X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.

-- 
Giuseppe "Oblomov" Bilotta

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/23/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> > and they /all/ come up snowy. This is starting to look queerer and
> > queerer. I've also tried changing vf min and max as you suggested:
>
> Before we proceed, do you agree that the patch will allow you to change
> video modes without disabling DDC support?  So this is still a valid
> fix?

You're right, I hadn't realized that. I can now access all the sizes
from 640 to 1600, so I would say the fix is valid.

> When does your display become snowy? Is the snow constant or does it
> only snow when doing heavy text operations, such as scrolling?

The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage.

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

X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.

-- 
Giuseppe "Oblomov" Bilotta

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> On 2/23/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> > > and they /all/ come up snowy. This is starting to look queerer and
> > > queerer. I've also tried changing vf min and max as you suggested:
> >
> > Before we proceed, do you agree that the patch will allow you to change
> > video modes without disabling DDC support?  So this is still a valid
> > fix?
> 
> You're right, I hadn't realized that. I can now access all the sizes
> from 640 to 1600, so I would say the fix is valid.

Okay, thanks.

> 
> > When does your display become snowy? Is the snow constant or does it
> > only snow when doing heavy text operations, such as scrolling?
> 
> The snowy is constant and abundant, and it seems to be independent of
> video size (640 through 1600) and screen occupation (single prompt
> line to fullscreen mc session) and usage.
> 
> > I presume that X's nv driver or vesafb does not exhibit this problem?
> 
> X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> this reason), then the screen is very snowy with X's nv too.
> 

Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.

Tony

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> On 2/23/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> > > and they /all/ come up snowy. This is starting to look queerer and
> > > queerer. I've also tried changing vf min and max as you suggested:
> >
> > Before we proceed, do you agree that the patch will allow you to change
> > video modes without disabling DDC support?  So this is still a valid
> > fix?
> 
> You're right, I hadn't realized that. I can now access all the sizes
> from 640 to 1600, so I would say the fix is valid.

Okay, thanks.

> 
> > When does your display become snowy? Is the snow constant or does it
> > only snow when doing heavy text operations, such as scrolling?
> 
> The snowy is constant and abundant, and it seems to be independent of
> video size (640 through 1600) and screen occupation (single prompt
> line to fullscreen mc session) and usage.
> 
> > I presume that X's nv driver or vesafb does not exhibit this problem?
> 
> X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> this reason), then the screen is very snowy with X's nv too.
> 

Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.

Tony


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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> >
> > The snowy is constant and abundant, and it seems to be independent of
> > video size (640 through 1600) and screen occupation (single prompt
> > line to fullscreen mc session) and usage.
> >
> > > I presume that X's nv driver or vesafb does not exhibit this problem?
> >
> > X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> > this reason), then the screen is very snowy with X's nv too.
> >
>
> Hmm..., I really don't know how to fix this except to look at Xorg's
> code and look for a difference.

Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is extremely reduced, to the point of
being barely perceptible during normal usage (not as clean as X, but
still very good).

Also, I'm wondering if it might be worth looking at the progress done
in nouveau, and the drm stuff they've implemented (or at least the new
memory management and maybe some of the 2D stuff).

-- 
Giuseppe "Oblomov" Bilotta

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> >
> > The snowy is constant and abundant, and it seems to be independent of
> > video size (640 through 1600) and screen occupation (single prompt
> > line to fullscreen mc session) and usage.
> >
> > > I presume that X's nv driver or vesafb does not exhibit this problem?
> >
> > X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> > this reason), then the screen is very snowy with X's nv too.
> >
>
> Hmm..., I really don't know how to fix this except to look at Xorg's
> code and look for a difference.

Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is extremely reduced, to the point of
being barely perceptible during normal usage (not as clean as X, but
still very good).

Also, I'm wondering if it might be worth looking at the progress done
in nouveau, and the drm stuff they've implemented (or at least the new
memory management and maybe some of the 2D stuff).

-- 
Giuseppe "Oblomov" Bilotta

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through 1600) and screen occupation (single prompt
> > > line to fullscreen mc session) and usage.
> > >
> > > > I presume that X's nv driver or vesafb does not exhibit this problem?
> > >
> > > X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> > > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> > > this reason), then the screen is very snowy with X's nv too.
> > >
> >
> > Hmm..., I really don't know how to fix this except to look at Xorg's
> > code and look for a difference.
> 
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow effect is extremely reduced,

I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption.  It also incorporates Luca's i2c fix.

Tony


[-- Attachment #2: nvidafb_generic_ddc --]
[-- Type: text/plain, Size: 1948 bytes --]

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

Signed-off-by: Antonino Daplas <adaplas@gmail.com>
---

 drivers/video/nvidia/nv_i2c.c |   44 ++---------------------------------------
 1 files changed, 2 insertions(+), 42 deletions(-)

diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index b858897..b91d404 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -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 */

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> >
> > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > by not compiling in EDID support or by using e.g. the ignoreedid patch
> > I had proposed) the snow effect is extremely reduced,
>
> I did not know that, just scanned the entire thread. Try this patch, it
> makes use of fb_ddc_read*() which I believe has extra steps to prevent
> display corruption.  It also incorporates Luca's i2c fix.

Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.

-- 
Giuseppe "Oblomov" Bilotta

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> >
> > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > by not compiling in EDID support or by using e.g. the ignoreedid patch
> > I had proposed) the snow effect is extremely reduced,
>
> I did not know that, just scanned the entire thread. Try this patch, it
> makes use of fb_ddc_read*() which I believe has extra steps to prevent
> display corruption.  It also incorporates Luca's i2c fix.

Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.

-- 
Giuseppe "Oblomov" Bilotta

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> > >
> > > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > > by not compiling in EDID support or by using e.g. the ignoreedid patch
> > > I had proposed) the snow effect is extremely reduced,
> >
> > I did not know that, just scanned the entire thread. Try this patch, it
> > makes use of fb_ddc_read*() which I believe has extra steps to prevent
> > display corruption.  It also incorporates Luca's i2c fix.
> 
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
> 

Here's a temporary workaround:

In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:

	if (par->chan[conn - 1].par)
		edid = fb_ddc_read(&par->chan[conn - 1].adapter);

and make sure CONFIG_FIRMWARE_EDID=y.

Tony

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> > >
> > > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > > by not compiling in EDID support or by using e.g. the ignoreedid patch
> > > I had proposed) the snow effect is extremely reduced,
> >
> > I did not know that, just scanned the entire thread. Try this patch, it
> > makes use of fb_ddc_read*() which I believe has extra steps to prevent
> > display corruption.  It also incorporates Luca's i2c fix.
> 
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
> 

Here's a temporary workaround:

In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:

	if (par->chan[conn - 1].par)
		edid = fb_ddc_read(&par->chan[conn - 1].adapter);

and make sure CONFIG_FIRMWARE_EDID=y.

Tony


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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/25/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> >
> > Applied. No noticeable difference, in the sense that the EDID debug
> > output is still the same and so is the snow effect.
>
> Here's a temporary workaround:
>
> In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
> this out:
>
>         if (par->chan[conn - 1].par)
>                 edid = fb_ddc_read(&par->chan[conn - 1].adapter);
>
> and make sure CONFIG_FIRMWARE_EDID=y.

With this patch, I don't get any dmesg info about my monitor EDID, but
I still get the snow. Could it be that there's something else on my
system which is setting the video to some absurd timings when I
switchg on the framebuffer console? I'm running an up-to-date debian
unstable.

-- 
Giuseppe "Oblomov" Bilotta

Re: [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/25/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> >
> > Applied. No noticeable difference, in the sense that the EDID debug
> > output is still the same and so is the snow effect.
>
> Here's a temporary workaround:
>
> In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
> this out:
>
>         if (par->chan[conn - 1].par)
>                 edid = fb_ddc_read(&par->chan[conn - 1].adapter);
>
> and make sure CONFIG_FIRMWARE_EDID=y.

With this patch, I don't get any dmesg info about my monitor EDID, but
I still get the snow. Could it be that there's something else on my
system which is setting the video to some absurd timings when I
switchg on the framebuffer console? I'm running an up-to-date debian
unstable.

-- 
Giuseppe "Oblomov" Bilotta

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Antonino A. Daplas]

On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote:
> On 2/25/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> > >
> > > Applied. No noticeable difference, in the sense that the EDID debug
> > > output is still the same and so is the snow effect.
> >
> > Here's a temporary workaround:
> >
> > In drivers/video/nvidia/nv_i2c.c:nvidia_probe_i2c_connector(),comment
> > this out:
> >
> >         if (par->chan[conn - 1].par)
> >                 edid = fb_ddc_read(&par->chan[conn - 1].adapter);
> >
> > and make sure CONFIG_FIRMWARE_EDID=y.
> 
> With this patch, I don't get any dmesg info about my monitor EDID, but
> I still get the snow. Could it be that there's something else on my
> system which is setting the video to some absurd timings when I
> switchg on the framebuffer console? I'm running an up-to-date debian
> unstable.
> 

At this point, I don't know.  You're the first person to report this
kind of problem. I'm still studying the nvidiafb and Xorg source code.

Tony