Bug 26582

Summary: XRandR property "tv standard" doesn't work with KMS
Product: xorg Reporter: Bob Ham <rah>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Output of xrandr --verbose
none
Output of dmesg
none
X log without VGA connector plugged in
none
X log while setting the 'tv standard' property to kill TV output
none
avivotool patch
none
Register dump of working state
none
Register dump of broken state
none
Another register dump of broken state
none
another avivotool patch
none
New patch register dump of working state
none
New patch register dump of broken state #1
none
New patch register dump of broken state #2
none
List of common registers differing between working/broken states
none
possible fix
none
possible fix none

Description Bob Ham 2010-02-15 12:35:35 UTC
Created attachment 33321 [details]
Output of xrandr --verbose

I've set the xrandr property, "tv standard" to "pal" for the DIN output.  When I enable the output (--mode 1024x768 --right-of DVI-1) there is a TV signal but it is in NTSC, not PAL.

This is with git master (commit 221ef11b31756deb7134801730e76c040e841f5c) of xf86-video-ati and drm-radeon-testing (commit 7cb72ef4d39978e6e07415a2d552b06d567c3079) of the kernel.
Comment 1 Bob Ham 2010-02-15 12:35:58 UTC
Created attachment 33322 [details]
Output of dmesg
Comment 2 Andrew Randrianasulu 2010-02-16 14:29:49 UTC
from provided dmesg: 

[drm] 2: conflicting encoders switching off 9-pin DIN-1
[drm] in favor of DVI-I-1


and many lines like this ..... so TV-out simply not working. Try to force-off DVI-I-1 ?
Comment 3 Bob Ham 2010-02-16 14:46:51 UTC
If, by "force-off DVI-I-1" you mean execute xrandr with an appropriate --off option, this is done prior to both setting the 'tv standard' property and enabling the DIN output.

Is this what you mean by "force-off DVI-I-1"?
Comment 4 Andrew Randrianasulu 2010-02-16 14:49:53 UTC
(In reply to comment #3)
> If, by "force-off DVI-I-1" you mean execute xrandr with an appropriate --off
> option, this is done prior to both setting the 'tv standard' property and
> enabling the DIN output.
> 
> Is this what you mean by "force-off DVI-I-1"?
> 

Yes. Guess you also tried to boot with only two output (screen + TV) connected?
Comment 5 Bob Ham 2010-02-17 00:24:00 UTC
(In reply to comment #4)
> Guess you also tried to boot with only two output (screen + TV) connected?

I hadn't, no.  When booting without the VGA display plugged in, the TV output is enabled from boot and is in NTSC format.  Setting the 'tv standard' property using xrandr does nothing at all; the display continues, it does not flicker and the output format does not change.

The Xorg.0.log for this instance is attached below.
Comment 6 Bob Ham 2010-02-17 00:24:31 UTC
Created attachment 33351 [details]
X log without VGA connector plugged in
Comment 7 Bob Ham 2010-02-17 00:26:18 UTC
When booting with the VGA display plugged in, setting the 'tv standard' property 'pal' after the DIN output has been enabled causes the display to go blank.  X and the driver believe that the output is active but the television displays no signal.

The Xorg.0.log for this instance is attached below.
Comment 8 Bob Ham 2010-02-17 00:27:01 UTC
Created attachment 33352 [details]
X log while setting the 'tv standard' property to kill TV output
Comment 9 Bob Ham 2010-02-17 01:34:06 UTC
Using an empty xorg.conf makes no difference whatsoever to the behavior of the 'tv standard' property.
Comment 10 Andrew Randrianasulu 2010-02-17 03:07:22 UTC
I don't understand what exactly connected to this videocard ...


looking at radeon_encoders.c (gpu/drm/radeon) i found in func
atombios_dac_setup strange case switch:

else {
<------><------>switch (tv_std) {
<------><------>case TV_STD_PAL:
<------><------>case TV_STD_PAL_M:
<------><------>case TV_STD_SCART_PAL:
<------><------>case TV_STD_SECAM:
<------><------>case TV_STD_PAL_CN:
<------><------><------>args.ucDacStandard = ATOM_DAC1_PAL;
<------><------><------>break;
<------><------>case TV_STD_NTSC:
<------><------>case TV_STD_NTSC_J:
<------><------>case TV_STD_PAL_60:
<------><------>default:
<------><------><------>args.ucDacStandard = ATOM_DAC1_NTSC;
<------><------><------>break;

so, it will set NTSC even for PAL-60? Can you try change this or tv_std = line in the same function? (hardcoding ....)
Comment 11 Andrew Randrianasulu 2010-02-17 03:40:16 UTC
Another pal/ntsc bug, but  this one seems to resolved?



http://bugs.freedesktop.org/show_bug.cgi?id=24150
Comment 12 Bob Ham 2010-02-17 04:24:51 UTC
(In reply to comment #10)
> I don't understand what exactly connected to this videocard ...

Ordinarily, a VGA monitor (HP L1909, 1280x1024); a DVI monitor (Dell 2408WFP, 1920x1200); and a PAL TV connected through the DIN->composite adapter.

> looking at radeon_encoders.c (gpu/drm/radeon) i found in func
> atombios_dac_setup strange case switch:

> so, it will set NTSC even for PAL-60? Can you try change this or tv_std = line
> in the same function? (hardcoding ....)

I have never set the 'tv standard' property to 'pal-60' so this will never have occurred.  Just to make the point, though, I have modified atombios_dac_setup like so:

        else {
          /*
                switch (tv_std) {
                case TV_STD_PAL:
                case TV_STD_PAL_M:
                case TV_STD_SCART_PAL:
                case TV_STD_SECAM:
                case TV_STD_PAL_CN:
                        args.ucDacStandard = ATOM_DAC1_PAL;
                        break;
                case TV_STD_NTSC:
                case TV_STD_NTSC_J:
                case TV_STD_PAL_60:
                default:
                        args.ucDacStandard = ATOM_DAC1_NTSC;
                        break;
                }
          */
          args.ucDacStandard = ATOM_DAC1_PAL;
        }

I tested this without the VGA monitor connected.  As expected, it made no difference.
Comment 13 Bob Ham 2010-02-17 04:31:06 UTC
(In reply to comment #11)
> Another pal/ntsc bug, but  this one seems to resolved?
> 
> http://bugs.freedesktop.org/show_bug.cgi?id=24150

The problem in that bug seems to be that the 'tv standard' property didn't exist.  I came across this bug as well.  That bug was fixed; the property does now exist.

The problem in this bug is that the 'tv standard' property does not work.
Comment 14 Andrew Randrianasulu 2010-02-17 05:03:05 UTC
Ok, radeon_connectors.c has  radeon_connector_set_property function. It can exit due to few things ..try to add some DRM_INFO(); and find where exactly it aborts ....

<------>if (property == rdev->mode_info.tv_std_property) {
<------><------>encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TVDAC);
<------><------>if (!encoder) {
<------><------><------>encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_DAC);
<------><------>}

<------><------>if (!encoder)
<------><------><------>return 0;

<------><------>radeon_encoder = to_radeon_encoder(encoder);
<------><------>if (!radeon_encoder->enc_priv)
<------><------><------>return 0;

sorry for <------> - copy/paste from MC (midnight commander) produces this ....
Comment 15 Bob Ham 2010-02-17 06:05:13 UTC
Having added DRM_INFO() calls throughout the function, I can say that it always returns from the final return statement; ie, it always completes and never aborts prematurely.
Comment 16 Alex Deucher 2010-03-08 05:59:17 UTC
Did pal ever work properly for you?  Did pal work with UMS?
Comment 17 Bob Ham 2010-03-08 06:05:13 UTC
(In reply to comment #16)
> Did pal ever work properly for you?  Did pal work with UMS?

Yes, I can switch to PAL with UMS.  This is a regression.
Comment 18 Alex Deucher 2010-03-12 06:43:21 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Did pal ever work properly for you?  Did pal work with UMS?
> 
> Yes, I can switch to PAL with UMS.  This is a regression.
> 

Can you dump the registers with the working UMS config and the non-working KMS config?  Use avivotool (available here: http://cgit.freedesktop.org/~airlied/radeontool or as a package for most distros) as root:

avivotool regs all > working.regs
avivotool regs all > broken.regs

and attach the output here.


Comment 19 Bob Ham 2010-03-12 10:57:54 UTC
(In reply to comment #18)

> Can you dump the registers with the working UMS config and the non-working KMS
> config?

Unfortunately no, I can't.  After cloning and building the radeontool tree, the avivotool program won't run with either UMS or KMS.  When executed as root, it hard-locks the machine.  When run as a user, it segfaults like so:

(gdb) run regs all
Starting program: /usr/local/src/radeontool/avivotool regs all
mapping ctrl region

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bdc4be in pci_device_map_range () from /usr/lib/libpciaccess.so.0
(gdb) bt
#0  0x00007ffff7bdc4be in pci_device_map_range () from /usr/lib/libpciaccess.so.0
#1  0x00000000004063c8 in map_radeon_mem (argc=3, argv=0x7fffffffe310) at avivotool.c:1621
#2  main (argc=3, argv=0x7fffffffe310) at avivotool.c:2085
(gdb) l avivotool.c:1621
1616          
1617        if (pci_device_map_region(avivo_device, ctrl_region, 1) != 0)
1618            fatal("mapping ctrl region\n");
1619        ctrl_mem = avivo_device->regions[ctrl_region].memory;
1620
1621        if (pci_device_map_region(avivo_device, fb_region, 1) != 0)
1622            fatal("mapping fb region\n");
1623        fb_mem = avivo_device->regions[fb_region].memory;
1624
1625        pci_iterator_destroy(iter);
(gdb) 
Comment 20 Alex Deucher 2010-03-12 12:04:47 UTC
Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the drm atom parser that may have fixed this.
Comment 21 Bob Ham 2010-03-12 13:02:22 UTC
(In reply to comment #20)
> Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the
> drm atom parser that may have fixed this.

Sorry, I'm a little confused here.  The kernel I'm using for KMS is from the drm-radeon-testing tree; would that not contain fixes from 2.6.34rc1?
Comment 22 Alex Deucher 2010-03-12 13:13:31 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the
> > drm atom parser that may have fixed this.
> 
> Sorry, I'm a little confused here.  The kernel I'm using for KMS is from the
> drm-radeon-testing tree; would that not contain fixes from 2.6.34rc1?
> 

looks like that branch hasn't been updated in a while.  You're probably better off with drm-linus until Dave updates the drm-radeon-testing branch.
2.6.34rc1 should be the same as drm-linus from the drm's perspective.
Comment 23 Bob Ham 2010-03-12 13:50:32 UTC
(In reply to comment #20)
> Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the
> drm atom parser that may have fixed this.

Alas, 2.6.34rc1 makes no difference.  The 'tv standard' property still does not work and avivotool still hard-locks the machine.
Comment 24 Alex Deucher 2010-04-07 06:37:38 UTC
Created attachment 34763 [details] [review]
avivotool patch

Can you apply this patch to avivotool?  then dump the regs as before:
avivotool regs all
Comment 25 Bob Ham 2010-04-07 08:03:21 UTC
Created attachment 34767 [details]
Register dump of working state
Comment 26 Bob Ham 2010-04-07 08:03:54 UTC
Created attachment 34768 [details]
Register dump of broken state
Comment 27 Bob Ham 2010-04-07 08:04:39 UTC
(In reply to comment #24)

> Can you apply this patch to avivotool?  then dump the regs as before:
> avivotool regs all

Yes, this allows avivotool to run.  Register dumps are attached.
Comment 28 Bob Ham 2010-04-08 01:53:07 UTC
Created attachment 34805 [details]
Another register dump of broken state
Comment 29 Bob Ham 2010-04-08 02:21:56 UTC
I looked at the differences between the working dump and the two broken dumps and came up with a list of registers that are different to both broken dumps:

0000609c
00006120
00006134
00006408
00006410
00006548
0000654c
00006920
00006934
00006b6c
00006c08
00006d48
00006d4c
00006d50
00006d58
00006d78
00006d7c

I used avivotool to set each register in that list to the value in the working dump.  One, and only one register, 0x6120, had any effect on the TV output:

rah@myrtle:/usr/local/src/radeontool$ sudo ./avivotool regset 0x00006120 0x00000d00
OLD: 0x00006120 (6120)  0x00000b80 (2944)
NEW: 0x00006120 (6120)  0x00000d00 (3328)
rah@myrtle:/usr/local/src/radeontool$

Unfortunately, it didn't set it to PAL.  It simply made the TV output appear as a CRT monitor with bad signal timings.
Comment 30 Alex Deucher 2010-04-08 06:56:49 UTC
(In reply to comment #29)

> rah@myrtle:/usr/local/src/radeontool$ sudo ./avivotool regset 0x00006120
> 0x00000d00
> OLD: 0x00006120 (6120)  0x00000b80 (2944)
> NEW: 0x00006120 (6120)  0x00000d00 (3328)
> rah@myrtle:/usr/local/src/radeontool$
> 
> Unfortunately, it didn't set it to PAL.  It simply made the TV output appear as
> a CRT monitor with bad signal timings.  


that register is the crtc pitch.  It will vary based on the size of your desktop surface.
Comment 31 Alex Deucher 2010-04-08 06:58:27 UTC
Created attachment 34810 [details] [review]
another avivotool patch

Hopefully this one won't hang.  dump some more info.
Comment 32 Bob Ham 2010-04-08 09:25:59 UTC
Created attachment 34813 [details]
New patch register dump of working state
Comment 33 Bob Ham 2010-04-08 09:26:50 UTC
Created attachment 34814 [details]
New patch register dump of broken state #1
Comment 34 Bob Ham 2010-04-08 09:27:17 UTC
Created attachment 34815 [details]
New patch register dump of broken state #2
Comment 35 Bob Ham 2010-04-08 09:28:35 UTC
Created attachment 34816 [details]
List of common registers differing between working/broken states
Comment 36 Bob Ham 2010-04-08 09:36:49 UTC
Register dumps attached.

While in the broken state, I attempted to poke each register with the value from the working state.  The following registers did bad things to either the non-TV output or TV output or both: 0x6920, 0x6120, 0x6910, 0x6110, 0x444.

The following registers did bad things to the TV output: 0x43c, 0x430, 0x404.  Specifically, they made the TV output appear as a CRT with bad signal timings.

Of particular interest is register 0x430.  In the working configuration, this has the value 0x620030.  Setting the register with this value in the broken configuration made the TV output appear as a CRT with bad signal timings, as noted.  However, setting it with the value 0x6a0000 made the TV output appear almost like a correct PAL output, as shown in this photograph:

  http://pkl.net/~node/misc/radeon-almost-pal.jpg
Comment 37 Alex Deucher 2010-04-08 09:58:05 UTC
Does changing the following regs help?

avivotool regset 0x404 0x0000800b
avivotool regset 0x430 0x00620030
avivotool regset 0x43c 0x00000006
Comment 38 Alex Deucher 2010-04-08 10:09:35 UTC
Created attachment 34818 [details] [review]
possible fix

Does this drm patch help?  It looks like the tv is rather picky about it's clock. using the fractional fb div should get us much more exact.
Comment 39 Bob Ham 2010-04-08 15:55:16 UTC
(In reply to comment #37)
> Does changing the following regs help?
> 
> avivotool regset 0x404 0x0000800b
> avivotool regset 0x430 0x00620030
> avivotool regset 0x43c 0x00000006

Yes, this (finally) sets the TV output to correct, stable PAL output.


(In reply to comment #38)
> Created an attachment (id=34818) [details]
> possible fix
> 
> Does this drm patch help?  It looks like the tv is rather picky about it's
> clock. using the fractional fb div should get us much more exact.

Strangely, no.  After applying this patch, the output is closer to PAL than the previous close-to-PAL effort:

  http://pkl.net/~node/misc/radeon-almost-pal-2.jpg


When setting the registers as above, the output is a proper PAL signal.  However, it is unstable.  Specifically, after displaying a full-screen video on a different monitor, the TV output will start flickering with what looks like a black box coming out of the noise in between frames.
Comment 40 Alex Deucher 2010-04-09 12:34:00 UTC
Created attachment 34851 [details] [review]
possible fix

Does this patch work any better?
Comment 41 Bob Ham 2010-04-12 06:42:49 UTC
(In reply to comment #40)
> Created an attachment (id=34851) [details]
> possible fix
> 
> Does this patch work any better?

Yes, the output is proper PAL with this patch.


Unfortunately, the VGA output is still broken, as in bug 25520 :

  https://bugs.freedesktop.org/show_bug.cgi?id=25520
Comment 42 Alex Deucher 2010-04-12 09:04:54 UTC
Fix sent to Dave.

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.