On Saturday 01 December 2007, Coleman Kane wrote:
>> Please find it in the attachment. For the record, below is the >> rhd_conntest output when I was dumping it (TFT monitor was >> disconnected this time): > > Should be fixed in git now.
No, unfortunately this didn't resolve the issue: the error mesage from the
Can you verify that this issue happens with Option "NoRandr" as well? It probably will. If everything works you should see an image on all connected monitors including panel.
Unfortunately, with "noRandr" it is broken even worser: the Xorg simply doesn't start at all:
(EE) RADEONHD(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration.
apparently, there is some issue with rejected panel modes: (II) RADEONHD(0): Rejected mode "1440x900" (1440x900:88.8Mhz): mode clock too high
I am attaching the Xorg log for this case.
Regards, Kirill
It looks like the mode that your system tries to set up requires 88.8MHz display bandwidth, however the panel seems to report that it's max is 88MHz (interpreted as 88.0MHz I assume) meaning that your monitor is telling X that the mode that it gave to X is out-of-range. It looks like a truncation problem to me... I wonder where this is occurring.
-- Coleman Kane
Apply the attached patch to your latest radeonhd sources, rebuild, reinstall, re-run X, and re-send the log. This patch attempts to undo that incidental truncation that happens around line 60 of src/rhd_monitor.c.
Patched, but I am getting build failure when running make: ====================== rhd_monitor.c: In function 'RHDMonitorPrint': rhd_monitor.c:59: error: implicit declaration of function 'lrintf' rhd_monitor.c:59: warning: incompatible implicit declaration of built-in function 'lrintf' ====================== Setting CFLAGS to "-std=c99" and LIBS to "-lm" as suggested in 'man lrintf' gives compile errors in different place. My compiler is: gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Reviewing the source code a little further, the value displayed here is likely being pulled from the clock field of the EDID structure for your panel. This is an integer of whole megahertz value, in this case is 88. This is likely a bug in the panel by some naive code that originally wrote the EDID data and truncated 88.8 or 88.9 to 88MHz. I *think* the proper value should be 89.
I made few more tests and found that if I disconnect the external TFT monitor (which is not so big, just 1024x768) and start Xorg, it starts well: I have attached the logs for cases 'with/without DVI' so you can compare them. Keep in mind that it still works w/o the TFT monitor (only panel present), I suspect that this failure of Xorg to start is failed by the following: the only acceptable by the panel mode, which is 1440x900 88.75MHz has too high bandwidth which is not acceptable by TFT monitor (which according to Xorg log has bandwidth 80MHz), therefore the last possible mode is dropped and no modes remain available. Does it make sense? Separate question if this a good behavior: I would expect in this case from driver to stop trying to find the 'common mode' for panel and TFT and output at least to the panel so there will be at least one working device.
Does "IgnoreEDID" work in the driver code yet? Not sure about driver code, simple adding of this option line to the corresponding section of Xorg config didn't change the situation for the Panel+TFT configuration.
Best regards, Kirill