Mailinglist Archive: radeonhd (529 mails)

[Coleman Kane <cokane@xxxxxxxxxx>]

Kirill Belokurov wrote:
> 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)
>
>   
Ah I forgot that Linux requires explicit -lm. I'm using FreeBSD w/ GCC
4.2.1.
> > 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
>   
Attached a new patch... try this one with only adding LIBS="-lm" and not
chagning the CFLAGS. The default standard used by your compiler should
include C99 as well as other extensions.

--
Coleman Kane

--- src/rhd_monitor.c.orig      2007-12-01 16:26:14.000000000 -0500
+++ src/rhd_monitor.c   2007-12-01 19:12:37.000000000 -0500
@@ -44,6 +44,7 @@
 #ifndef _XF86_ANSIC_H
 #include <strings.h>
 #endif
+#include <math.h>
 
 /* From rhd_edid.c */
 void RHDMonitorEDIDSet(struct rhdMonitor *Monitor, xf86MonPtr EDID);
@@ -56,7 +57,7 @@
 {
     int i;
 
-    xf86Msg(X_NONE, "    Bandwidth: %dMHz\n", Monitor->Bandwidth / 1000);
+    xf86Msg(X_NONE, "    Bandwidth: %0.2fMHz\n", lrintf(Monitor->Bandwidth) / 
1000.0F);
     xf86Msg(X_NONE, "    Horizontal timing:\n");
     for (i = 0; i < Monitor->numHSync; i++)
        xf86Msg(X_NONE, "        %3.1f - %3.1fkHz\n",  Monitor->HSync[i].lo,