lkml.org 
[lkml]   [2005]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Blanky rivafb vs snowy nvidiafb with 2.6.12
Date
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/

\
 
 \ /
  Last update: 2005-10-01 09:11    [W:0.246 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site