Summary: | Radeon HD 2400 Pro -- Monitor not detected | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Peter <peter> | ||||||||||||
Component: | Driver/radeonhd | Assignee: | Luc Verhaegen <lverhaegen> | ||||||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||
Severity: | normal | ||||||||||||||
Priority: | medium | ||||||||||||||
Version: | 7.3 (2007.09) | ||||||||||||||
Hardware: | x86 (IA32) | ||||||||||||||
OS: | Linux (All) | ||||||||||||||
Whiteboard: | |||||||||||||||
i915 platform: | i915 features: | ||||||||||||||
Attachments: |
|
Description
Peter
2008-07-11 04:41:18 UTC
Created attachment 17643 [details]
rhd_conntest output
This is the output from rhd_conntest output for every connection type...
Peter: Could you also attach your X.Org log file, please? Created attachment 17662 [details]
Xorg.0.log with hpd=OFF
Yes, this is another example of a broken connector table. HPD on the DVI connector should be 2 - not 0. (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_VGA, "VGA CRT1", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_DVI_SINGLE, "HDMI_TYPE_A DFP1", RHD_DDC_1, RHD_HPD_NONE /*0*/, { RHD_OUTPUT_TMDSA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_PANEL, "LVDS LCD1", RHD_DDC_2, RHD_HPD_NONE, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[3] {RHD_CONNECTOR_TV, "7PIN_DIN TV1", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } } I'm probably going to add a hand made table to the black list. Also the BIOS reports the DVI connector to be an HDMI type A connector. Is there any sign of an HDMI connector on the board? If so have you tried using this one (with an adaptor) to see if it works? Yes, the Samsung X22 has a HDMI Output Connector. And it is working fine. It's the same output/resolution thats on the PANEL. You connect the cable - and you have the output. Not even a restart of the xserver is required. I'm not using any adapter as I have a beamer with HDMI input. But I think xrandr doesn't see the HDMI output connector as its not in the list: .... VGA_1 disconnected DVI-D_1 connected 1280x800+0+0 0mm x 0mm 1280x800 60.0* 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 PANEL connected 1280x800+0+0 303mm x 190mm 1280x800 60.0*+ 60.0 1440x960Scaled 60.4 1280x1024Scaled 60.5 1280x960Scaled 60.4 1280x854Scaled 60.4 1280x768 60.0 1280x720Scaled 60.4 1152x768Scaled 60.3 1024x768 60.0 1024x768Scaled 60.4 800x600 60.3 800x600Scaled 60.3 768x576Scaled 60.4 854x480Scaled 59.8 720x480Scaled 59.8 640x480 59.9 640x480Scaled 60.1 320x240Scaled 57.6 320x200Scaled 55.7 TV_7PIN_DIN disconnected The TV-Output is on the X-Dock, and I'm unable to test it at the moment, as the Docking Station is at work. (In reply to comment #5) > > But I think xrandr doesn't see the HDMI output connector as its not in the > list: The DVI-D 1 is actually your HDMI connector. The docking station DVI (using DDC line 2) is not listed in the connector table. > .... > VGA_1 disconnected > DVI-D_1 connected 1280x800+0+0 0mm x 0mm > 1280x800 60.0* > 1280x768 60.0 > 1024x768 60.0 > 800x600 60.3 > 640x480 59.9 > > The TV-Output is on the X-Dock, and I'm unable to test it at the moment, as the > Docking Station is at work. > TV out is irrelevant at the moment, let's concentrate on the digital outputs: I need to find out where I can find information on the connectors of the docking station. Could you please run three tests for me? 1. Without the docking station connect a monitor to the HDMI connector and run rhd_conntest. 2. use rhd_conntest <pci_id> -d to dump your video BIOS for me and attach it here. 3. before starting the Xserver place the laptop into the docking station, start X with '-logverbose 7' and send me the output please. (In reply to comment #6) > The DVI-D 1 is actually your HDMI connector. The docking station DVI (using DDC > line 2) is not listed in the connector table. Meant to say HPD pin 2. The HDMI port seem to share the TMDSA controller and DDC line 1 with the DVI connector on the doc while the DVI connector uses HPD 2 while the HDMI connector (according to AtomBIOS) uses HPD 0. I would like to verify the latter. Created attachment 17779 [details]
VideoBios
Created attachment 17780 [details]
Log from "X -logverbose 7"
Ok, I did point 2 and 3, the first one will come later. By doing your steps I run into an other issue: sometimes the console will not recovered (using the docking station). I did not much tests, as I have to shutdown the laptop every time, the console stays black after quitting the XServer. So, after doing the X -logverbose 7, (all three outputs Panel, vga, dvi show the same) and a CTRL-C the console is not recovered. But in normal work I do a xrandr --output PANEL --off xrandr --output VGA_1 --left-of DVI-D_1 And then the console will be recovered after finishing the session, sometimes at least. But I can't switch to the text mode with ALT-F1 (get a black screen), going back to graphic mode with ALT-F7 works ok. But maybe this is a different issue. Should I open a new bug? Or has anyone a starting point in the source, where I can have a look whats going on? (In reply to comment #10) > Ok, I did point 2 and 3, the first one will come later. I think I've found the issue why you need HPD_OFF. I will attach a (tiny) patch later. > > So, after doing the X -logverbose 7, (all three outputs Panel, vga, dvi > show the same) and a CTRL-C the console is not recovered. > > But in normal work I do a > xrandr --output PANEL --off > xrandr --output VGA_1 --left-of DVI-D_1 > This sounds very much like a pll assignment issue again. Luc has investigated those before. The main issue here seems to be that the panel is off. then the VGA_1 and crtc share the same CRTC while the second CRTC is off. I assume it works better if you only start with the panel and becomes flakey once you connect the DVI or the VGA (ie it doesn't have to be both)? > Or has anyone a starting point in the source, where I can have a look whats > going on? That's indeed tricky. Let's first sort out when the problem occurs. In your case there are quite a few different scenarios to compare. Created attachment 17802 [details] [review] Increase the number of available connectors. Super! Your small patch (+current git) solves the initial problem with the detection of the DVI-Output!. The monitor will be detected, without the Option "HPD" "OFF". Now xrandr found the 2. DVI-output. ... VGA_1 disconnected DVI-D_1 disconnected PANEL connected 1280x800+0+0 303mm x 190mm ... TV_7PIN_DIN disconnected DVI-D_2 connected 1280x800+0+0 338mm x 271mm .... The other issue (recovery of the text mode): The problem occurs as soon as a monitor is connected to the VGA-Output. (no matter if its the output on the docking station or the one on the laptop). At the moment only the DVI-Output is used (and the panel) and I can switch to the text mode. (In reply to comment #13) > Super! > > Your small patch (+current git) solves the initial problem with the detection > of the DVI-Output!. > The monitor will be detected, without the Option "HPD" "OFF". > Now xrandr found the 2. DVI-output. > > ... > VGA_1 disconnected > DVI-D_1 disconnected > PANEL connected 1280x800+0+0 303mm x 190mm > ... > TV_7PIN_DIN disconnected > DVI-D_2 connected 1280x800+0+0 338mm x 271mm > .... > > > The other issue (recovery of the text mode): > The problem occurs as soon as a monitor is connected to the VGA-Output. > (no matter if its the output on the docking station or the one on the laptop). no its not that easy. Currently I'm using VGA and DVI output, PANEL is off. And I can switch to text mode. Yesterday (without the patch or/and latest git, this was not working) So it must be an error if both is activated VGA and PANEL. > > At the moment only the DVI-Output is used (and the panel) and I can switch to > the text mode. > Peter, thanks for your report! So basically when you start up with DVI+PANEL you can restore text mode but when you start with VGA+PANEL the vt restore doesn't work. Does this sum up your experience? (In reply to comment #15) > Peter, thanks for your report! > So basically when you start up with DVI+PANEL you can restore text mode but > when you start with VGA+PANEL the vt restore doesn't work. Does this sum up > your experience? > Now I was testing a bit, but its strange behavior. First and important: Its never working if PANAL and VGA_1 is connected, thats true. if only VGA and DVI_2 connected, then it works, but sometimes only after a second try. That means you have to switch to the console and back to graphic and back to console - and now there is it working. If it is not working, and I switch back from the (black) text mode to graphich I see the text mode output on the top of the graphic output, but only for point of time. This is not the case, if its working correctly. All in all the behavior seems not reproducible, maybe it depends on the previous mode. Btw: I'm not able to compile the latest git. Even after a make distclean I get a r5xx_xaa.c:132: error: ‘struct RHDRec’ has no member named ‘TwoDPrivate’ and so on. I start my IRC, if there are more information needet. (In reply to comment #16) r5xx_xaa.c:132: error: ‘struct RHDRec’ has no member named > ‘TwoDPrivate’ > and so on. > > I start my IRC, if there are more information needet. > Peter, you need to do a fresh build. I ususally do a make distclean; autogen.sh; make This assures that everything is build afresh. There have been changes to the Makefile.ams so the Makefiles also need to change. I will get to your other issues later. Peter, could you please start a 'bare' Xserver and see if your outputs also don't light up? We have seen several incidences where desktop helpers have taken over and disabled outputs while the user was thinking the driver was at fault. You can start the Xserver by doing 'X' on the text console command line. (In reply to comment #18) > Peter, could you please start a 'bare' Xserver and see if your outputs also > don't light up? We have seen several incidences where desktop helpers have > taken over and disabled outputs while the user was thinking the driver was at > fault. > You can start the Xserver by doing 'X' on the text console command line. > (In reply to comment #18) > Peter, could you please start a 'bare' Xserver and see if your outputs also > don't light up? We have seen several incidences where desktop helpers have > taken over and disabled outputs while the user was thinking the driver was at > fault. > You can start the Xserver by doing 'X' on the text console command line. > Using the plain X command everything works fine. All test monitor combination switch back to the text mode without trouble. Looking at the log-file: there was only one difference: If I use an exernal Monitor (dvi or vga) I got this message: ... (EE) RADEONHD(0): TMDSAVoltageControl: unhandled chipset: 0x94C9. ... Thanks, Peter As the initial problem is solved (at least in git), I close this bug. Thanks for fixing this issue! I have this problem with my Radeon 2400 Pro, using the current git version -- 4bba1163. Adding Option "HDP" "off" fixes it. However, I have a problem with my screen flickering black repeatedly, when I run with this git version of radeonhd with Option "HDP" "off". I have the same problem with the radeonhd driver 1.1.0 that comes with Ubuntu Hardy and with the radeon driver, and also occasionally when in text mode, when not using any X driver at all. :-( Oh by the way I'm on amd64. (In reply to comment #21) > I have this problem with my Radeon 2400 Pro, using the current git version -- > 4bba1163. > > Adding Option "HDP" "off" fixes it. Give me your PCI ID so I can add it to the blacklist. > > However, I have a problem with my screen flickering black repeatedly, when I > run with this git version of radeonhd with Option "HDP" "off". I have the same > problem with the radeonhd driver 1.1.0 that comes with Ubuntu Hardy and with > the radeon driver, and also occasionally when in text mode, when not using any > X driver at all. :-( > So this is not a driver bug. Could be that your monitor is extremely picky regarding the signal quality or your cable is bad. In any case neither problem have anything to do with the original bug. (In reply to comment #23) > (In reply to comment #21) > > I have this problem with my Radeon 2400 Pro, using the current git version -- > > 4bba1163. > > > > Adding Option "HDP" "off" fixes it. > > Give me your PCI ID so I can add it to the blacklist. 02:00.0 VGA compatible controller: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] Subsystem: VISIONTEK Device 3210 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 7 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at f9000000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at 9000 [size=256] [virtual] Expansion ROM at f8000000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 |
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.