On Tue, 29 Nov 2005, Antonino A. Daplas wrote:
>
> Nov 28 14:02:32 stiffy kernel: Extrapolated
> Nov 28 14:02:32 stiffy kernel: H: 75-75KHz V: 60-60Hz DCLK: 162MHz
>
> Since the min and max value of the sync timings are equal, nvidiafb has
> no room left to verify the timings, and will _always_ reject any timings even
> if they are valid.
>
> So, try this patch, we make nvidiafb less restrictive by ignoring the
> hsync and vsync ranges if the min and max values are equal. This should
> make your hardware display properly even if CONFIG_FB_NVIDIA_I2c = y.
Tony,
may I suggestinstead making the verifier allow a small error?
I don't find it at all unlikely that some EDID blocks might say that only
a 60Hz refresh rate is allowed. A lot of LCD's are literally specced for
that (just read their manuals), even though they often in practice allow
other frequencies (often _wildly_ different - most modern LCD's are
perfectly happy to sync up with almost anything).
And if a monitor says that it wants a vertical frequency of 60Hz, a mode
that has a frequency of 59 should certainly be accepted.
So it sounds like something has marked a perfectly valid mode as invalid,
just because it's not _exactly_ at the frequency.
So how about allowing a small error in the frequencies in
fb_validate_mode()? And make sure to try to round the divisions to
nearest, not down. Something like the appended (totally untested)..
Linus
----
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index fc7965b..15b0e7e 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1261,10 +1261,15 @@ int fb_validate_mode(const struct fb_var
if (var->vmode & FB_VMODE_DOUBLE)
vtotal *= 2;
- hfreq = pixclock/htotal;
+ hfreq = (pixclock + htotal/2) / htotal;
hfreq = (hfreq + 500) / 1000 * 1000;
- vfreq = hfreq/vtotal;
+ vfreq = (hfreq + vtotal/2) / vtotal;
+
+ /* Allow a 3% error */
+ vfmin -= vfmin >> 5; vfmax += vfmax >> 5;
+ hfmin -= hfmin >> 5; hfmax += hfmax >> 5;
+
return (vfreq < vfmin || vfreq > vfmax ||
hfreq < hfmin || hfreq > hfmax ||
-
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]
