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
On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
>
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvid
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 supp
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
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)
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 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 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 actua
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 :|
>
> To
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, b
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
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
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
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 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 ev
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 al
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
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
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
(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 mislink
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 the
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,
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
> > bl
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
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 resolu
> 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 i
> > > 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.
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
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 thou
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 out
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 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
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 mo
> > 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
> CONFIG_FB
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 t
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 wo
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 ke
42 matches
Mail list logo
