[R500 x1400] xorg gives black screen with external monitor connected through KVM-switch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you for taking the time to report this bug and helping to make
Ubuntu better. Unfortunately we can't fix it without more information.

Please include the information requested at
https://help.ubuntu.com/community/DebuggingXAutoconfiguration as
separate attachments.

 status incomplete
 subscribe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiv+QwACgkQ06FgkPZwicQAqQCeI4wG2NGNqaBcF0pUCKoR1eDG
tE0AoJoyv2/pH6JZhatpG6T0dcM+kwYv
=m804
-----END PGP SIGNATURE-----

got error messages with 'sudo discover --disable=parallel,serial,usb,ide,scsi,pcmcia --format="%M\t%S\t%D\t%i\n" video', so this is just 'sudo discover'

xresprobe radeon

Can you please also attach the xorg.0.log created with no xorg.conf file present? Thanks

Here you go.

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

just a small fix to the description. All log files so far are from failed attempts with the ext. monitor connected.
This one here is without the ext. monitor.

Hi Rick,

Sorry it's taken so long to respond to this issue. Are you still experiencing it with the released Intrepid?

It sounds to me like the KVM is somehow corrupting the EDID data provided by the monitor. There are two useful tools for looking at the EDID information:

  xrandr --verbose

and, from the read-edid package:

  get-edid | parse-edid

I would suggest running each of these commands once with the monitor directly attached, and once with it through the KVM. See if there are any notable changes, and attach all the output from these commands.

Meanwhile as a workaround, you could also experiment with the IgnoreEDID or NoDDC options (see `man radeon`).

Thanks for your response. With a freshly installed Intrepid (and all upgrades) there has indeed been some development.

X11 still fails, but independently from whether the KVM switch is attached or not. Also, the output from xrandr and get-edid is identical, no matter how the monitor is connected.

I'm attaching both Xorg logs (xorg.conf and xorg.conf.failsafe have been deleted; monitor is directly attached) and the output of both xrandr and get-edid (monitor directly attached).

> Also, the output from xrandr and get-edid is identical, no matter how the monitor is connected.

Well, that's a good sign - implies that the detection is working the same regardless of whether the kvm is present or not. But we'll have to see once the current bug is resolved.

From the log file, I see it is parsing the edid into this (note the 'Unknown vendor field' warning):

(II) RADEON(0): EDID vendor "SAM", prod id 403
(II) RADEON(0): Output: LVDS, Detected Monitor Type: 2
(II) RADEON(0): EDID data from the display on output: LVDS ----------------------
(II) RADEON(0): Manufacturer: CPT Model: 13a6 Serial#: 0
(II) RADEON(0): Year: 2006 Week: 21
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
(II) RADEON(0): Max Image Size [cm]: horiz.: 33 vert.: 21
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): No DPMS capabilities specified
(II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): redX: 0.600 redY: 0.340 greenX: 0.309 greenY: 0.559
(II) RADEON(0): blueX: 0.149 blueY: 0.131 whiteX: 0.315 whiteY: 0.329
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 68.9 MHz Image Size: 331 x 207 mm
(II) RADEON(0): h_active: 1280 h_sync: 1301 h_sync_end 1333 h_blank_end 1408 h_border: 0
(II) RADEON(0): v_active: 800 v_sync: 801 v_sync_end 804 v_blanking: 816 v_border: 0
(WW) RADEON(0): Unknown vendor-specific block f
(II) RADEON(0): FD1631154WB4
(II) RADEON(0): /BRZ����


(II) RADEON(0): EDID (in hex):
(II) RADEON(0): 00ffffffffffff000e14a61300000000
(II) RADEON(0): 15100103802115780a806d99574f8f26
(II) RADEON(0): 21505400000001010101010101010101
(II) RADEON(0): 010101010101ea1a0080502010301520
(II) RADEON(0): 13004bcf100000190000000f00000000
(II) RADEON(0): 0000000000206e050f00000000fe0046
(II) RADEON(0): 44313633313135345742340a000000fe
(II) RADEON(0): 002f42525a81c4eaff01010a2020004b
in RADEONProbeOutputModes
(II) RADEON(0): EDID vendor "CPT", prod id 5030
(II) RADEON(0): Output VGA-0 connected
(II) RADEON(0): Output LVDS connected
(II) RADEON(0): Using fuzzy aspect match for initial modes
(II) RADEON(0): Output VGA-0 using initial mode 1024x768
(II) RADEON(0): Output LVDS using initial mode 1024x768
after xf86InitialConfiguration
(**) RADEON(0): Display dimensions: (380, 300) mm
(**) RADEON(0): DPI set to (106, 135)

You could doublecheck that the same thing gets printed out when the KVM is attached - that will prove that the original KVM issue is resolved, which would be nice.

Meanwhile, as to what could be causing the black screen failure, with these kinds of issues the next step is usually to collect register dumps from both a) when it is working, and b) while it is failed with a black screen. In Jaunty we've updated the radeontool utility for this purpose. You can run it as follows:

  radeontool regmatch '*'

If you want to try using this on Intrepid, you can check out a copy of it from git here:
   http://cgit.freedesktop.org/~airlied/radeontool/

OK, the following results are with a fresh install of Jaunty Alpha 3. The external monitor is different, but the bug is the same.

I'm attaching three different sets of Xorg.log and the radeontool output:

*_1screen: no external monitor, everything works

*_2screen: external monitor (directly connected): black screen

*_kvm: external monitor (connected via KVM switch): black screen

there seems to be no (major) difference between the Xorg.log/radeontool output from the kvm setting and the one where the monitor is plugged in directly.

Hi Rico,

I have to apologize, I asked you for the wrong info. Upstream tells me that radeontool output is only valid for pre-R5xx series chips. For r500 and newer, including the R500-based X1400, they actually need the output from avivotool. This probably explains why you saw no difference between the two radeontool outputs...

avivotool is in the radeontool package, so you already have it installed. Would you mind please re-running your two cases again, and instead collect the output from avivotool? Run it like this:

  avivotool regs all > avivotool_good.txt

Thanks ahead of time, and sorry for the incorrect directions I gave.

No problem, I'm just glad someone's trying to help :)

One little comment though: avivotool is not included in the binary radeontool package, I had to compile it from source.

Since I'm not sure which two cases you're interested in (I think the KVM switch is no longer the issue), I'm again attaching all three cases:

*_1screen: no external monitor, everything works

*_2screen: external monitor (directly connected): black screen

*_kvm: external monitor (connected via KVM switch): black screen

> avivotool is not included in the binary radeontool package, I had to compile it from source.

Ah, thanks, I've uploaded radeontool with this fixed.

Hi Rico,

I've gone ahead and forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=20209 - please subscribe to that bug in case upstream needs further information or wishes you to test something. Thanks ahead of time.

It's possible upstream may wish you to re-test against a newer version of their driver. I've uploaded the just-released 6.11.0 to Jaunty today. You can download an Alpha ISO from http://cdimages.ubuntu.com/releases/jaunty/ and then update it to latest in order to test.

Okay, upstream believes this is now fixed in the 6.11.0 driver we have in Jaunty.

When you get a chance, please test Jaunty and verify. If the problem still occurs, feel free to reopen this bug and we can look further.