On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote:
> On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> > >
> > > Applied. No noticeable difference, in the sense that the EDID debug
> > > output is still the same and
On Sun, 2007-02-25 at 14:16 +0100, Giuseppe Bilotta wrote:
On 2/25/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow
On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
>
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
Here's a temporary workaround:
In
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> > >
> > > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > > by not compiling in EDID
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect is
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by
On 2/25/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.
Here's a temporary workaround:
In
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
>
> The snowy is constant and abundant, and it seems to be independent of
> video size (640 through 1600) and screen occupation (single prompt
> line to fullscreen mc session) and
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> On 2/23/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> > > and they /all/ come up snowy. This
On 2/23/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> and they /all/ come up snowy. This is starting to look queerer and
> queerer. I've also tried changing vf
On 2/23/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
On 2/23/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> > >
> > > However, I'm still getting the same snowy effects, which doesn't come
> > > as a surprise since the
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 :|
>
>
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,
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
>
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
>
BTW, you can also use CVT
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
> On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> >
> > Ah, my fault. Apply this patch on top.
>
> We're getting closer! The patch now works, and the dmesg has the following
> info:
Okay.
>
>
> ACPI: PCI Interrupt
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
nvidiafb: Device ID:
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
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
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 all
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
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 11 (level,
low) - IRQ 11
nvidiafb: Device ID: 10de0112
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following
info:
Okay.
ACPI: PCI Interrupt :01:00.0[A] -
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
BTW, you can also use CVT modes for
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only 1
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
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode
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
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
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
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
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
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
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,
(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
(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
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 +, James Simmons ha scritto:
> >> There is no stand alone nvidia card i2c driver. Its the issue of sharing
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 +, James Simmons ha scritto:
There is no stand alone nvidia card i2c driver. Its the issue of sharing
> > 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
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
On 2/8/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Il Tue, Feb 06, 2007 at 09:22:00PM +, 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
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
> >
Il Tue, Feb 06, 2007 at 09:22:00PM +, 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
Il Tue, Feb 06, 2007 at 09:22:00PM +, 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,
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
On 2/8/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
Il Tue, Feb 06, 2007 at 09:22:00PM +, 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,
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
> 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
> > > 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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
> 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
>
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
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
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
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
78 matches
Mail list logo
