Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes

[Alex Deucher]

On Sun, Mar 14, 2010 at 2:32 PM, Bas Wijnen <wijnen at debian.org> wrote:
> On Sun, Mar 14, 2010 at 10:21:02AM -0500, Alex Deucher wrote:
>> >    /* clocks over 135 MHz have heat issues with DVI on RV100 */
>> >    if ((radeon_output->MonType == MT_DFP) &&
>> >        (info->ChipFamily == CHIP_FAMILY_RV100) &&
>> >        (pMode->Clock > 135000))
>> >            return MODE_CLOCK_HIGH;
>> >
>> > This explains why it refuses the mode.
>> >
>> > Looking at the source should not be required for understanding the log
>> > file.  Please make it more readable by adding a line about the heat
>> > issues.  It may also be a good idea to allow overriding the check.  I
>> > never had any trouble using 1600x1200 with this card and monitor.
>>
>> You can start the xserver with higher verbosity levels and it will
>> tell you why modes were rejected.
>
> I didn't test, but looking at the source I find it hard to believe that
> there will be more information than "mode clock too high".  After all,
> the rejecting code (which I quoted above) doesn't provide any more
> information than that.

yeah, that's what it will tell you, but I that's all you should need.

>
>> You can also manually specify modelines in your xorg.conf or at run
>> time using xrandr to override what the driver/xserver's selections.
>
> That might work, but I'm not sure.  This is the code when a modeline is
> already present (in this case it's a default modeline), and is checked
> for validity.  I expect that check to be performed when specifying it
> manually as well.
>
> But I didn't test, because I recompiled the package with the check
> removed, and so I have a workaround already.
>

It will work.  The point of manual modelines is that you can use them
to override what the driver/xserver decides or to add modes that may
not be in your monitor's edid.  If you specify one, then presumably
you know what you are doing.  Running TMDS above 135 Mhz on those
cards is out of spec, so you are on your own, it might work for you,
but will not work for others (in fact the check was added as a bug
fix).

Alex

> Thanks,
> Bas
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkudOdUACgkQFShl+2J8z5UqUQCgi4EPrlPC07IPeA7bYJAO+qbT
> AQ4AoK3FIZp1oqj4XBFo+dCVHb+IFW1u
> =MOx4
> -----END PGP SIGNATURE-----
>
>