Re: Blanky rivafb vs snowy nvidiafb with 2.6.12

[Giuseppe Bilotta <bilotta78@hotpop.com>]

On Sat, 01 Oct 2005 13:49:59 +0800, Antonino A. Daplas wrote:

> Looks like the nv driver just ignored the EDID and used one of
> its built-in VESA modes.  If you notice, X's EDID ouput is the same
> as nvidiafb's. But the resulting timings are different.
> 
> In contrast, nvidiafb will attempt to use the EDID, and only as a last
> resort, use one of the timings in the global mode database.

I see. And when EDID is enabled for the module, it won't let me touch
those timings at all. Maybe a "noddc" or "noedid" module option for
when EDID support is compiled in and one wants to work without it?

>> D'oh. D'oh. D'oh.
>> 
>> I *really* need someone to repeatedly and savagely hit me on the head
>> with a gigantic, purple-and-yellow CLUEBAT. *sigh*
>> 
>> Somehow, I just assumed that modprobing for the framebuffer driver
>> just loaded everything. But fbcon was *not* automatically load.
>> Indeed, modprobing for fbcon allows me to load nvidiafb OR rivafb
>> without any more screen garbling/blanking problems!
> 
> :-) Yes, many have been burned by this assumption.  If you do want
> 2.4 behavior, you can compile fbcon statically, nvidiafb as a module.
> Doing modprobe nvidiafb will automatically give you a framebuffer
> console.

Yes, after I got the idea that came as an obvious conclusion ... maybe
this should be a FAQ? Documented in the help for fbmod?

>> Notice how rivafb can't read the EDID from DDC/I2C -- and remark that
>> I also have problems reading the EDID with get-edid. Also interesting
> 
> read-edid though uses the Video BIOS to grab the EDID.  So even your
> card's BIOS is having problems doing i2c/ddc.

Yep, and as I already said it's a known problem with my configuration
(it's not clear whether the problem is the video card, with the
montitor, or somewhere inbetween).

>> is that rivafb won't let me get to 16 bit depth or higher. By
> 
> Hmm, I'll check on that again.

That'd be nice.

> Oh well, I think rivafb and nvidiafb have different i2c timeouts.  I believe
> the timeouts in nvidiafb are more correct.

Given that nvidiafb manages to read the edid and rivafb doesn't, I
would say so too :) maybe get-edid needs fixes in that direction too?

Anyway, it looks like I won't have problems using nvidiafb at 16 bits
depth without EDID for the moment ... can I still use X.org's nv at 24
bits at the same time? Can they cooperate on the framebuffer? IIRC
there was an option to let nv use the Linux-managed framebuffer ...

Oh yes:
"""
	Option		"UseFBDev"		"true" 
"""

Will this create problems when the FBDev is at a different bitdepth?
WIll this slow down either of the sides?

-- 
Giuseppe "Oblomov" Bilotta

"Da grande lotterò per la pace"
"A me me la compra il mio babbo"
(Altan)
("When I grow up, I will fight for peace"
 "I'll have my daddy buy it for me")

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/