Messages in this thread | | | From | Giuseppe Bilotta <> | Subject | Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 | Date | Sat, 1 Oct 2005 09:07:33 +0200 |
| |
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/
| |