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.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.