Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Branden Robinson wrote: 6) ...and the byteswapped cursor. Thanks, Alex! This helped a lot. Problems 1), 2), and 3) above are gone. 4) is no longer applicable; 5) and 6) remain. 5) should be fixed once you switch to Xserver 1.5 and the ati driver snapshot in experimental. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, 2008-05-22 at 08:31 +0200, Brice Goglin wrote: Branden Robinson wrote: 6) ...and the byteswapped cursor. Thanks, Alex! This helped a lot. Problems 1), 2), and 3) above are gone. 4) is no longer applicable; 5) and 6) remain. 5) should be fixed once you switch to Xserver 1.5 and the ati driver snapshot in experimental. I think you mean 6). -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, May 22, 2008 at 09:32:23 +0200, Michel Dänzer wrote: On Thu, 2008-05-22 at 08:31 +0200, Brice Goglin wrote: Branden Robinson wrote: 6) ...and the byteswapped cursor. Thanks, Alex! This helped a lot. Problems 1), 2), and 3) above are gone. 4) is no longer applicable; 5) and 6) remain. 5) should be fixed once you switch to Xserver 1.5 and the ati driver snapshot in experimental. I think you mean 6). And it should even be fixed in xorg-server 2:1.4.1~git20080517-1 (if I understood correctly, and the commit entitled Fix RandR 1.2 driver interface conversion of two colour cursors to ARGB is the relevant one). Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, May 22, 2008 at 2:13 AM, Branden Robinson [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 01:20:45AM -0400, Alex Deucher wrote: On Thu, May 22, 2008 at 12:26 AM, Branden Robinson [EMAIL PROTECTED] wrote: Unfortunately it looks like things have not improved for me, but gotten worse. Now: 1) My detected screen resolution is 1280x768, which is not only too small, but the wrong aspect ratio for my 4:3 monitor; 2) the xrandr tricks that worked around this problem no longer help; 3) in fact, they make the problem worse by throwing the display into an illegible mess; 4) which I can recover from by VT switching to a console and back. 5) But I'm still left with the weird interference pattern, 6) ...and the byteswapped cursor. Please remove the connector table option from your xorg.conf. Thanks, Alex! This helped a lot. Problems 1), 2), and 3) above are gone. 4) is no longer applicable; 5) and 6) remain. In short, I'm now back to the original #348082 status quo, with the added benefit of not having to use the ConnectorTable option as part of the workaround. Also, my monitor now detects as DVI-0, and is not located at DVI-1 as before. Does switching to the other DVI port help? Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, May 22, 2008 at 12:15:04PM -0400, Alex Deucher wrote: In short, I'm now back to the original #348082 status quo, with the added benefit of not having to use the ConnectorTable option as part of the workaround. Also, my monitor now detects as DVI-0, and is not located at DVI-1 as before. Does switching to the other DVI port help? Unfortunately, I cannot find out. The other DVI port is an ADC port, and I don't have compatible hardware: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348082#152 -- G. Branden Robinson| I don't care if it has a GUI, or Debian GNU/Linux | command line, or is carved in mud [EMAIL PROTECTED] | with a sharp spoon. http://people.debian.org/~branden/ | -- Barry Smith signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, May 22, 2008 at 12:26 AM, Branden Robinson [EMAIL PROTECTED] wrote: found 1:6.8.0-1 thanks [see below] On Thu, Sep 13, 2007 at 09:16:39PM -0400, Alex Deucher wrote: On 9/7/07, Branden Robinson [EMAIL PROTECTED] wrote: On Sat, Sep 01, 2007 at 11:21:18AM -0400, Alex Deucher wrote: On 9/1/07, Branden Robinson [EMAIL PROTECTED] wrote: That's three more experiments: 1) xrandr --output DVI-0 --off This appears to be a no-op. The interference is left in place, and it is the same as if I do not use xrandr or xvidmode at all. 2) Option ConnectorTable 3,1,1,3,2,0,0,3 This also has no apparent effect. The same interference is present on server startup. 3) Switch the ConnectorTable back to what I have now*, and plug the monitor into the other DVI port. 4) 3) with the new connectortable. I'm afraid I cannot perform these experiments. Upon trying it, I see that my other video output is an ADC connector, not a DVI connector. http://redwald.deadbeast.net/tmp/debian_bug_348082_damn_ati_connectors.jpeg Also, if you have an analog monitor (VGA connector). it'd be nice to test that to make sure we actually have the dac mapping correct. Another disappointment -- I got rid of my last CRT monitors earlier this year. Given these setbacks, is there something more I can do to help with this bug? Once I merge the external tmds stuff, things might improve. stay tuned. Alex On Sun, Nov 18, 2007 at 05:05:33PM +0100, Brice Goglin wrote: On Thu, Sep 13, 2007 at 09:16:39PM -0400, Alex Deucher wrote: Given these setbacks, is there something more I can do to help with this bug? Once I merge the external tmds stuff, things might improve. stay tuned. Unless I am mistaken, this has been merged now. Branden, is it better with 6.7.196-1 currently in experimental? Unfortunately it looks like things have not improved for me, but gotten worse. Now: 1) My detected screen resolution is 1280x768, which is not only too small, but the wrong aspect ratio for my 4:3 monitor; 2) the xrandr tricks that worked around this problem no longer help; 3) in fact, they make the problem worse by throwing the display into an illegible mess; 4) which I can recover from by VT switching to a console and back. 5) But I'm still left with the weird interference pattern, 6) ...and the byteswapped cursor. Please remove the connector table option from your xorg.conf. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Branden Robinson wrote: found 1:6.8.0-1 thanks Unfortunately it looks like things have not improved for me, but gotten worse. Now: Can you try the latest snapshot in experimental? thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, Sep 13, 2007 at 09:16:39PM -0400, Alex Deucher wrote: Given these setbacks, is there something more I can do to help with this bug? Once I merge the external tmds stuff, things might improve. stay tuned. Unless I am mistaken, this has been merged now. Branden, is it better with 6.7.196-1 currently in experimental? Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 9/7/07, Branden Robinson [EMAIL PROTECTED] wrote: On Sat, Sep 01, 2007 at 11:21:18AM -0400, Alex Deucher wrote: On 9/1/07, Branden Robinson [EMAIL PROTECTED] wrote: That's three more experiments: 1) xrandr --output DVI-0 --off This appears to be a no-op. The interference is left in place, and it is the same as if I do not use xrandr or xvidmode at all. 2) Option ConnectorTable 3,1,1,3,2,0,0,3 This also has no apparent effect. The same interference is present on server startup. 3) Switch the ConnectorTable back to what I have now*, and plug the monitor into the other DVI port. 4) 3) with the new connectortable. I'm afraid I cannot perform these experiments. Upon trying it, I see that my other video output is an ADC connector, not a DVI connector. http://redwald.deadbeast.net/tmp/debian_bug_348082_damn_ati_connectors.jpeg Also, if you have an analog monitor (VGA connector). it'd be nice to test that to make sure we actually have the dac mapping correct. Another disappointment -- I got rid of my last CRT monitors earlier this year. Given these setbacks, is there something more I can do to help with this bug? Once I merge the external tmds stuff, things might improve. stay tuned. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Sat, Sep 01, 2007 at 11:21:18AM -0400, Alex Deucher wrote: On 9/1/07, Branden Robinson [EMAIL PROTECTED] wrote: That's three more experiments: 1) xrandr --output DVI-0 --off This appears to be a no-op. The interference is left in place, and it is the same as if I do not use xrandr or xvidmode at all. 2) Option ConnectorTable 3,1,1,3,2,0,0,3 This also has no apparent effect. The same interference is present on server startup. 3) Switch the ConnectorTable back to what I have now*, and plug the monitor into the other DVI port. 4) 3) with the new connectortable. I'm afraid I cannot perform these experiments. Upon trying it, I see that my other video output is an ADC connector, not a DVI connector. http://redwald.deadbeast.net/tmp/debian_bug_348082_damn_ati_connectors.jpeg Also, if you have an analog monitor (VGA connector). it'd be nice to test that to make sure we actually have the dac mapping correct. Another disappointment -- I got rid of my last CRT monitors earlier this year. Given these setbacks, is there something more I can do to help with this bug? -- G. Branden Robinson|People are equally horrified at Debian GNU/Linux |hearing the Christian religion [EMAIL PROTECTED] |doubted, and at seeing it http://people.debian.org/~branden/ |practiced. -- Samuel Butler signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Fri, Aug 31, 2007 at 11:13:59PM -0400, Alex Deucher wrote: For some reason, when kdm asks for the pixmaps that comprise its background, the X server draws from someplace else in video memory. The following has me pretty convinced given that it comprises a bunch of images from recently-viewed webpages and windows that were unmapped when the previous X session was terminated. Very strange. Can you open an new bug (https://bugs.freedesktop.org) for that? Filed as fd.o #12274. -- G. Branden Robinson| If you're handsome, it's flirting. Debian GNU/Linux | If you're a troll, it's sexual [EMAIL PROTECTED] | harassment. http://people.debian.org/~branden/ | -- George Carlin signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 9/1/07, Branden Robinson [EMAIL PROTECTED] wrote: On Fri, Aug 31, 2007 at 11:22:29PM -0400, Alex Deucher wrote: It appears the driver thinks have two monitors connected. do you? Nope. Just the one, the Samsung SyncMaster 213T. I haven't switched DVI ports yet. Apparently I'm on DVI-1. If not, I think perhaps I got the dac mapping backwards when I suggested the connectortable. does it help if you force off DVI-0 (xrandr --output DVI-0 --off) If I understand you correctly, I'll try this instead of the two xrandr mode switches in my .xsession. Can you also try this connectortable (reverses the dac mapping)? Option ConnectorTable 3,1,1,3,2,0,0,3 That's three more experiments: 1) xrandr --output DVI-0 --off 2) Option ConnectorTable 3,1,1,3,2,0,0,3 3) Switch the ConnectorTable back to what I have now*, and plug the monitor into the other DVI port. 4) 3) with the new connectortable. Also, if you have an analog monitor (VGA connector). it'd be nice to test that to make sure we actually have the dac mapping correct. Thanks, Alex Please let me know if I'm leaving one out. * OptionConnectorTable3,0,1,3,2,1,0,3 -- G. Branden Robinson| Debian GNU/Linux | Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw http://people.debian.org/~branden/ | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iEYEARECAAYFAkbY8/QACgkQ6kxmHytGonzyNwCfdXlDG07WcNTwrGu52U7OX2kX PTkAn32Qdal1j7gh126b5/0YLsadLvH6 =HDn3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, Aug 30, 2007 at 08:16:04PM -0400, Alex Deucher wrote: Any mode change fixes the problem, but modes with resolutions smaller than 1600x1200 get rejected as being too small. Michel Dänzer seemed to think that should work. Should it? Depends on the monitor. In most cases it should. Can you send me the output of xrandr --verbose? Here you go. I'll tackle the rest of your requests this evening or over the weekend. Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1600 x 1600 DVI-1 connected 1600x1200+0+0 (0x4f) normal (normal left inverted right x axis y axis) 432mm x 324mm Identifier: 0x4c Timestamp: -772800836 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00004c2d91003132424e 0e0f0103802b20a02ad0c4a15a4b9723 174f57bfef80a9408180010101010101 010101010101ed3240a060b023403020 2400b044111a00fd00384b1e 510e000a20202020202000fc0053 796e634d61737465720a202000ff 00484348593430303832340a2020001c dvi_monitor_type: auto scaler: fill 1600x1200 (0x4e) 130.4MHz +HSync -VSync h: width 1600 start 1648 end 1680 total 1760 skew0 clock 74.1KHz v: height 1200 start 1202 end 1206 total 1235 clock 60.0Hz 1600x1200 (0x4f) 161.0MHz -HSync +VSync h: width 1600 start 1712 end 1880 total 2160 skew0 clock 74.5KHz v: height 1200 start 1203 end 1207 total 1245 clock 59.9Hz 1280x1024 (0x50) 135.0MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew0 clock 80.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.0Hz 1280x1024 (0x51) 109.0MHz -HSync +VSync h: width 1280 start 1368 end 1496 total 1712 skew0 clock 63.7KHz v: height 1024 start 1027 end 1034 total 1063 clock 59.9Hz 1152x864 (0x52) 108.0MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew0 clock 67.5KHz v: height 864 start 865 end 868 total 900 clock 75.0Hz 1024x768 (0x53) 78.8MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew0 clock 60.1KHz v: height 768 start 769 end 772 total 800 clock 75.1Hz 1024x768 (0x54) 75.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1328 skew0 clock 56.5KHz v: height 768 start 771 end 777 total 806 clock 70.1Hz 1024x768 (0x55) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 832x624 (0x56) 57.3MHz -HSync -VSync h: width 832 start 864 end 928 total 1152 skew0 clock 49.7KHz v: height 624 start 625 end 628 total 667 clock 74.6Hz 800x600 (0x57) 50.0MHz +HSync +VSync h: width 800 start 856 end 976 total 1040 skew0 clock 48.1KHz v: height 600 start 637 end 643 total 666 clock 72.2Hz 800x600 (0x58) 49.5MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew0 clock 46.9KHz v: height 600 start 601 end 604 total 625 clock 75.0Hz 800x600 (0x59) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x5a) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x5b) 31.5MHz -HSync -VSync h: width 640 start 656 end 720 total 840 skew0 clock 37.5KHz v: height 480 start 481 end 484 total 500 clock 75.0Hz 640x480 (0x5c) 31.5MHz -HSync -VSync h: width 640 start 664 end 704 total 832 skew0 clock 37.9KHz v: height 480 start 489 end 491 total 520 clock 72.8Hz 640x480 (0x5d) 30.2MHz -HSync -VSync h: width 640 start 704 end 768 total 864 skew0 clock 35.0KHz v: height 480 start 483 end 486 total 525 clock 66.7Hz 640x480 (0x5e) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 60.0Hz 720x400 (0x5f) 28.3MHz -HSync +VSync h: width 720 start 738 end 846 total 900 skew0 clock 31.5KHz v: height 400 start 412 end 414 total 449 clock 70.1Hz DVI-0 connected 1280x800+0+0 (0x60) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x4d Timestamp:
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
A bit more info: On Thu, Aug 30, 2007 at 08:16:04PM -0400, Alex Deucher wrote: http://redwald.deadbeast.net/tmp/branden_grief_4.jpeg http://redwald.deadbeast.net/tmp/branden_grief_5.jpeg I'll call that new problem #1: this looks like actual framebuffer corruption on top of the video signal interference (sic?) I've been experiencing since I filed this bug. My opinion now is that it has something to do with pixmap cache management. For some reason, when kdm asks for the pixmaps that comprise its background, the X server draws from someplace else in video memory. The following has me pretty convinced given that it comprises a bunch of images from recently-viewed webpages and windows that were unmapped when the previous X session was terminated. http://redwald.deadbeast.net/tmp/branden_grief_6.jpeg (Sigh. I reckon hardcore porn would be less embarrassing than some of that.) xvidtune no longer works to fix the pinkness and striping effect. But I reckon this is expected thanks to some X extension jiggery-pokery -- RandR 1.2 superseding XVidMode. At least that's my vague understanding. Corrections welcome. :) Based on that conjecture, I poked around with xrandr (the utility), and came up with the following recipe: xrandr --output DVI-1 --mode 0x4f xrandr --output DVI-1 --mode 0x4e More for the benefit of debian-x folks or general users, I'll note that sticking the above as the first thing in my $HOME/.xsession works beautifully. New problem #2: The X cursor is corrupted. It looks like the cursor has been sectionally barrel-shifted about the vertical axis. This doesn't visibly affect the insertion point cursor that xterm uses, but the normal right-pointing arrow that KDE uses barely is, and the white hand cursor KDE uses when you hover over the task bar is dramatically affected. known server issue see bug: https://bugs.freedesktop.org/show_bug.cgi?id=11796 I've applied Michel's fix from that bug and it works great. -- G. Branden Robinson| The well-bred contradict other Debian GNU/Linux | people. The wise contradict [EMAIL PROTECTED] | themselves. http://people.debian.org/~branden/ | -- Oscar Wilde signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 8/31/07, Branden Robinson [EMAIL PROTECTED] wrote: A bit more info: On Thu, Aug 30, 2007 at 08:16:04PM -0400, Alex Deucher wrote: http://redwald.deadbeast.net/tmp/branden_grief_4.jpeg http://redwald.deadbeast.net/tmp/branden_grief_5.jpeg I'll call that new problem #1: this looks like actual framebuffer corruption on top of the video signal interference (sic?) I've been experiencing since I filed this bug. My opinion now is that it has something to do with pixmap cache management. For some reason, when kdm asks for the pixmaps that comprise its background, the X server draws from someplace else in video memory. The following has me pretty convinced given that it comprises a bunch of images from recently-viewed webpages and windows that were unmapped when the previous X session was terminated. Very strange. Can you open an new bug (https://bugs.freedesktop.org) for that? Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 8/31/07, Branden Robinson [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 08:16:04PM -0400, Alex Deucher wrote: Any mode change fixes the problem, but modes with resolutions smaller than 1600x1200 get rejected as being too small. Michel Dänzer seemed to think that should work. Should it? Depends on the monitor. In most cases it should. Can you send me the output of xrandr --verbose? Here you go. I'll tackle the rest of your requests this evening or over the weekend. It appears the driver thinks have two monitors connected. do you? If not, I think perhaps I got the dac mapping backwards when I suggested the connectortable. does it help if you force off DVI-0 (xrandr --output DVI-0 --off) Can you also try this connectortable (reverses the dac mapping)? Option ConnectorTable 3,1,1,3,2,0,0,3 Thanks, Alex Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1600 x 1600 DVI-1 connected 1600x1200+0+0 (0x4f) normal (normal left inverted right x axis y axis) 432mm x 324mm Identifier: 0x4c Timestamp: -772800836 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00004c2d91003132424e 0e0f0103802b20a02ad0c4a15a4b9723 174f57bfef80a9408180010101010101 010101010101ed3240a060b023403020 2400b044111a00fd00384b1e 510e000a20202020202000fc0053 796e634d61737465720a202000ff 00484348593430303832340a2020001c dvi_monitor_type: auto scaler: fill 1600x1200 (0x4e) 130.4MHz +HSync -VSync h: width 1600 start 1648 end 1680 total 1760 skew0 clock 74.1KHz v: height 1200 start 1202 end 1206 total 1235 clock 60.0Hz 1600x1200 (0x4f) 161.0MHz -HSync +VSync h: width 1600 start 1712 end 1880 total 2160 skew0 clock 74.5KHz v: height 1200 start 1203 end 1207 total 1245 clock 59.9Hz 1280x1024 (0x50) 135.0MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew0 clock 80.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.0Hz 1280x1024 (0x51) 109.0MHz -HSync +VSync h: width 1280 start 1368 end 1496 total 1712 skew0 clock 63.7KHz v: height 1024 start 1027 end 1034 total 1063 clock 59.9Hz 1152x864 (0x52) 108.0MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew0 clock 67.5KHz v: height 864 start 865 end 868 total 900 clock 75.0Hz 1024x768 (0x53) 78.8MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew0 clock 60.1KHz v: height 768 start 769 end 772 total 800 clock 75.1Hz 1024x768 (0x54) 75.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1328 skew0 clock 56.5KHz v: height 768 start 771 end 777 total 806 clock 70.1Hz 1024x768 (0x55) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 832x624 (0x56) 57.3MHz -HSync -VSync h: width 832 start 864 end 928 total 1152 skew0 clock 49.7KHz v: height 624 start 625 end 628 total 667 clock 74.6Hz 800x600 (0x57) 50.0MHz +HSync +VSync h: width 800 start 856 end 976 total 1040 skew0 clock 48.1KHz v: height 600 start 637 end 643 total 666 clock 72.2Hz 800x600 (0x58) 49.5MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew0 clock 46.9KHz v: height 600 start 601 end 604 total 625 clock 75.0Hz 800x600 (0x59) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x5a) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x5b) 31.5MHz -HSync -VSync h: width 640 start 656 end 720 total 840 skew0 clock 37.5KHz v: height 480 start 481 end 484 total 500 clock 75.0Hz 640x480 (0x5c) 31.5MHz -HSync -VSync h: width 640 start 664 end 704 total 832 skew0 clock 37.9KHz v: height 480 start 489 end 491 total 520 clock 72.8Hz 640x480 (0x5d) 30.2MHz -HSync -VSync h: width 640 start 704 end 768 total 864 skew0 clock 35.0KHz v: height 480 start 483 end 486 total 525 clock 66.7Hz 640x480 (0x5e) 25.2MHz
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Fri, Aug 31, 2007 at 11:22:29PM -0400, Alex Deucher wrote: It appears the driver thinks have two monitors connected. do you? Nope. Just the one, the Samsung SyncMaster 213T. I haven't switched DVI ports yet. Apparently I'm on DVI-1. If not, I think perhaps I got the dac mapping backwards when I suggested the connectortable. does it help if you force off DVI-0 (xrandr --output DVI-0 --off) If I understand you correctly, I'll try this instead of the two xrandr mode switches in my .xsession. Can you also try this connectortable (reverses the dac mapping)? Option ConnectorTable 3,1,1,3,2,0,0,3 That's three more experiments: 1) xrandr --output DVI-0 --off 2) Option ConnectorTable 3,1,1,3,2,0,0,3 3) Switch the ConnectorTable back to what I have now*, and plug the monitor into the other DVI port. Please let me know if I'm leaving one out. * OptionConnectorTable3,0,1,3,2,1,0,3 -- G. Branden Robinson| Debian GNU/Linux | Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, 2007-08-30 at 05:17 -0400, Branden Robinson wrote: The bit that concerns me is common to both: (WW) RADEON(0): Option UseFBDev is not used Don't I kinda have to have that, since I'm on a PowerPC? No, hasn't been necessary (or even very useful) in a while. Hmm, and it says MonitorLayout is not used when I try to use *that*. Anyway, with MonitorLayout I get ugly corruption for a second or two after attempting to start the X server, before the monitor loses track of the video signal from the adapter altogether. Without MonitorLayout, I'm just blank before the monitor loses it. This can't be related to MonitorLayout as the driver no longer knows that option, so it has no effect. Looking at the log file, the driver seems to misdetect the DVI connection as being VGA: (II) RADEON(0): EDID data from the display on connector: VGA -- (II) RADEON(0): Manufacturer: SAM Model: 91 Serial#: 1312961073 (II) RADEON(0): Year: 2005 Week: 14 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input Note the 'Digital Display Input' (and Branden confirmed on IRC it's a real DVI connection). Alex Deucher can probably provide the Option ConnectorTable magic to work around this and then fix it properly. :) -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 8/30/07, Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2007-08-30 at 05:17 -0400, Branden Robinson wrote: The bit that concerns me is common to both: (WW) RADEON(0): Option UseFBDev is not used Don't I kinda have to have that, since I'm on a PowerPC? No, hasn't been necessary (or even very useful) in a while. Hmm, and it says MonitorLayout is not used when I try to use *that*. Anyway, with MonitorLayout I get ugly corruption for a second or two after attempting to start the X server, before the monitor loses track of the video signal from the adapter altogether. Without MonitorLayout, I'm just blank before the monitor loses it. This can't be related to MonitorLayout as the driver no longer knows that option, so it has no effect. Looking at the log file, the driver seems to misdetect the DVI connection as being VGA: (II) RADEON(0): EDID data from the display on connector: VGA -- (II) RADEON(0): Manufacturer: SAM Model: 91 Serial#: 1312961073 (II) RADEON(0): Year: 2005 Week: 14 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input Note the 'Digital Display Input' (and Branden confirmed on IRC it's a real DVI connection). Alex Deucher can probably provide the Option ConnectorTable magic to work around this and then fix it properly. :) Branden, remind me again what card this is and what connectors your card has. Actually, the full log would be useful. It's it a mac, we'll need to add a quirk for it. If it's a powerbook, I may have already fixed it. Alex
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, 2007-08-30 at 09:54 -0400, Alex Deucher wrote: Branden, remind me again what card this is and what connectors your card has. Actually, the full log would be useful. It's it a mac, we'll need to add a quirk for it. If it's a powerbook, I may have already fixed it. Alex, the full history of this bug report is available at http://bugs.debian.org/348082 -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 8/30/07, Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2007-08-30 at 09:54 -0400, Alex Deucher wrote: Branden, remind me again what card this is and what connectors your card has. Actually, the full log would be useful. It's it a mac, we'll need to add a quirk for it. If it's a powerbook, I may have already fixed it. Alex, the full history of this bug report is available at http://bugs.debian.org/348082 ok, I scanned over the bug. It looks like the ddc lines are reversed. What connectors does the card actually have? What model mac is this? I'm assuming that it has a DVI port and a VGA port. Does it have a TV port as well? try: Option ReverseDDC true If that doesn't work we can try some connector tables. Alex
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Thu, Aug 30, 2007 at 10:25:49AM -0400, Alex Deucher wrote: On 8/30/07, Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2007-08-30 at 09:54 -0400, Alex Deucher wrote: Branden, remind me again what card this is and what connectors your card has. Actually, the full log would be useful. It's it a mac, we'll need to add a quirk for it. If it's a powerbook, I may have already fixed it. Alex, the full history of this bug report is available at http://bugs.debian.org/348082 ok, I scanned over the bug. It looks like the ddc lines are reversed. What connectors does the card actually have? 2 DVI ports. What model mac is this? Power Mac G4, dual 1.25GHz, mirrored drive door I'm assuming that it has a DVI port and a VGA port. Does it have a TV port as well? 2 DVI ports, no TV port. try: Option ReverseDDC true If that doesn't work we can try some connector tables. Will do. -- G. Branden Robinson| Mediocrity knows nothing higher Debian GNU/Linux | than itself, but talent instantly [EMAIL PROTECTED] | recognizes genius. http://people.debian.org/~branden/ | -- Sir Arthur Conan Doyle signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 8/30/07, Branden Robinson [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 10:25:49AM -0400, Alex Deucher wrote: On 8/30/07, Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2007-08-30 at 09:54 -0400, Alex Deucher wrote: Branden, remind me again what card this is and what connectors your card has. Actually, the full log would be useful. It's it a mac, we'll need to add a quirk for it. If it's a powerbook, I may have already fixed it. Alex, the full history of this bug report is available at http://bugs.debian.org/348082 ok, I scanned over the bug. It looks like the ddc lines are reversed. What connectors does the card actually have? 2 DVI ports. Ok. now we just need to figure out how the ports are mapped. Since you have two DVI ports I suspect the one you are currently using it drive by an external tmds chip, which is not fully supported at the moment (it might work if OF or macos init's the chip first). That may be part of the reason for the interference. try the following connector table: # port ddcdac tmds connector # port0 VGA_DCC primary external DVI-I # port1 DVI_DCC tvdac internal DVI-I Option ConnectorTable 3,0,1,3,2,1,0,3 If that doesn't work, try swapping the monitor to the other DVI port. Ideally we'd work out the analog mappings as well. Finally, if none of that works try swapping the ddc ports: # port ddcdac tmds connector # port0 DVI_DCC primary external DVI-I # port1 VGA_DCC tvdac internal DVI-I Option ConnectorTable 2,0,1,3,3,1,0,3 the information these numbers correspond to can be found in radeon_probe.h if you are curious. Alex
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On 8/30/07, Branden Robinson [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 01:17:29PM -0400, Alex Deucher wrote: Ok. now we just need to figure out how the ports are mapped. Since you have two DVI ports I suspect the one you are currently using it drive by an external tmds chip, which is not fully supported at the moment (it might work if OF or macos init's the chip first). That may be part of the reason for the interference. try the following connector table: # port ddcdac tmds connector # port0 VGA_DCC primary external DVI-I # port1 DVI_DCC tvdac internal DVI-I Option ConnectorTable 3,0,1,3,2,1,0,3 Progress! This restores the video card's ability to talk to the monitor. Unfortunately, not only does the original bug not appear to be fixed, but there is further degradation. See the following screenshots. The first was after a restart of kdm. The second was after exiting that session and starting a new generation of the X server, though I'm not sure if/how that matters. http://redwald.deadbeast.net/tmp/branden_grief_4.jpeg http://redwald.deadbeast.net/tmp/branden_grief_5.jpeg I'll call that new problem #1: this looks like actual framebuffer corruption on top of the video signal interference (sic?) I've been experiencing since I filed this bug. More data points: xvidtune no longer works to fix the pinkness and striping effect. But I reckon this is expected thanks to some X extension jiggery-pokery -- RandR 1.2 superseding XVidMode. At least that's my vague understanding. Corrections welcome. :) Based on that conjecture, I poked around with xrandr (the utility), and came up with the following recipe: xrandr --output DVI-1 --mode 0x4f xrandr --output DVI-1 --mode 0x4e (0x4e is the mode I actually start in.) Any mode change fixes the problem, but modes with resolutions smaller than 1600x1200 get rejected as being too small. Michel Dänzer seemed to think that should work. Should it? Depends on the monitor. In most cases it should. Can you send me the output of xrandr --verbose? the strange colors and such may be due to the external TMDS chip. it may need some special handling that we are not currently doing that gets fixed after you switch modes. Can you try again with the same connectortable option but the monitor attached to the other DVI port? there's a greater chance of that port working correctly as it uses internal tmds which we know how to program correctly. New problem #2: The X cursor is corrupted. It looks like the cursor has been sectionally barrel-shifted about the vertical axis. This doesn't visibly affect the insertion point cursor that xterm uses, but the normal right-pointing arrow that KDE uses barely is, and the white hand cursor KDE uses when you hover over the task bar is dramatically affected. known server issue see bug: https://bugs.freedesktop.org/show_bug.cgi?id=11796 New problem #3: Console framebuffer corruption: While the X server is alive, there is no problem, but when the X server exits, every character cell on the text VTs gets its left and right halves swapped, making the console unreadable without great effort. The only way I have figured out to correct this is to restart the X server. not sure about this. It may be some issue with radeonfb or the external tmds chip not being reset properly. Alex
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Hi Branden, The randr-1.2 ati driver is now in experimental (6.7.192 uploaded today), it contains a major rework of the driver. Could you test whether your problem still occurs? Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Mon, Aug 27, 2007 at 11:35:33AM +0200, Brice Goglin wrote: Hi Branden, The randr-1.2 ati driver is now in experimental (6.7.192 uploaded today), it contains a major rework of the driver. Could you test whether your problem still occurs? Hi Brice, I'll check into this as soon as I can (I'll shoot for some time this week, tonight UTC-0400 if I'm really lucky). What's the current state of autobuilding experimental? Only i386 packages are up right now. If not, I still know how to build from source, of course, but I don't run anything newer than lenny, so some warning would be appreciated as to whether I'll need to set up a chroot for some bleeding-edge build-deps. Once again, you have my appreciation for the big rubber mallet and pruning shears you've been wielding so ferociously against the X bug list. -- G. Branden Robinson| The last time the Republican Party Debian GNU/Linux | was on the right side of a social [EMAIL PROTECTED] | issue, Abe Lincoln was president. http://people.debian.org/~branden/ | -- Kirk Tofte signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Mon, 2007-08-27 at 11:24 -0400, Branden Robinson wrote: On Mon, Aug 27, 2007 at 11:35:33AM +0200, Brice Goglin wrote: Hi Branden, The randr-1.2 ati driver is now in experimental (6.7.192 uploaded today), it contains a major rework of the driver. Could you test whether your problem still occurs? Hi Brice, I'll check into this as soon as I can (I'll shoot for some time this week, tonight UTC-0400 if I'm really lucky). What's the current state of autobuilding experimental? There is an experimental autobuilder for powerpc, but it usually lags a bit. Only i386 packages are up right now. If not, I still know how to build from source, of course, but I don't run anything newer than lenny, so some warning would be appreciated as to whether I'll need to set up a chroot for some bleeding-edge build-deps. I have everything built for powerpc in a pbuilder chroot. Just let me know which packages you need and I can put them up on people.debian.org. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Branden Robinson wrote: Hi Brice! ii xserver-xorg-core 2:1.3.0.0.dfsg-11 ii xserver-xorg-video-ati 1:6.6.3-2 Still exactly the same, as far as I can tell. I just restarted X within the past day or two. It'd be good to test ati 6.6.192 in experimental too (or 6.7 which should arrive in unstable in the near future). Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Branden Robinson wrote: Package: xserver-xorg Version: 6.9.0.dfsg.1-2 Severity: normal Tags: upstream This is a regression from 6.8.2.dfsg.1-11. I don't even know how to begin to describe the problem I'm having beyond what's in the bug subject. The amount of pinkness and intereference seems to vary with how saturated the rest of the screen is. I took two pictures of my monitor. The images are way too large to attach, so I have put them up on one of my web servers. http://redwald.deadbeast.net/tmp/branden_grief_1.jpeg http://redwald.deadbeast.net/tmp/branden_grief_2.jpeg Sadly, this is so distracting I'll have to downgrade to 6.8.2.dfsg.1-11. Congratulations on getting 6.9.0 into unstable nonetheless. :) Hi Branden, What's the status of this bug with ati driver 6.6.3 (or 6.6.192 in experimental) and xserver-xorg-core 1.3? Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Tue, Jul 24, 2007 at 12:10:48AM +0200, Brice Goglin wrote: I took two pictures of my monitor. The images are way too large to attach, so I have put them up on one of my web servers. http://redwald.deadbeast.net/tmp/branden_grief_1.jpeg http://redwald.deadbeast.net/tmp/branden_grief_2.jpeg Hi Branden, What's the status of this bug with ati driver 6.6.3 (or 6.6.192 in experimental) and xserver-xorg-core 1.3? Hi Brice! ii xserver-xorg-core 2:1.3.0.0.dfsg-11 ii xserver-xorg-video-ati 1:6.6.3-2 Still exactly the same, as far as I can tell. I just restarted X within the past day or two. The pinkness still comes back in exactly the same way on any X server reset, and I can still get rid of it exactly the same way -- run xvidtune, and then adjust the screen right or left. I haven't tried up/down or resizing, but I suspect that any vidmode tweak will just fix the problem. My hardware is still exactly the same as when I filed this report. Thanks very much for your scrupulous attention to old X bugs. -- G. Branden Robinson|It's extremely difficult to govern Debian GNU/Linux |when you control all three branches [EMAIL PROTECTED] |of government. http://people.debian.org/~branden/ |-- John Feehery signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Fri, Jan 20, 2006 at 12:51:36PM -0500, Branden Robinson wrote: On Mon, Jan 16, 2006 at 12:23:50PM +0100, Michel Dänzer wrote: Hi Branden, On Sat, 2006-01-14 at 11:42 -0500, Branden Robinson wrote: Section Device Identifier ATI Radeon 9000 Driver ati Option UseFBDev true Option MonitorLayout TMDS,CRT EndSection Does commenting out one or both of these options make a difference? I'll give that a try this weekend. Earlier this week I was away from the machine. Thanks for the suggestion! Er, I completely zoned on this. FWIW, I am now running: ii xserver-xorg 7.0.18the X.Org X server ii xserver-xorg-core 1.0.2-8 X.Org X server -- core server ii xserver-xorg-input-all7.0.18the X.Org X server -- input driver metapackage ii xserver-xorg-input-evdev 1.0.0.5-2 X.Org X server -- evdev input driver ii xserver-xorg-input-kbd1.0.1.3-2 X.Org X server -- keyboard input driver ii xserver-xorg-input-mouse 1.0.4-3 X.Org X server -- mouse input driver ii xserver-xorg-input-synaptics 0.14.4-5 Synaptics TouchPad driver for X.Org/XFree86 server ii xserver-xorg-input-wacom 0.7.4.1-2 X.Org X server -- wacom input driver ii xserver-xorg-video-all7.0.18the X.Org X server -- output driver metapackage ii xserver-xorg-video-ati6.5.8.0-1 X.Org X server -- ATI display driver ii xserver-xorg-video-chips 1.0.1.3-3 X.Org X server -- Chips display driver ii xserver-xorg-video-fbdev 0.1.0.5-2 X.Org X server -- fbdev display driver ii xserver-xorg-video-glint 1.0.1.3-3 X.Org X server -- Glint display driver ii xserver-xorg-video-imstt 1.0.0.5-2 X.Org X server -- IMSTT display driver ii xserver-xorg-video-mga1.2.1.3.dfsg.1-2 X.Org X server -- MGA display driver ii xserver-xorg-video-nv 1.0.1.5-2 X.Org X server -- NV display driver ii xserver-xorg-video-s3 0.3.5.4-3 X.Org X server -- legacy S3 display driver ii xserver-xorg-video-s3virge1.8.6.5-2 X.Org X server -- S3 ViRGE display driver ii xserver-xorg-video-savage 2.0.2.3-4 X.Org X server -- Savage display driver ii xserver-xorg-video-sis0.8.1.3-2 X.Org X server -- SiS display driver ii xserver-xorg-video-sisusb 0.7.1.3-2 X.Org X server -- SiS USB display driver ii xserver-xorg-video-tdfx 1.1.1.3-3 X.Org X server -- tdfx display driver ii xserver-xorg-video-trident1.0.1.2-2 X.Org X server -- Trident display driver ii xserver-xorg-video-v4l0.0.1.5-1 X.Org X server -- Video 4 Linux display driver ii xserver-xorg-video-vga4.0.0.5-2 X.Org X server -- VGA display driver But there has been no evident change. A few data points: Commenting out both no difference Commenting out only MonitorLayout no difference Commenting out only UseFBDev even worse! Even worse consists of vertical red stripes on the screen. Please see the digital camera photo at: http://redwald.deadbeast.net/tmp/branden_grief_3.jpeg It's a little dark but using flash was worse, and you should still be able to get the gist of the interference. I do have one further data point which renders the X.Org X server usable again. At least as far back as 6.8.2, the X server has had a problem in which the display gets shifted several pixels to the right. This usually happened after power-cycle events on the monitor, but with 7.0 I note that it happens across server resets too. On my Samsung SyncMaster 213T I cannot perform manual adjustments to the positioning on a digital input, so at first this is really awful. However, if I use xvidtune to adjust the screen *either* left *or* right (you'd think only left would work), the screen image is centered perfectly. This worked back in 6.8.2, and I never filed a bug about it. 7.0 still exhibits this problem (and the fix still works) *but*, doing this adjustment also makes the pink interference go away. I haven't tested in the commening out only UseFBDev case yet. So this pink suffusion problem and the off-centered image problem seem to be correlated somehow. Please let me know if I can provide any further information. -- G. Branden Robinson| If you wish to strive for peace of Free Software Developer| soul, then believe; if you wish to [EMAIL PROTECTED] | be a devotee of truth, then http://deadbeast.net/~branden/ | inquire. -- Friedrich Nietzsche signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
On Mon, Jan 16, 2006 at 12:23:50PM +0100, Michel Dänzer wrote: Hi Branden, On Sat, 2006-01-14 at 11:42 -0500, Branden Robinson wrote: Section Device Identifier ATI Radeon 9000 Driver ati Option UseFBDev true Option MonitorLayout TMDS,CRT EndSection Does commenting out one or both of these options make a difference? I'll give that a try this weekend. Earlier this week I was away from the machine. Thanks for the suggestion! -- G. Branden Robinson| When I die I want to go peacefully Debian GNU/Linux | in my sleep like my ol' Grand [EMAIL PROTECTED] | Dad...not screaming in terror like http://people.debian.org/~branden/ | his passengers. signature.asc Description: Digital signature
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Hi Branden, On Sat, 2006-01-14 at 11:42 -0500, Branden Robinson wrote: Section Device Identifier ATI Radeon 9000 Driver ati Option UseFBDev true Option MonitorLayout TMDS,CRT EndSection Does commenting out one or both of these options make a difference? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T
Package: xserver-xorg Version: 6.9.0.dfsg.1-2 Severity: normal Tags: upstream This is a regression from 6.8.2.dfsg.1-11. I don't even know how to begin to describe the problem I'm having beyond what's in the bug subject. The amount of pinkness and intereference seems to vary with how saturated the rest of the screen is. I took two pictures of my monitor. The images are way too large to attach, so I have put them up on one of my web servers. http://redwald.deadbeast.net/tmp/branden_grief_1.jpeg http://redwald.deadbeast.net/tmp/branden_grief_2.jpeg Sadly, this is so distracting I'll have to downgrade to 6.8.2.dfsg.1-11. Congratulations on getting 6.9.0 into unstable nonetheless. :) -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xfree86-dbg xserver-xorg /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 17 Sep 27 10:24 /etc/X11/X - /usr/bin/X11/Xorg -rwxr-xr-x 1 root root 2188224 Jan 6 14:37 /usr/bin/X11/Xorg Contents of /var/lib/xfree86/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) 0001:10:13.0 VGA compatible controller: XGI - Xabre Graphics Inc Volari Z7 /etc/X11/xorg.conf does not match checksum in /var/lib/xfree86/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 3096 Jan 14 10:07 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the manual page. # (Type man at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp .custom # md5sum /var/lib/xfree86/.md5sum # dpkg-reconfigure xserver-xorg Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us Option XkbOptionsctrl:nocaps,compose:ralt EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons false Option ZAxisMapping 4 5 EndSection Section Device Identifier ATI Radeon 9000 Driver ati Option UseFBDev true Option MonitorLayout TMDS,CRT EndSection Section Monitor Identifier Samsung SyncMaster 213T Option DPMS HorizSync 30-75 VertRefresh 50-85 EndSection Section Screen Identifier Default Screen Device ATI Radeon 9000 Monitor Samsung SyncMaster 213T DefaultDepth24 SubSection Display Depth 1 Modes 1600x1200 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1600x1200 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1600x1200 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display
