Edgar Fu? <ef at math.uni-bonn.de> writes:
> I'm curious what the TDMS bandwidth limit values in
get_tmds_link_bandwidth() are based on.
They're based on what the nvidia proprietary driver itself refuses to
do, though, I'm not 100% sure that I had nv44 in my sample when I made
that change.
> We're using chipset == 44 cards that happily run 1600x1200 at 60 using
the propriety driver and which also used to work with nouveau up to Linux
2.6.36.2. Since 2.6.37, nouveau refuses to use that mode because the required
163M pixel clock exceeds the computed TDMS bandwidth of 155M (earlier versions
allowed for 165M regardless of chipset value).
> Although I cannot tell for sure which timing the closed-source driver runs
1600x1200 at 60 with on these monitors, I find it unlikely that it uses some
built-in, non-EDID timing requiring a lower pixel clock. I also don't
suspect NVidia running their own chips above specs.
It might be using a reduced-blanking mode, check your Xorg.0.log to be
sure. See the "-logverbose" option if you don't get all the
timings
printed out with the default verbosity level.
> So either NVidia doesn't disclose the specs even to their own
programmers, the values in get_tmds_link_bandwidth() are wrong, or, more likely,
I'm missing something.
> Patching get_tmds_link_bandwidth() to allow for 165M already for chipset
>= 0x44 appears to work. However, I don't feel comfortable with
stretching rates above spec.
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20110203/f6fb6ae2/attachment.pgp>