Description of problem: When booting F11 beta with latest updates on a ThinkPad T41 with ATI Radeon RV250 graphics the svideo output option is missing in xrandr when KMS is enabled (default) Version-Release number of selected component (if applicable): kernel-2.6.29.1-100.fc11.i586 xorg-x11-drv-ati-6.12.2-4.fc11.i586 How reproducible: every time Steps to Reproduce: 1. boot with KMS enabled (default) 2. run xrandr and check for svideo output option 3. Actual results: missing Svideo output option Expected results: xrandr should list svideo, like it does without KMS Additional info: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) ===with KMS=== $ xrandr Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 4096 x 4096 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1400x1050 50.0*+ ===without KMS=== $ xrandr Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 2048 x 1200 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1400x1050 50.0*+ 1280x1024 59.9 60.0 1280x960 60.0 59.9 1280x854 59.9 1280x800 59.8 1280x720 59.9 1152x768 59.8 1024x768 60.0 59.9 800x600 60.3 59.9 56.2 640x480 59.9 59.4 S-video disconnected (normal left inverted right x axis y axis)
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still the case in F12 Rawhide kernel-2.6.31-0.167.rc6.git6.fc12.i686 xorg-x11-drv-ati-6.13.0-0.1.20090821gitb1b77a4d6.fc12.i686
kernel-2.6.31-0.210.rc9.git1 should introduce kms tv-out support let me know if it helps.
xorg-x11-drv-ati-6.13.0-0.3.20090908git651fe5a47.fc12.i686 xorg-x11-server-Xorg-1.6.99.900-1.fc12.i686 kernel-2.6.31-0.212.rc9.git1.fc12.i686 A quick first test seems positive, although I have not actually tried using it. I will try to locate my Svideo cable and try it later. # xrandr Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 4096 x 4096 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1400x1050 50.0*+ 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 S-video disconnected (normal left inverted right x axis y axis)
Ok, I tried it with a S-video to composite cable, connected to a Samsung LCD TV. I hotplugged the cable and ran xrandr, this results in a flash on the display (this also happens with VGA or DVI when hotplugging a display and running xrandr...), and it tries to automatically enable the external display. At this point the LVDS display is messed up, apart from the terminal window where I ran the xrandr command from. No output on the TV. The xrandr output at this point is... $ xrandr Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 4096 x 4096 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1400x1050 50.0*+ 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 S-video connected 800x600+1400+0 (normal left inverted right x axis y axis) 0mm x 0mm 800x600 59.9*+ When then used gpd to lower my LVDS resolution to 800x600, I suddenly got extended desktop, but the picture on the TV is vibrating horizontally. I tried to switch to PAL mode with xrandr (GDP has no option for it), but although it causes a flash of the TV output does not seem to have any other effect. In any case, it should not matter since the LCD TV supports both PAL and NTSC. $ xrandr --output S-video --set tv_standard pal X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 147 (RANDR) Minor opcode of failed request: 11 (RRQueryOutputProperty) Serial number of failed request: 29 Current serial number in output stream: 29 $ xrandr --verbose Screen 0: minimum 320 x 200, current 1600 x 600, maximum 4096 x 4096 VGA-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x52 Timestamp: 533678 Subpixel: no subpixels Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: DVI-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x53 Timestamp: 533678 Subpixel: horizontal rgb Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: LVDS connected 800x600+0+0 (0x5a) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x54 Timestamp: 533678 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 1400x1050 (0x56) 85.0MHz +preferred h: width 1400 start 1472 end 1512 total 1600 skew 0 clock 53.1KHz v: height 1050 start 1052 end 1053 total 1062 clock 50.0Hz 1280x1024 (0x57) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x960 (0x58) 108.0MHz +HSync +VSync h: width 1280 start 1376 end 1488 total 1800 skew 0 clock 60.0KHz v: height 960 start 961 end 964 total 1000 clock 60.0Hz 1024x768 (0x59) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x5a) 40.0MHz +HSync +VSync *current h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x5b) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew 0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x5c) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz S-video connected 800x600+800+0 (0x111) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x55 Timestamp: 533678 Subpixel: no subpixels Clones: CRTC: 1 CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 800x600 (0x111) 38.2MHz -HSync +VSync *current +preferred h: width 800 start 832 end 912 total 1024 skew 0 clock 37.4KHz v: height 600 start 603 end 607 total 624 clock 59.9Hz
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions). Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
situation is still current as in comment #5
Robert with Fedora 12 right ?
I tested again today on F12, to check the current status. It seems nothing changed since the last report. Hotplugging an external Samsung LCD TV after X login, and running 'xrandr' causes a flash on the LVDS, and the LVDS is partly corrupted (panels and active terminal window is OK, background is corrupted). xrandr claims extended desktop is enabled with the external display at 800x600, but TV reports no signal. See picture 1 of LVDS. Enabling mirror mode, does show a picture on the LCD TV, but it 'vibrates' horizontally (see picture 2). The LVDS instead shows a black display with a white horizontal line towards the bottom and a strange white 'burning' spot in the bottom right hand corner (see picture 3). After I let gnome-display-preferences time-out, it returns to extended desktop, but this time it does show a picture on the LCD TV, but the background is corrupted and the display again vibrates (see picture 4).
Created attachment 369395 [details] Picture 1 - LVDS with corrupted background
Created attachment 369396 [details] Picture 2 - LCD TV in mirror mode with vibration
Created attachment 369397 [details] Picture 3 - LVDS in mirror mode
Created attachment 369398 [details] Picture 4 - LCD TV in extended desktop mode with corrupted background and vibration
can you attach dmesg, also might be worth trying latest kernel and latest -ati from koji http://kojipkgs.fedoraproject.org/packages/kernel/2.6.31.6/144.fc12/ http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-ati/6.13.0/0.12.20091119git437113124.fc12/ This might fix some of the things disappearing issues.
Created attachment 374173 [details] Picture 5 - TV output after initial xrandr run I tried the following (latest) versions from koji. I hope that is OK. kernel-2.6.31.6-151.fc12.i686 xorg-x11-drv-ati-6.13.0-0.15.20091127gita8dbf7c23.fc12.i686 when hotplugging the TV, and running xrandr, automatically enables extended desktop. Corruption on the TV is now even worse then before at this point (see Picture 5). But when I then go into gnome-display-properties, and set mirror mode, the output on the TV improves noticeably, but is still not perfect (some vibration and colour bleeding). In addition letting gdp time-out and restore the previous settings does not result in the terrible image as in Picture 5, but keeps the same "quality" of the image as in mirror mode. Note that when in mirror mode, the LVDS still behaves the same as mentioned in Comment #5. Also, I still cannot set any output properties such as PAL.
So in short, some improvements where noted - I do now get a picture on the TV after initial xrandr run, even though it is badly corrupted - the LVDS output is no longer corrupted after initial xrandr run - after messing with gdp, it seems the TV output is slightly better then I was able to get before (still not usable though). - background image is no longer corrupted on the TV output after messing with gdp
I found the LVDS mirror problem (burning), as mentioned above is a separate problem that occurs when lowering the LVDS resolution to less then native, regardless if external monitors are attached or not. https://bugzilla.redhat.com/show_bug.cgi?id=539936 So that leaves for this report the following problems - initial TV output corruption after TV hotplug and running xrandr - horizontal vibration of image on TV output - no way to specify TV mode (PAL vs NTSC) - no way to set any parameters like TV output location/overscan/underscan
I tried kernel-2.6.31.6-161.fc12.i686 from Koji today. when I run xrandr --props I get; S-video connected 800x600+1400+0 (normal left inverted right x axis y axis) 0mm x 0mm tv standard: pal supported: ntsc pal pal-m pal-60 ntsc-j scart-pal pal-cn secam load detection: 1 (0x00000001) range: (1,0) 800x600 59.9*+ I was surprised to notice it defaulted to pal, which is correct for my geographic region. with this I do not get the horizontal vibration, but I do get some colour bleeding which is in particular noticeable in a terminal window with white background and black letters. When I set it to ntsc (xrandr --output S-video --set "tv standard" ntsc) I get the horizontal vibration again. Also, I do not have the problem any longer of getting a totally corrupted display after initial hotplug. I tried every other TV mode option, just to see the result, and several (scart-pal, pal-m, pal-60) caused the TV to display junk for a sec and then report no signal.
To make sure that the hardware is actually capable of producing a somewhat decent picture out of the s-video port, I installed Windows XP on a spare HDD with the ATI drivers. First of all I noticed a few things * windows defaults to NTSC (no surprise) * I get both 800x600 and 1024x768, while under Linux I only get 800x600 for S-video * the list of available TV modes is completely different, I get NTSC-M (default), NTSC-M(Japan), PAL B, PAL D, PAL G, PAL H, PAL I, PAL K and PAL L * I get options for adjusting contrast and colour saturation * I get options for adjusting screen position, screen size and overscan * I get options for adjusting Composite sharpness, S-Video sharpness and Flicker removal In any case with video mode set to NTSC-M, I did not experience any vibration, and with it set to PAL B, I did not experience any colour bleeding either. In fact I tried every one of the available TV modes, and none of them gave these problems, although some did give a out-of-focus look. With the windows drivers, I got the best picture with NTSC-M at 800x600 on my TV.
I was experiencing the same issue on a T40p: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) Using the latest drm-radeon-testing (now in linux-tree) and the latest ddx, I can't reproduce the issue, TV-out is now working fine for me with KMS.
I tried F13alpha with the following levels kernel-2.6.33-1.fc13.i686 libdrm-2.4.18-0.1.fc13.i686 xorg-x11-server-Xorg-1.7.99.901-8.20100223.fc13.i686 xorg-x11-drv-ati-6.13.0-0.24.20100316git819b40153.fc13.i686 mesa-7.8-0.18.fc13 And it made no difference. @bjaglin what kind of cable where you using, a straight svideo or a svideo to composite? I am using a svideo to composite, and perhaps that is the key difference, although the cable works fine with Windows XP. Unfortunately I don't have a straight svideo cable to try.
I am also using a svideo to composite. I haven't tried svideo for about a month or two, but last time I tried in early february or so, with drm-radeon-testing and all the things you are mentionning from git master, I had no problem. I will update this thread next time I try it out.
Improving summary. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers [This triage is part of collective effort done by students of University of Rijeka Department of Informatics.]
Fix summary. Not a FireGL chip.
I gave it another try today with kernel-2.6.35.1-4.rc1.fc14.i686 and xorg-x11-drv-ati-6.13.0-2.fc13.i686 Apart from it defaulting to NTSC, I noticed no change to the output quality.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.