Bug 35970

Created attachment 45244 [details]
kms xrandr for tv (with modes after the first four manually added).

Created attachment 45245 [details]
kms xorg log

Created attachment 45246 [details]
ums xorg log

Does disabling tiling help?
Option "ColorTiling" "False"
in the device section of your xorg.conf

Also does disabling hdmi audio help (with 2.6.38)?  Add:
radeon.audio=0
on the kernel command line in grub.

Created attachment 45247 [details]
ums tv xrandr

(In reply to comment #4)
> Does disabling tiling help?
> Option "ColorTiling" "False"
> in the device section of your xorg.conf

No difference.

> 
> Also does disabling hdmi audio help (with 2.6.38)?  Add:
> radeon.audio=0
> on the kernel command line in grub.

audio=0 fixes the 576i/480i kms colour problem (looking again there was also distortion, also fixed)

Neither fix the top line issue.

I only tested them with kms.

A patch referencing this bug report has been merged in Linux v3.0-rc3:

commit 805c22168da76a65c978017d0fe0d59cd048e995
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Mon Jun 6 17:39:16 2011 -0400

    drm/radeon/kms: disable hdmi audio by default

Andy: I've request to you, could you switch to some updated kernel and try
radeon.audio=1 option in GRUB?

In case of 3.0, please use 3.0.18 or newer.
In case of 3.1, please use 3.1.10 or newer.
In case of 3.2. please use 3.2.2 or newer.
Of course 3.3-rc1 is good as well.

The commit I want you to have is:

commit d21e9677f82d619967c6c918038343fe12bb0f4a
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Fri Dec 23 20:32:18 2011 +0100

    drm/radeon/kms: workaround invalid AVI infoframe checksum issue

Do you still get color and distortion issues when using 576i or 480i (with radeon.audio=1)?

(In reply to comment #8)
> Andy: I've request to you, could you switch to some updated kernel and try
> radeon.audio=1 option in GRUB?
> 
> In case of 3.0, please use 3.0.18 or newer.
> In case of 3.1, please use 3.1.10 or newer.
> In case of 3.2. please use 3.2.2 or newer.
> Of course 3.3-rc1 is good as well.
> 
> The commit I want you to have is:
> 
> commit d21e9677f82d619967c6c918038343fe12bb0f4a
> Author: Rafał Miłecki <zajec5@gmail.com>
> Date:   Fri Dec 23 20:32:18 2011 +0100
> 
>     drm/radeon/kms: workaround invalid AVI infoframe checksum issue
> 
> Do you still get color and distortion issues when using 576i or 480i (with
> radeon.audio=1)?

I am running current drm-core-next, and it doesn't fix it.

Although turning off audio fixes it, I wonder if the the fact that the only two (out of four) interlaced modes that are affected by colour shift and distortion are ones that should be double clocked, but the modes really do AFAICT use the full res eg. These are the modes as displayed by xrandr -

 1440x576 (0x16f)   27.0MHz -HSync -VSync Interlace
        h: width  1440 start 1464 end 1590 total 1728 skew    0 clock   15.6KHz
        v: height  576 start  580 end  586 total  625           clock   25.0Hz
 1440x480 (0x170)   27.0MHz -HSync -VSync Interlace
        h: width  1440 start 1478 end 1602 total 1716 skew    0 clock   15.7KHz
        v: height  480 start  488 end  494 total  525           clock   30.0Hz

Looking at the CAE for the TV and the spec shows that they are 720 wide and each pixel should be sent twice - I think I get normal 1440 wide.

The commit in agd5f drm-next-4.1-wip -

2c1ecad111c82450d715929c12ac9511010d3b6c

drm/radeon: fix interlaced modes
The viewport needs the frame size, not the field size.

Makes things worse for me.

Before this patch testing with R9270X I see the same as I did with with an HD4890 in that normal clock modes are almost OK apart from a bit of wrap around/dup from bottom line to top, low res double clock modes = trash, but then it's not implemented.

With this patch the screen is far more trashed = top 1/5 shredded and displaying some of what is in rest of screen. Bottom 4/5 too dim but not shredded.

FWIW I don't think my TV is "special" as recently I've tested with an intel chip (bay trail) and all interlaced modes are correct with that.

(In reply to Andy Furniss from comment #10)
> The commit in agd5f drm-next-4.1-wip -
> 
> 2c1ecad111c82450d715929c12ac9511010d3b6c
> 
> drm/radeon: fix interlaced modes
> The viewport needs the frame size, not the field size.
> 
> Makes things worse for me.
> 

Does your TV have any native interlaces modes?  If so, do those work?  I.e., are there only problems with manually added interlaces modes?  I think there is some inconsistency with how the vertical timing is stored (whether it is frames or fields) across modelines.

(In reply to Alex Deucher from comment #11)
> (In reply to Andy Furniss from comment #10)
> > The commit in agd5f drm-next-4.1-wip -
> > 
> > 2c1ecad111c82450d715929c12ac9511010d3b6c
> > 
> > drm/radeon: fix interlaced modes
> > The viewport needs the frame size, not the field size.
> > 
> > Makes things worse for me.
> > 
> 
> Does your TV have any native interlaces modes?  If so, do those work?  I.e.,
> are there only problems with manually added interlaces modes?  I think there
> is some inconsistency with how the vertical timing is stored (whether it is
> frames or fields) across modelines.

They are all native (cea vic) modes - I don't add any now.

I guess the xrandr/adding in this bug from 2011 was before xorg/whatever handled CEA properly.

Created attachment 113794 [details]
current xrandr --verbose

Created attachment 113797 [details] [review]
possible fix

(In reply to Andy Furniss from comment #10)
> 
> Before this patch testing with R9270X I see the same as I did with with an
> HD4890 in that normal clock modes are almost OK apart from a bit of wrap
> around/dup from bottom line to top, low res double clock modes = trash, but
> then it's not implemented.

Does this patch fix doublescan?

(In reply to Alex Deucher from comment #14)
> Created attachment 113797 [details] [review] [review]
> possible fix
> 
> (In reply to Andy Furniss from comment #10)
> > 
> > Before this patch testing with R9270X I see the same as I did with with an
> > HD4890 in that normal clock modes are almost OK apart from a bit of wrap
> > around/dup from bottom line to top, low res double clock modes = trash, but
> > then it's not implemented.
> 
> Does this patch fix doublescan?

I can try later but shouldn't it be DRM_MODE_FLAG_DBLCLK ?

(In reply to Andy Furniss from comment #15)
> (In reply to Alex Deucher from comment #14)
> > Created attachment 113797 [details] [review] [review] [review]
> > possible fix
> > 
> > (In reply to Andy Furniss from comment #10)
> > > 
> > > Before this patch testing with R9270X I see the same as I did with with an
> > > HD4890 in that normal clock modes are almost OK apart from a bit of wrap
> > > around/dup from bottom line to top, low res double clock modes = trash, but
> > > then it's not implemented.
> > 
> > Does this patch fix doublescan?
> 
> I can try later but shouldn't it be DRM_MODE_FLAG_DBLCLK ?

Sorry, different feature.  Nevermind the patch.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/18.