Bug 24150

Summary:	tv out issues with radeon kms drm-next
Product:	Mesa	Reporter:	Andy Furniss <adf.lists>
Component:	Drivers/DRI/R100	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	drm bits of dmesg with debug=4 xrandr --verbose with modeset=0 xrandr --verbose with modeset=1 oops with tv=0

Description Andy Furniss 2009-09-25 07:44:32 UTC

Tv is CRT connected with s-video

Card is rv670 (Sapphire HD3850 AGP)

Monitor is PAL CRT connected with DVi -> VGA adapter.

Issue 1.

After loading modules using fbcon (1024x768 on monitor) TV mentions 1920x1200 and the output on TV is incorrect. Screen is split into two halves, the left displaying correctly but squashed and the right side is a shifted slightly left and cropped copy of the right side displayed at half brightness.

drm debug=4 attached, I notice 9 pin DIN is reported, this card has a 7 pin DIN.

Issue 2.

After starting X the TV display is almost correct cloning 1024x768 monitor.

There are however two half bright green lines at the bottom and I can see from banding artifacts on Xorg -retro background that either the scale type is different or it is being scaled to a slightly smaller height.

The green lines do not occur with modeset=0 and the background does not artifact (Though it will when scaling from other than 1024x768)

I noticed that a slightly different modeline is used between kms and ums for the TV. The ums is 59.9Hz vs 60Hz for kms.

xrandr --verboses attached.

I tried changing with xrandr but it didn't affect things (but then it seems that changing modes with different freq doesn't change the ums output either)

Issue 3.

This doesn't actually change anything, but I notice when switching vts between X and fbcon after a few switches the modes reported become strange. TV still works as before.

[drm] TV-11: set mode 1024x768 32
executing set pll
executing set crtc timing
[drm] TV-11: set mode 1920x1200 2f
executing set pll
executing set crtc timing
[drm] TV-11: set mode 1024x768 34
executing set pll
executing set crtc timing
[drm] TV-11: set mode 1920x1200 2f
executing set pll
executing set crtc timing
[drm] TV-11: set mode 1152x768 36
executing set pll
executing set crtc timing
[drm] TV-11: set mode 1920x1200 2f
executing set pll
executing set crtc timing
[drm] TV-11: set mode 640x480 38
executing set pll
executing set crtc timing
[drm] TV-11: set mode 1920x1200 2f
executing set pll
executing set crtc timing
[drm] TV-11: set mode 8×200 3a

Comment 1 Andy Furniss 2009-09-25 07:50:52 UTC

Created attachment 29843 [details]
drm bits of dmesg with debug=4

Comment 2 Andy Furniss 2009-09-25 07:52:07 UTC

Created attachment 29844 [details]
xrandr --verbose with modeset=0

Comment 3 Andy Furniss 2009-09-25 07:53:08 UTC

Created attachment 29845 [details]
xrandr --verbose with modeset=1

Comment 4 Andy Furniss 2009-09-25 07:55:32 UTC

(In reply to comment #0)

> Monitor is PAL CRT connected with DVi -> VGA adapter.

Should be the TV is PAL not the monitor.

Comment 5 Andy Furniss 2009-09-25 13:56:10 UTC

(In reply to comment #0)

Issue 4.

If I modprobe with tv=0 I get an oops (attached) and no displays.

Comment 6 Andy Furniss 2009-09-25 13:57:09 UTC

Created attachment 29851 [details]
oops with tv=0

Comment 7 Andy Furniss 2009-10-08 04:28:03 UTC

(In reply to comment #0)

> Issue 2.
> 
> After starting X the TV display is almost correct cloning 1024x768 monitor.
> 
> There are however two half bright green lines at the bottom and I can see from
> banding artifacts on Xorg -retro background that either the scale type is
> different or it is being scaled to a slightly smaller height. 
> 
> The green lines do not occur with modeset=0 and the background does not
> artifact (Though it will when scaling from other than 1024x768)
> 
> I noticed that a slightly different modeline is used between kms and ums for
> the TV. The ums is 59.9Hz vs 60Hz for kms.

I've found through testing that the difference here is that kms is using NTSC and ums is using PAL. Researching it seems that my old PAL CRT does offer NTSC support.

Testing shows that the frequency of the modeline as shown by xrandr in either case does not change anything - it's 59.94 using kms or 50 using ums.

Comment 8 Alex Deucher 2009-10-08 07:40:05 UTC

(In reply to comment #7)
> 
> I've found through testing that the difference here is that kms is using NTSC
> and ums is using PAL. Researching it seems that my old PAL CRT does offer NTSC
> support.
> 
> Testing shows that the frequency of the modeline as shown by xrandr in either
> case does not change anything - it's 59.94 using kms or 50 using ums.
> 

The modelines reported by xrandr for tv-out are irrelevant.  There just there to provide access to different scaled modes.  The driver programs the tv-out hw directly with the native timing of either NTSC or PAL.  You can use xrandr to select the tv standard (NTSC or PAL) however.  e.g.,
xrandr --output DIN --set "tv standard" "pal"
You may have to double check the property names with kms (xrandr --verbose).

Comment 9 Andy Furniss 2009-10-08 15:45:09 UTC

(In reply to comment #8)

> The modelines reported by xrandr for tv-out are irrelevant.  There just there
> to provide access to different scaled modes.  The driver programs the tv-out hw
> directly with the native timing of either NTSC or PAL.  You can use xrandr to
> select the tv standard (NTSC or PAL) however.  e.g.,
> xrandr --output DIN --set "tv standard" "pal"
> You may have to double check the property names with kms (xrandr --verbose).
> 

xrandr --verbose with kms doesn't list the tv_standard, it does with ums.

I tried changing ums and got errors the first time as I do if I try with kms -

X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  145 (RANDR)
  Minor opcode of failed request:  11 ()
  Serial number of failed request:  27
  Current serial number in output stream:  27

but one time with ums it did accept the command, but just trashed the tv output.

Will try updating xrandr and xserver later and see if that helps.

Comment 10 Andy Furniss 2009-10-08 17:32:17 UTC

(In reply to comment #9)

> 
> Will try updating xrandr and xserver later and see if that helps.
> 

That doesn't help, I also tried a fedora live cd and it's not listed and gives the same error with that.

Comment 11 Andy Furniss 2009-12-02 14:48:43 UTC

(In reply to comment #9)
 You can use xrandr to
> > select the tv standard (NTSC or PAL) however.  e.g.,
> > xrandr --output DIN --set "tv standard" "pal"
> > You may have to double check the property names with kms (xrandr --verbose).
> > 
> 
> xrandr --verbose with kms doesn't list the tv_standard, it does with ums.

This is working now after the recent commit to drm-testing.

I now get pal by default and can switch between pal and ntsc OK.

Comment 12 Andy Furniss 2010-09-24 14:39:08 UTC

(In reply to comment #5)
> (In reply to comment #0)
> 
> Issue 4.
> 
> If I modprobe with tv=0 I get an oops (attached) and no displays.

May as well close this messy multi bug now that the oops is fixed and tv mostly works OK.

The green lines I see in ntsc are still there, but I think I only see them because my TV (pal with ntsc support) seems to get the gamma/brightness way too high for ntsc. The lines are actually there in pal mode as well, but they are so dim with the correct gamma/brightness I get with pal, that you would never notice them at normal viewing distance. They are outside the "drawn area" due to overscan compensation.

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.