Messages in this thread | | | Date | Sat, 01 Oct 2005 18:49:08 +0800 | From | "Antonino A. Daplas" <> | Subject | Re: Blanky rivafb vs snowy nvidiafb with 2.6.12 |
| |
Giuseppe Bilotta wrote: > 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.
Yes. But if the EDID block specified a usable hsync and vsync range, the timings can be customized. In your case it does not.
> Maybe a "noddc" or "noedid" module option for > when EDID support is compiled in and one wants to work without it?
It is a good idea. Especially since I've already encountered a lot of crappy EDID blocks.
> >>> 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? >
I documented it in feature-list-2.6.txt, but it is still in the -mm tree.
>>> 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?
get-edid is meant to be a generic reader, that's why it uses the BIOS. nvidiafb uses i2c/ddc and the method is different from manufacturer to manufacturer, chipset to chipset.
> > 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
Yes, you can have nvidiafb and nv with differing visuals. This should not be a problem.
> there was an option to let nv use the Linux-managed framebuffer ... > > Oh yes: > """ > Option "UseFBDev" "true" > """
The "UseFBDev" option was meant to restore the framebuffer console when switching from X to vt. This option is unnecessary in 2.6 kernels. The console layer now detects an X<->console switch, so it can properly inform fbcon and the drivers that it needs to restore the state, or not touch the hardware when X owns the vt.
> > Will this create problems when the FBDev is at a different bitdepth?
It will only slow down the console switch. But it's preferrable to set it to false.
> WIll this slow down either of the sides? >
It should not.
Tony - 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/
| |