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.
Created attachment 33322 [details] Output of dmesg
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 ?
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"?
(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?
(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.
Created attachment 33351 [details] X log without VGA connector plugged in
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.
Created attachment 33352 [details] X log while setting the 'tv standard' property to kill TV output
Using an empty xorg.conf makes no difference whatsoever to the behavior of the 'tv standard' property.
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 ....)
Another pal/ntsc bug, but this one seems to resolved? http://bugs.freedesktop.org/show_bug.cgi?id=24150
(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.
(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.
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 ....
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.
Did pal ever work properly for you? Did pal work with UMS?
(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.
(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.
(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)
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.
(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?
(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.
(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.
Created attachment 34763 [details] [review] avivotool patch Can you apply this patch to avivotool? then dump the regs as before: avivotool regs all
Created attachment 34767 [details] Register dump of working state
Created attachment 34768 [details] Register dump of broken state
(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.
Created attachment 34805 [details] Another register dump of broken state
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.
(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.
Created attachment 34810 [details] [review] another avivotool patch Hopefully this one won't hang. dump some more info.
Created attachment 34813 [details] New patch register dump of working state
Created attachment 34814 [details] New patch register dump of broken state #1
Created attachment 34815 [details] New patch register dump of broken state #2
Created attachment 34816 [details] List of common registers differing between working/broken states
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
Does changing the following regs help? avivotool regset 0x404 0x0000800b avivotool regset 0x430 0x00620030 avivotool regset 0x43c 0x00000006
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.
(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.
Created attachment 34851 [details] [review] possible fix Does this patch work any better?
(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
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.