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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
