Bug 35970 - HDMI TV interlaced modes slightly wrong.
HDMI TV interlaced modes slightly wrong.
Status: NEW
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
git
x86 (IA32) Linux (All)
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-04 15:38 UTC by Andy Furniss
Modified: 2015-02-24 19:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
kms xrandr for tv (with modes after the first four manually added). (4.06 KB, text/plain)
2011-04-04 15:43 UTC, Andy Furniss
no flags Details
kms xorg log (44.87 KB, text/plain)
2011-04-04 15:45 UTC, Andy Furniss
no flags Details
ums xorg log (131.20 KB, text/plain)
2011-04-04 15:47 UTC, Andy Furniss
no flags Details
ums tv xrandr (4.29 KB, text/plain)
2011-04-04 15:51 UTC, Andy Furniss
no flags Details
current xrandr --verbose (5.61 KB, text/plain)
2015-02-24 15:05 UTC, Andy Furniss
no flags Details
possible fix (1.37 KB, patch)
2015-02-24 16:31 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Furniss 2011-04-04 15:38:14 UTC
Running git ddx and d-r-t kernel on rv790.

This shows with both ums and kms - though kms has an extra problem with 576i and 480i.

All interlaced modes my tv supports show the rightmost 25% of the bottom line X4 as the top line.

In addition kms only displays wrong colours on 480i and 576i red -> green, blue-> purple.
Comment 1 Andy Furniss 2011-04-04 15:43:32 UTC
Created attachment 45244 [details]
kms xrandr for tv (with modes after the first four manually added).
Comment 2 Andy Furniss 2011-04-04 15:45:17 UTC
Created attachment 45245 [details]
kms xorg log
Comment 3 Andy Furniss 2011-04-04 15:47:26 UTC
Created attachment 45246 [details]
ums xorg log
Comment 4 Alex Deucher 2011-04-04 15:48:06 UTC
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.
Comment 5 Andy Furniss 2011-04-04 15:51:02 UTC
Created attachment 45247 [details]
ums tv xrandr
Comment 6 Andy Furniss 2011-04-04 16:22:49 UTC
(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.
Comment 7 Florian Mickler 2011-06-30 03:29:47 UTC
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
Comment 8 Rafał Miłecki 2012-02-08 08:52:19 UTC
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)?
Comment 9 Andy Furniss 2012-02-08 11:23:21 UTC
(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.
Comment 10 Andy Furniss 2015-02-24 14:39:52 UTC
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.
Comment 11 Alex Deucher 2015-02-24 14:48:03 UTC
(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.
Comment 12 Andy Furniss 2015-02-24 15:02:08 UTC
(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.
Comment 13 Andy Furniss 2015-02-24 15:05:49 UTC
Created attachment 113794 [details]
current xrandr --verbose
Comment 14 Alex Deucher 2015-02-24 16:31:30 UTC
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?
Comment 15 Andy Furniss 2015-02-24 17:43:39 UTC
(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 ?
Comment 16 Alex Deucher 2015-02-24 19:54:21 UTC
(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.