From: Giuseppe Bilotta <[email protected]>
Some nVidia video cards have broken EDID information. Using nvidiafb
with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
framebuffer to use wrong timing information, causing the display to be
extremely 'snowy'. Since most distribution kernels are compiled with
CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
framebuffer on said broken system without recompiling the kernel
(or at least the nvidiafb module).
Solve the issue by introducing a new boolean module parameter (useedid)
which can be set to 0 to prevent the driver from using the EDID
information.
Signed-off-by: Giuseppe Bilotta <[email protected]>
---
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
Am Sonntag 28 Januar 2007 schrieb Giuseppe Bilotta:
> From: Giuseppe Bilotta <[email protected]>
> Solve the issue by introducing a new boolean module parameter (useedid)
> which can be set to 0 to prevent the driver from using the EDID
> information.
I don't know whether this is possible, but wouldn't be a cleaner approach be
to put this parameter to something fb specific and not nvidia specific? As
Nvidia fb proabably isn't the only one using edid and so it wouldn't be
necessary to introduce such a parameter for every fb driver...
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Sun, 28 Jan 2007 11:48:59 +0100
Giuseppe Bilotta <[email protected]> wrote:
> From: Giuseppe Bilotta <[email protected]>
>
> Some nVidia video cards have broken EDID information. Using nvidiafb
> with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
> framebuffer to use wrong timing information, causing the display to be
> extremely 'snowy'. Since most distribution kernels are compiled with
> CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
> framebuffer on said broken system without recompiling the kernel
> (or at least the nvidiafb module).
>
> Solve the issue by introducing a new boolean module parameter (useedid)
> which can be set to 0 to prevent the driver from using the EDID
> information.
>
> If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
> altogether.
>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> > 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.
On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <[email protected]> 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?)
On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <[email protected]> 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?
> > > 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.
On 1/29/07, Dave Airlie <[email protected]> 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
Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto:
> On 1/29/07, Dave Airlie <[email protected]> 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.
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 <[email protected]> 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.
On 2/4/07, Luca Tettamanti <[email protected]> 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
Il Sun, Feb 04, 2007 at 10:17:08PM +0100, Giuseppe Bilotta ha scritto:
> On 2/4/07, Luca Tettamanti <[email protected]> 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.
On 2/5/07, Luca Tettamanti <[email protected]> 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
> > > 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.
> On 2/5/07, Luca Tettamanti <[email protected]> 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.
On 2/6/07, James Simmons <[email protected]> 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
Il Tue, Feb 06, 2007 at 09:22:00PM +0000, James Simmons ha scritto:
>
> > On 2/5/07, Luca Tettamanti <[email protected]> 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.
Il Mon, Feb 05, 2007 at 10:28:36PM +0100, Giuseppe Bilotta ha scritto:
> On 2/5/07, Luca Tettamanti <[email protected]> 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)
On 2/8/07, Luca Tettamanti <[email protected]> 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
> > 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.
Sorry for the delay.
Il Thu, Feb 08, 2007 at 01:19:08AM +0100, Giuseppe Bilotta ha scritto:
> On 2/8/07, Luca Tettamanti <[email protected]> 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
(some of you might get this mail in double copy , sorry)
On 2/11/07, Luca Tettamanti <[email protected]> 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
Il Tue, Feb 13, 2007 at 10:25:41AM +0100, Giuseppe Bilotta ha scritto:
> On 2/11/07, Luca Tettamanti <[email protected]> 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.
On 2/17/07, Luca Tettamanti <[email protected]> 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
On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
> On 2/6/07, James Simmons <[email protected]> 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
On 2/22/07, Antonino A. Daplas <[email protected]> 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
On Thu, 2007-02-22 at 09:01 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[email protected]> 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
Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto:
> On 2/22/07, Antonino A. Daplas <[email protected]> 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
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 <[email protected]> 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