I have an "ATI Mobility Radeon X1600" (ChipID = 0x71c5). It has four outputs, VGA-1, LVDS-1, HDMI-A-1, and SVIDEO-1. I'm running 2.6.37 final (Ubuntu 2.6.37-12.26) and the Ubuntu xorg edgers 1:6.13.99+git20110110.0e432dff-0ubuntu0sarvatt version of xserver-xorg-video-ati. I'm pretty sure this has something to do with a display being plugged into VGA-1 as well. xrandr --prop Screen 0: minimum 320 x 200, current 3840 x 1350, maximum 8192 x 8192 VGA-0 connected 1920x1200+0+150 (normal left inverted right x axis y axis) 550mm x 340mm EDID: 00ffffffffffff000469a42664070200 1e140103683722782acbd0a35a49a024 135054bfef00714f0101814081809500 b300d1c00101283c80a070b023403020 360026542100001a000000ff0041374c 4d54463133323936340a000000fd0032 4b1e5511000a202020202020000000fc 0041535553205657323636480a200054 load detection: 1 (0x00000001) range: (0,1) 1920x1200 60.0*+ 1920x1080 60.0 1680x1050 60.0 1280x1024 75.0 60.0 1440x900 59.9 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 LVDS connected (normal left inverted right x axis y axis) EDID: 00ffffffffffff004ca3463500000000 00100103802115780a87f594574f8c27 27505400000001010101010101010101 010101010101442f90c4601a0f401858 13004bcf100000190000000f00000000 00000000003cd2026400000000fe0053 414d53554e470a2020202020000000fe 004c544e31353450342d4c30310a007f scaling mode: Full supported: None Full Center Full aspect 1680x1050 60.6 + 1400x1050 60.0 1280x1024 59.9 1440x900 59.9 1280x960 59.9 1280x854 59.9 1280x800 59.8 1280x720 59.9 1152x768 59.8 1024x768 59.9 800x600 59.9 848x480 59.7 720x480 59.7 640x480 59.4 S-video disconnected (normal left inverted right x axis y axis) tv standard: ntsc supported: ntsc pal pal-m pal-60 ntsc-j scart-pal pal-cn secam load detection: 1 (0x00000001) range: (0,1) HDMI-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 550mm x 340mm EDID: 00ffffffffffff000469a42660070200 1e140103803722782acbd0a35a49a024 135054bfef00714f0101814081809500 b30001010101283c80a070b023403020 360026542100001a000000ff0041374c 4d54463133323936300a000000fd0032 4b1e5511000a202020202020000000fc 0041535553205657323636480a2000d3 underscan vborder: 0 (0x00000000) range: (0,128) underscan hborder: 0 (0x00000000) range: (0,128) underscan: auto supported: off on auto coherent: 1 (0x00000001) range: (0,1) 1920x1200 60.0*+ 1680x1050 60.0 1280x1024 75.0 60.0 1440x900 59.9 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 When I plug my laptop into the docking station which the monitor is plugged into, I get: [ 94924.709] (II) RADEON(0): EDID vendor "SEC", prod id 13638 [ 94924.709] (II) RADEON(0): Printing DDC gathered Modelines: [ 94924.709] (II) RADEON(0): Modeline "1680x1050"x0.0 121.00 1680 1704 1792 1876 1050 1051 1054 1065 -hsync -vsync (64.5 kHz) [ 94926.272] (II) RADEON(0): EDID vendor "SEC", prod id 13638 [ 94926.272] (II) RADEON(0): Printing DDC gathered Modelines: [ 94926.272] (II) RADEON(0): Modeline "1680x1050"x0.0 121.00 1680 1704 1792 1876 1050 1051 1054 1065 -hsync -vsync (64.5 kHz) [ 94926.537] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840 [ 94926.749] (II) RADEON(0): VRAM usage limit set to 213120K
Please attach your xorg log and dmesg output.
Created attachment 41999 [details] dmesg I originally thought this had to do with being connected at powerup, but it really has to do with it breaking after powerup. The attached dmesg and xorg.log is from: powerup laptop with no external displays connected plug laptop into docking station. LVDS-1 turns off, HDMI-A-1 and VGA-1 turn on suspend laptop wake laptop, VGA-1 turns on, HDMI-A-1 does not
Created attachment 42000 [details] [review] Xorg.0.log
Does the LVDS come on when you resume? X may be getting confused and enabling the wrong displays on resume (LVDS+VGA rather than VGA+HDMI) since all are attached. Can you manually reconfigure things using xrandr after resume?
xrandr shows LVDS as being off and HDMI as being on. Manually fussing with xrandr doesn't change anything, but I can turn the LVDS display on and off. However, if I try to turn all three displays on at a time, X segfaults (or at least the last time I tried it did).
(In reply to comment #5) > xrandr shows LVDS as being off and HDMI as being on. Manually fussing with > xrandr doesn't change anything, but I can turn the LVDS display on and off. > However, if I try to turn all three displays on at a time, X segfaults (or at > least the last time I tried it did). Can you attach the output of 'xrandr --verbose' before and after resume? Also, if you get a segfault, can you get a backtrace and attach it here?
Created attachment 42508 [details] xrandr --verbose (before suspend)
Created attachment 42509 [details] xrandr --verbose (after resume)
The xorg crashing thing is no longer true, its been fixed at some point. gnome-display-properties still gets confused and thinks it successfully configured all three, but there is no crash. (and closing and re-opening gnome-display-properties changes it back to only showing two displays enabled.
Does a dpms cycle help? xset dpms force off Does restarting X help? How about forcing a mode change? e.g., xrandr --output HDMI-0 --mode 1680x1050
> Does a dpms cycle help? > xset dpms force off Nope (but causes the VGA-0 monitor to flash off and on) > Does restarting X help? Nope > How about forcing a mode change? e.g., > xrandr --output HDMI-0 --mode 1680x1050 Nope
Can you dump the following regs with avivotool (available here: http://cgit.freedesktop.org/~airlied/radeontool/) as root before and after suspend? avivotool regmatch <reg> Where <reg> = 0x7880 0x7884 0x7888 0x788c 0x7890 0x7894 0x7898 0x789c 0x78a0 0x78a4 0x78a8 0x78ac 0x78b0 0x78b4 0x78b8 0x78bc 0x78c0 0x78c4 0x78c8 0x78cc 0x78d0 0x78d4 0x78d8 0x78dc 0x78e0 0x7904 0x7908 0x790c 0x7910 0x7914 0x7918 0x791c
Created attachment 42572 [details] avivotool regmatch <0x7880..0x791c> (before suspend)
Created attachment 42573 [details] avivotool regmatch <0x7880..0x791c> (after resume) Both files are identical
So there is a DVI port on the dock and an hdmi port on the laptop. It's likely they share the same encoder and there may some gpio magic involved in switching between them. I don't see any router info in the vbios, so it's likely to be a system specific thing. Maybe some acpi method? When the hdmi port isn't working, does the DVI port work or vice versa?
Just a few followups. It doesn't seem to be related to the docking station switching. The problem occurs even without the docking port. Additionally, if I plug an HDMI cable into the laptop while the docking station is plugged in, the monitor is not detected at all. Where-as after I resume and have a problem, the monitor is detected, it just doesn't get sync. So the docking station switching disables the port "more" than the resume problem. - radeon.modeset=0 displays the same problem - vista-x32 works correctly
(In reply to comment #16) > Just a few followups. It doesn't seem to be related to the docking station > switching. The problem occurs even without the docking port. > > Additionally, if I plug an HDMI cable into the laptop while the docking station > is plugged in, the monitor is not detected at all. Where-as after I resume and > have a problem, the monitor is detected, it just doesn't get sync. So the > docking station switching disables the port "more" than the resume problem. This is consistent with the gpio controlled data and ddc routing that I suspect is happening. There's probably a small mux which routes the ddc/hdp lines (for detection and edid) and the data lines (for the actual video signal) between the HDMI port on the laptop and the DVI port on the docking station. When you dock, the acpi docking method probably calls some other method which switches the mux to the other connector. The same thing probably happens on undock. The question is, is this handled by an acpi method or some platform specific gpio/i2c setup. Newer radeon-based laptops that use a mux like this have a special entry in the vbios object table that describes the mux. Unfortunately, your system doesn't have this, so it's probably some system-specific configuration. When you suspend, the mux loses power and goes into some undefined state on resume the signals are not routed correctly since the mux state is wrong.
Just some notes: Power: Maxim MAX1999 Quad-ouput main power supply controller Maxim MAX8774GTL+ main power supply controller Semtech SC470 synchronous buck controller Semtech SC488 complete DDR memory power supply Nat Semi LM393 dual comparators. Chipset: ATI IXP460 SB460 ATI XPRESS RX485 ATX X1600 Broadcom BCM5788 MKFBG Netlink gigabit Ethernet controller with phy ICS ICS951462AGLF Programmable system clock chip for ATI RS/RD690 - K8 based systems Cypress CY25819 spread spectrum clock generator Super IO: Nat Semi PC87541V-VPC (Seems to be PC87591) LPC Mobile Embedded Controller Nat Semi PC87383-VS Legacy reduced super I/O Video: TI TS3DV520 5-Channel differential 10:20 multiplexer switch for DVI/HDMI applications (Single pin SEL signal) (x2) California Micro Devices CM1213 4-channel low capacitance ESD protection arrays California Micro Devices CM2009 VGA port companion circuit Silicon Image Sil1930CMU TDMS ParallelLink uC: Atmel AT89C51ICS-VL 8-bit flash microcontroller with 2-wire interface Misc: TI SN74CBT3257 4-bit 1-of-2 FET multiplexer/demultiplexer (I2C?) Maxim MAX3892 10/100/1000 base-T ethernet LAN switch Global Mixed-mode Technology Inc G528 USB high-side switch Microchip 24LC08BI 8K I2C serial EEPROM Toshiba 7W125 dual bus buffer Audio: Realtek ALC833 Value 7.1+2 HD audio codec AKM AK4113VF 192kHz 24bit DIR with 6:1 selector Maxim 9710E 3W Mono/Steria BTL audio power amps
Created attachment 43178 [details] DSDT
Russ Dill, Ubuntu Natty Narwhal reached EOL on October 28, 2012. For more on this, please see https://wiki.ubuntu.com/Releases. If this is reproducible with a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal: ubuntu-bug xorg Also, please feel free to subscribe me to it. For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.
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.