Bug 210923

Could you attach /var/log/SaX.log after configuring (without the test!) with
"sax2 -V 0:1280x1024@60"? Thanks.

Created attachment 100949 [details]
/var/log/SaX.log

SaX log starting with "sax2 -V 0:1280x1024@60"
I accepted the SaX configuration without making any changes, and X did come up afterward with "init 5", but not all of the screen was visible in the vertical direction (KDE and GNOME panels on the bottom mostly hidden, even after pressing the auto adjust button on the monitor).

I didn't mention it in the original report, but this combination of hardware works fine in 10.1.

Well, looks like you have a notebook and the internal display is autodetected by the driver (1400x1050). Did you check the dualhead button in SaX2 to make sure the internal and external display is used?

No, it's a Dell OptiPlex GX260.  The monitor was correctly detected as a Benq FP731.  The monitor's spec sheet says 1280x1024.

I just updated the radeon driver for openSUSE 10.2. Please test again with Beta1. Thanks.

openSUSE 10.2 Beta1 has just been released.

Same symptom in beta 1 (monitor shows "No signal detected").

Could you attach /etc/X11/xorg.conf and /var/log/Xorg.0.log for Beta1? Thanks.

Created attachment 102931 [details]
requested files tarred/gzipped

Hmm. This is still the fbdev configuration from the installation. Can't you create a real one with SaX2? If it's not possible, try again "sax2 -V 0:1280x1024@60".

Created attachment 102937 [details]
same files after running SaX manually

As before, SaX2 won't start from runlevel 3 without using "sax2 -V 0:1280x1024@60", and I couldn't come up with a workable configuration except to leave the initial suggestion as is.  The results are the same as in comment #2.

Reverting from NEEDINFO to ASSIGNED.

> (**) RADEON(0):  Default mode "1400x1050": 122.0 MHz, 64.9 kHz, 60.0 Hz
Is this the correct size of your monitor? What's the official resolution of your monitor?

The monitor specs are:
maximum resolution: 1280x1024
maximum refresh rate: 75Hz
horizontal frequency: 31-81 kHz
vertical frequency: 56-76 Hz
Also, it is a 17" monitor, but YaST says 15".

The drivers seems to make very strange assumptions. I have no idea, why it configures a 1400x1050 resolution, when only a 1280x1024 resolution is specified in config file. You could try to remove all the modelines in Modes section of /etc/X11/xorg.conf, but I doubt that this would help. :-(

Yes, I suppose I could edit the X config file by hand the way we did 10 years ago, but what concerns me about this issue is the fact that this combination of hardware works fine with SUSE 10.1.

> Yes, I suppose I could edit the X config file by hand ...
This is only for testing purposes.

Amazingly, that worked:

97,100c97,100
<   Modeline    "1280x1024" 24.09 1280 1248 1368 1456 1024 1025 1028 1034
<   Modeline    "1152x864" 24.40 1152 1136 1240 1328 864 865 868 875
<   Modeline    "1024x768" 24.34 1024 1016 1112 1200 768 769 772 780
<   Modeline    "800x600" 24.61 800 808 888 976 600 601 604 615
---
> #  Modeline   "1280x1024" 24.09 1280 1248 1368 1456 1024 1025 1028 1034
> #  Modeline   "1152x864" 24.40 1152 1136 1240 1328 864 865 868 875
> #  Modeline   "1024x768" 24.34 1024 1016 1112 1200 768 769 772 780
> #  Modeline   "800x600" 24.61 800 808 888 976 600 601 604 615

I now have a usable display with the entire screen showing :)

Indeed, the modelines are completely bogus. 24 Mhz pixelclock ?!? Marcus?

Hmm, don't know why this happens. Is there a way for me to reproduce this
... ssh login ?

anyway if you can reproduce the wrong configuration by calling

   init 3
   cp /etc/X11/xorg.conf /etc/X11/xorg.conf.working
   sax2 -r -a

   ---> send the /var/log/SaX.log file

this would help as well

Created attachment 103009 [details]
/var/log/SaX.log after starting in runlevel 3 and running "sax2 -r -a"

Marcus, does this help?

yes, your monitor reports wrong DDC values. I don't know what other distribution
do but we care for the data of the monitor. In your case it is more than wrong:

  standard DDC said your display is: 1280x1024 is this correct ?
  enhanced DDC timing said:
 
     	Card0     =>  Dacspeed[2]: 25
	Card0     =>  Modeline   :  640  656  752  800  350  387  389  449 -/+
	Card0     =>  Modeline[2]:  640  656  752  800  350  387  389  449 -/+

  which is completely wrong and the cause for the "wrong" modelines.
  These timings say your monitor can do 640x350 at a maximum bandwidth of
  25Mhz. 

Maybe the following patch makes sense. But I cannot test it here because I
don't have that bad hardware ;)

Stefan what do you think ?

Index: lib/hw/monitor.c
===================================================================
--- lib/hw/monitor.c    (revision 1222)
+++ lib/hw/monitor.c    (working copy)
@@ -112,8 +112,10 @@
                for(di = di0, i = 0; di; di = di->next, i++) {
                if (di->any.type == di_display) {
                        if (di->display.bandwidth) {
+                       if (di->display.bandwidth >= 100) {
                                display->bandwidth = di->display.bandwidth;
                        }
+                       }
                        if (di->display.max_hsync) {
                                display->hsync_max = (int)di->display.max_hsync;
                        }
@@ -124,7 +126,7 @@
                                bestX = di->display.width;
                                bestY = di->display.height;
                        }
-                       if (di->display.hdisp) {
+                       if ((di->display.hdisp) && (display->bandwidth)) {
                                sprintf (display->modeline,
                                "%4u %4u %4u %4u %4u %4u %4u %4u %c/%c",
                                        di->display.hdisp,

What's the fallback, when di->display.bandwidth < 100? Maybe we can detect the monitor instead and use vald values instead?

> Maybe we can detect the monitor instead and use vald values instead?
See comment #14.

if no bandwidth is available the clock is calculated from the given
standard DDC information. This means the enhanced data is simply not used
and the hsync/vsync range decides for the bunch of modelines and the
clock used. For this example everything should work because the
standard data is correct (1280x1024) and the hsync/vsync values fits

but as I already said I cannot test this without having access to the
broken data. 

In reply to comment #4:
default values are only needed if the complete record is broken. Which
means the resolution information AND the hsnyc/vsync information is wrong.
In such a case we overwrite the values according to the DDC-ID with the correct
specs. This is not needed in your case because some of the data are pretty well 

Ok. Marcus, could you rebuild SaX2 and atttach the RPM for testing?

I checked it into openSuSE. once the package has built you can refer to

  http://ftp.opensuse.org/pub/opensuse/repositories/SaX2/SL10.2

status:

SL10.2          x86_64     building
SL10.2          i586       building

Glenn, please check these packages one they have a date of Oct 30.

(In reply to comment #23)
>   These timings say your monitor can do 640x350 at a maximum bandwidth of
>   25Mhz. 
> 
> Maybe the following patch makes sense. But I cannot test it here because I
> don't have that bad hardware ;)

Marcus, don't test for bandwidth, that could always involve some arbitrary value that seems to fall from the stars. A monitor with maximum resolution 1024x768 in 60Hz (they still exist) e.g. has a maximum bandwidth of 60MHz.

What would make more sense is to calculate the refresh frequency, and if it is out of bounds of the DDC spec to ignore the maximum bandwidth (which I have been told is often wrong). I have a monitor here that works only with special options in its optimal resolution, even with the NVIDIA driver, due to the same issue.

I'm sorry I have to test for the bandwidth and the mode timings of the
enhanced DDC specs. There are so many devices which works only with the
timings given in that record. Think about this crappy Philips Monitor
the company bought and spreads over the world. Yes it's cheap hardware and
it's crap.

- what you suggested is done that way. The problem here is that the
  bandwidth is ok for a resolution of 640x350 but why are there timings
  for this resolution it doesn't make sense. According to the standard
  the timings and bandwidth data must correspond to the preferred resolution
  of the device which is somethng the vendor decides. I'm pretty sure 640x350
  doesn't correspond to 1280x1024. Is this my fault no it isn't. So what
  makes sense ? accept timings for the maximum resolution only but
  this will work on TFT's only and is still buggy if the vendor doesn't
  take care for its data. I think any workaround we can add here has race
  conditions
 
- if you have such a special monitor you could tell me the options to be
  able to store them in sax ;)

I installed the following RPMs:

sax2-8.1-126.1.i586.rpm
sax2-gui-8.1-126.1.i586.rpm
sax2-ident-8.1-126.1.i586.rpm
sax2-libsax-8.1-126.1.i586.rpm
sax2-libsax-perl-8.1-126.1.i586.rpm
sax2-tools-8.1-126.1.i586.rpm

But I get the following error seven times: "ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.". Then he proceeds, but gives up with "xc: sorry could not satrt configuration server". Did I miss an RPM somewhere?

Attaching /var/log/SaX.log.

Created attachment 103159 [details]
see comment #32

Reassigning to Marcus.

Comment #32 was from sax2 in runlevel 3. I think the errors may be because I moved  xorg.conf out of the way before starting.  If I come to runlevel 5 using the xorg.conf like in comment #18, then start yast2 "Hardware / Graphics Card and Monitor", I can get a successful configuration, although sax2 will still not start from runlevel 3 afterwards. Let me know if you want any additional logs.

you have the binary only fglrx driver installed:

  (II) LoadModule: "fglrx"
	(II) Loading /usr/lib/xorg/modules/drivers//fglrx_drv.so
	(II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
	compiled for 7.1.0, module version = 8.28.8
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 1.0
	[R200Setup] X version mismatch - detected X.org 7.2.-1.2, required X.org 7.1.0.0
   (II) UnloadModule: "fglrx"
   (EE) No devices detected 

It seems your installation is broken

Indeed. Could you uninstall this driver? It cannot work on openSUSE 10.2. Thanks.

You are right, I had tried something else out of desperation :)  I did a clean install from the beta1 DVD.  After network setup, the installer went right to a KDM login.  I dropped back to runlevel 3 and installed the RPMs listed above, then rebooted.  The installer came up and asked if I wanted to continue; this time I was able to configure the monitor without any problems. It's beautiful!  Thank you so much!

Thanks for testing again. Reassigning to Marcus (again) to add the workaround to SaX2 and close this bugreport afterwards.

done :-)