Bug 104043 - TV out garbled with linux > 3.2 (RV516)
Summary: TV out garbled with linux > 3.2 (RV516)
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-03 03:22 UTC by frodzdev
Modified: 2019-11-19 09:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg log (44.14 KB, text/plain)
2017-12-15 12:50 UTC, frodzdev
no flags Details
Xorg log (19.28 KB, text/x-log)
2017-12-15 13:16 UTC, frodzdev
no flags Details
Xorg log (with text/plain content type) (19.28 KB, text/plain)
2017-12-15 13:18 UTC, frodzdev
no flags Details

Description frodzdev 2017-12-03 03:22:13 UTC
With anything more recent an linux 3.16 my S-video TV output looks garbled. Depending on the resolution the black colors are either green-tinted with horizontal stripes, or magenta.

This is with "tv standard" set to ntsc. If I set it to pal the colors look about right but the screen is scrolling.

My xf86-video-ati package version is 7.9

The only way I can get this card working correctly is either by using the 3.16 kernel or using the uvesafb driver. With the 3.16 kernel it works ok but the blacks are a little purple-ish and I have other issues with that kernel.

With the uvesafb driver the colors look perfect and it performs ok for my needs but it underscans so there is a black border around the picture.
Comment 1 frodzdev 2017-12-03 03:47:16 UTC
Correction, the problem happens with linux versions > 3.2
Comment 2 Alex Deucher 2017-12-04 04:41:58 UTC
Please attach your xorg log and dmesg output.  Can you bisect?
Comment 3 frodzdev 2017-12-15 12:32:14 UTC
Hi, thanks for the response and sorry for taking so long but the notification went to spam folder. I will attach the Xorg log later today.

I actually tried to bisect already. The problem is that it doesn't happen all the time (I found that out during the bisect). With a recent kernel it happens all the time but with an older kernel (I'm at g8ff1f792dd68/3.6.0-rc7 right now) it happens about 1 out of 4 boots (rough guess). Luckily the corruption with recent kernels (where it happens all the time) looks different. With newer kernels is just horizontal purple lines, with older ones it alsa has vertical lines. So I may be able to bisect up to the point where it can be reproduced all the time. Hopefully that will help.

When it boots correctly if I start my application (which uses DRM/EGL without X) it starts correctly but when I quit it and return the to the VT console the display gets corrupted most of the time. If I get lucky and quit the app once without the display getting corrupted then I can restart it again and again without getting corruption until I reboot.

Starting X is harder because most of the time the display gets corrupted when X starts.
Comment 4 frodzdev 2017-12-15 12:50:54 UTC
Created attachment 136192 [details]
dmesg log
Comment 5 frodzdev 2017-12-15 13:16:37 UTC
Created attachment 136193 [details]
Xorg log
Comment 6 frodzdev 2017-12-15 13:18:59 UTC
Created attachment 136194 [details]
Xorg log (with text/plain content type)
Comment 7 Martin Peres 2019-11-19 09:31:10 UTC
-- 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/drm/amd/issues/824.


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.