Please attach config and logfile.

Created attachment 48829 [details]
xorg.conf

Created attachment 48830 [details]
Xorg.0.log

Created attachment 48831 [details]
result of "hwinfo"

Here is the information you asked for. Unfortunately I forgot the value of the 
original screen resolution, but the effects were the same. I also commented 
out the mode-selection so the X server would try to find its own modeline, but 
that didn't change anything either. The log file and the config file I 
attached match. 

The monitor values look completely bogus. Try to adjust theme to the real ones 
and remove the   

  UseModes     "Modes[0]"

line as well.

The usemodes entry doesn't matter (as I mentioned too unprecisely above). I 
don't really know what sensible values for the monitor section are, so I 
changed them only slightly. Note that the Display size was detected correctly, 
so maybe the other values made sense too? 
I'll attach the new xorg.conf and Xorg.0.log 

Created attachment 48840 [details]
xorg.conf without modes

Created attachment 48841 [details]
Xorg.0.log without modes

Surely for a 1280x1024 TFT "HorizSync 30-40" is bogus. I would expect values    
similar to this: "HorizSync 30-70" and  "VertRefresh 60-70".  

Please try the values I mentioned above and attach the new logfile. Althout I 
don't think this will help ... 

The pysical resolution is 1280x800. 
Btw, the way it looks the backlight of the screen is off. Maybe that's the 
problem or maybe it's just a result of the server not working correctly? 
 
It looks like the xserver is not seeing a mode with the physical resolution 
of the display. 
 
As reqeusted the xorg.conf and Xorg.0.log files. 

Created attachment 48855 [details]
xorg.conf with better monitor values

Created attachment 48856 [details]
Xorg.0.log with better monitor values

*** Bug 113697 has been marked as a duplicate of this bug. ***

I think this is sth. for Matthias. Maybe we find a X700 Notebook for testing, 
but I don't think so ... 

I'm in no way knowledgable about X, so the following is pure 
<speculation>. 
Is there a way to further debug the way the X server retrieves the monitor  
information? Which information does it retrieve via DDC, which information 
from the video BIOS? Where do the Default modelines come from that are visible 
in the log? Why isn't there a line with 1280x800? 
</speculation> 

In case it is a problem with the values from the videobios: There is a tool 
for Intel 855G chipsets (855resolution) that "fixes" the values. 
Maybe the discussion on that tool's pages can shed some light? 
Startpage with better explanation: 
http://www.ubuntuusers.de/wiki/treiber:notebooks:855resolution 
Homepage: http://perso.wanadoo.fr/apoirier/ 

But this works only with Intel chipsets. BTW, I misread the bugreport. I 
thought it's a desktop machine with a "1280x1024" TFT. My fault. Of course 
you need a modeline for 1280x800, because the Xserver modeline pool only 
provides some Vesa modelines and 1280x800 seems to be missing there. Anyway 
I don't think it's a configuration problem. Probably the driver simply doesn't 
work and we need to use "fbdev" driver for this chipset as long as we don't 
have such a notebook for testing available. 

Actually you should try configuring X with 'sax2 -r' in runlevel 3.
Unfortunately sax isn't able to retrieve monitor information in runlevel 5.

Please try to run 'sax2 -r', and if you see an image, try to configure your
system to the best of your knowledge. Then try starting X again.

OK, lots of (unsuccessful) attempts later: 
sax2 -r in runlevel 3 (and everything else I tried) also results in a deep 
black screen (no backlight). Absolutely no change. ps shows that fvwm2 etc are 
running. 

Just like in bug #113697 it seems that the monitor does not accept general
timing formula modelines. I'll try to find that different formula again.

Please try the following ModeLine:

Modeline 	"1200x800@60-CVT" 49.7 1280 1352 1480 1680 800 803 809 831

This one has been calculated using the CVT, which is the appropriate timing
formula for panels.

I ran sax2 -r, copied the temporary file and then made the necessary changes 
manually. It didn't work. I'll attach xorg.conf and Xorg.0.log 

Created attachment 49189 [details]
xorg.conf with cvt modeline

Created attachment 49190 [details]
Xorg.0.log for CVT config

So it looks like the line doesn't match the monitor settings (timings). 

Created attachment 49194 [details]
Xorg.0.log after changing monitor config

I've changed the monitor config so the mode line will be accepted by the
Xserver at all. The behaviour hasn't changed though.

OUCH!

I'm sorry, the Modeline was wrong:

Modeline "1280x800@60-CVT" 83.5 1280 1352 1480 1680  800 803 809 831

This one should be correct. No wonder your monitor wouldn't like to show a
picture, it was driven with 35.6 Hz...

No, it didn't work either. I also tried a modeline I found in an internetforum  
which supposedly worked with the proprietary ATI driver, but it didn't work 
with the radeon drivers: 
Modeline     "1280x800@60"  83.91 1280 1312 1624 1656 800 816 824 841 
 
  

Btw, is there a "recommended" ATI driver version for 10.0 (or a suse rpm?). 

Could you please attach the logfile for the modeline in comment #29?

You can always use the vesa driver, of course (which appearantly worked during
installation), but you will loose all acceleration functions this way.

Other than that I'm out of ideas. Egbert, do you have any additional ideas?

For the binary only driver: you can always download the driver from ATI and
install it, but you won't be able to uninstall it easily. Maybe Stefan has news
about an installation script for the ATI driver.

Created attachment 49235 [details]
xorg with corrected modeline

Created attachment 49237 [details]
Xorg.0.log for corrected modeline

Yes, I'm using the vesa driver when I'm testing other stuff, but my goal is
that other users starting Suse on this type of Laptop will get a "just working"
experience instead of a "You have to press C-A-F1, login, vi
/etc/X11/xorg.conf...." experience :-)

An additional goodie would be a proper resolution of 1280x800 instead of 
800x600 :-) 

Some last additional ideas:

Try adding '-hsync +vsync' to the modeline. At least the CVT tells me to do so.
Never cared about syncs, because all monitors I know never cared as well.

I also have some additional modelines to try (including the idea above):

Modeline "1280x800-CVT"  83.5 1280 1352 1480 1680 800 803 809 831 -hsync +vsync
Modeline "1280x800-CVT-r"  71 1280 1328 1360 1440 800 803 809 823 +hsync -vsync
Modeline "1280x800-CVT-m"  89 1280 1352 1488 1696 800 803 809 832 -hsync +vsync
Modeline "1280x800-CVT-mr" 75 1280 1328 1360 1440 800 803 809 824 +hsync -vsync

Please check whether you have luck with *any* of them...
I'm not exactly sure about the modes with margin (m), because there is too
little documentation. But looking at the log files (the resulting vertical and
horizontal refresh rates) could help.

> Btw, is there a "recommended" ATI driver version for 10.0 (or a suse rpm?). 

http://www.novell.com/linux/suse/
http://www.novell.com/products/linuxprofessional/
http://www.novell.com/products/linuxprofessional/downloads/x11/index.html
ftp://ftp.suse.com/pub/suse/i386/supplementary/X/ATI/ati-installer-HOWTO.html

Created attachment 49258 [details]
xorg.conf plus 4 logs - 1 for each modeline

I've done the tests and none of them worked. I've attached all the logfiles but
only one configfile (I only replaced the modename to use for 24 bits).

Thanks a lot for testing!

Now I'm really out of ideas... Egbert, do you have any left?

Created attachment 49348 [details]
xorg.conf for ati-fglrx drivers generated by sax2

I've taken the time to install the proprietary fglrx drivers. I ran sax2 as
described in the ati documentation but this resulted in a non-working config
too. I needed to comment out the VertRefresh value for the X-Server to start.
Afterwards, I needed to manually add the "1280x800" resulution to the Display
SubSection. I'll also attach the output of Xorg.0.log with the proprietary
driver, maybe you get some ideas from it how to get the radeon driver working
for 2D.

Created attachment 49349 [details]
Xorg.0.log  with fglrx-driver

Did your config finnally work and gave you an image, or is the display still black?

The config attached in #41 plus the changes mentioned in #41 give me an image 
(with the fglrx drivers). I tried to use the modeline found in #42 with the  
radeon driver and it didn't give me an image. Playing with ignoreedid didn't 
help either. 
After adding glx and dri loads to the fglrx config, I even had working 
3d-accel ;-) 

If the modeline of comment #42 doesn't work, please add your finnally working
config, so that there are no ambiguities.

So this is the modeline that actually work:

Modeline "1280x800"   68.90  1280 1301 1333 1408  800 801 804 813 +csync

One last try: can you try this one with the radeon driver?
Maybe also one of the former ones with '+csync'?

Additionally: was the hwinfo in comment #4 created in runlevel 3? Because it
contains no usefull DDC information... Otherwise please attach the output of
'hwinfo --monitor', executed in runlevel 3.

 #45 and #46: 
The modeline is *NOT* part of the config - it is learned via EDID (if I'm 
notmistaken). Just look a few lines higher. Also, I tried exactly that line 
with the radeon driver already and it didn't work (that's what I meant with my 
comment in #44). 
 
#46: 
I'll try the other modelines with +csync soon. 
 
#46 The hwinfo was created in runlevel 3 (and without X running or trying to 
run). 

Created attachment 49439 [details]
modelines with +csync, radeon driver

OK, here's the test of the modelines for the radeon driver with +csync. None of
them worked.

I have fixed this issue. The problem, as I stated in 113697, is in the X.org
radeon driver. I have obtained 1680x1050 resolution on my Gateway M680/X700
Mobility using the ATI driver fglrx_6_8_0-8.16.20.i386.rpm. As proof I have a
screen capture of my system running properly at
http://www.geocities.com/bill_beebe/suse10/gateway-screenshot.png

The key to fixing this problem is to essentially ignore sax2 and use fglrxconfig
to create a new xorg.conf. The key is in the screen section. When asked for
resolutions, make sure to enter a screen resolution for 1680x1050. The screen
section of your new xorg.conf should look like the following:

# **********************************************************************
# Screen sections
# **********************************************************************

# Any number of screen sections may be present.  Each describes
# the configuration of a single screen.  A single specific screen section
# may be specified from the X server command line with the "-screen"
# option.
Section "Screen"
    Identifier  "Screen0"
    Device      "ATI Graphics Adapter"
    Monitor     "Monitor0"
    DefaultDepth 24
    #Option "backingstore"

    Subsection "Display"
        Depth       24
        Modes       "1680x1050" "1280x1024" "1280x960" "1152x864" "1024x768"
"800x600"
        ViewPort    0 0  # initial origin if mode is smaller than desktop
#        Virtual     1280 1024
    EndSubsection
EndSection

If you've already got a working xorg.conf from an earlier run but without the
highest resolution, then add the new mode for 1680x1050 as shown. Reboot the
notebook, and your new resolution will be operational. Note that if you change
the kernel (via yast or by building your own) that you'll need to reinstall the
ATI kernel driver.

Editorial comments

The handling of this issue has turned out to be very disappointing. I've never
seen a lower bug (113697, mine) marked as a dupe to a higher bug (this one).
It's always been the other way around. I've never seen more conflicting advice
given out, or seen someone put up with as many wrong suggestions as George Mayer
did.

I solved this problem by talking to local people in Orlando, FL, who seemed to
be knowledgable about the ATI hardware and the various drivers. I tested this
solution first on another system I own that has an ATI 9600. I increased its
screen resolution to 1600x1200 using the fglrx driver. That screen resolution
was actually "found" by Ubuntu breezy (5.10), which seemed to find and use that
resolution with its radeon driver. SuSE 10 RC1 does not. When I hand modified
the xorg.conf for the ATI 9600 to 1600x1200 and found that it worked, I was then
confident enough to try the same experiment with my Gateway notebook. And, of
course, it worked as well.

1st) Jörg got a working fglrx configuration as in comment #41. But thanks for
     your additional input, so we have confirmed this is not a single laptop
     issue.
2nd) Bugs are marked as dups in order to close bugs with less input in order to
     concentrate information. Closing bugs as duplicates is not to insult
     anyone, but just a necessary work flow management. Which way the bugs are
     combined should be irrelevant to reporters, but is important for our
     workflow.
3rd) We have so many conflicting advices, because we do not have the hardware
     to reproduce the problem, so this is somehow flying blind. I could have
     CLOSED WONTFIX this one, but I want to give as much advise as I'm able to.
4th) Jörg Mayer is not related to SuSE, no need to insult him.
     He also did an extremely professional job in his checks.
5th) This bug report was about the open source driver, not about fglrx. If
     these drivers help, fine, but we cannot support them. What I'm more
     concerned with is that the open source drivers don't work.
     This is actually the first time I know that the open source drivers don't
     work but the fglrx drivers do.
6th) Who's 'George Mayer' anyway?

This bug is not yet closed for us.

Marcus, I've added you to this bug, because in addition to the non-working
driver sax2 (or hwinfo --monitor) doesn't detect the monitor correctly, while
the fglrx driver appearantly does.

Do you have any ideas what's going on there?

So currently the non-working configuration seems to be X700 only related.

William, as you seem to have tested Ubuntu as well, did the radeon driver work
in their distribution? Or was this on the ATI 9600? Additionally, did any other
than the native resolution work with the fglrx driver on the laptop?

(In reply to comment #50)
> 5th) This bug report was about the open source driver, not about fglrx. If
>      these drivers help, fine, but we cannot support them. What I'm more
>      concerned with is that the open source drivers don't work.
>      This is actually the first time I know that the open source drivers don't
>      work but the fglrx drivers do.
In bug 73092 it's similar, radeon does not work, but fglrx does.

It's different, because in this bug the machine locks up (while here it 'only'
does not display a valid screen).
But I agree that the radeon driver is currently in a bad shape WRT the modern
cards like X600 and X700.

Created attachment 49796 [details]
New CVS radeon driver

Please test this driver (replace the one in /usr/X11R6/lib/modules/drivers/
after backing it up).

Maybe the problem has been fixed upstream, some other problems have
definitively been fixed.

I have tried it on my asus(ati 9700 lcd 1280x800) and the problem(conly
corruption) is still there.
Do you need/wont more information? 

The problem is in rc1, b4, b3.... and 9.3 ;)

Sorry for the delay: I was on a business trip and had to return the laptop to 
its owner. But until the end of the week I've now both, time and laptop so 
it's time to play some more ;-) 
I've tried the new radeon driver from comment 54 and tried all the modelines 
again: No luck, the problem hasn't changed a bit. 

I was on a conference as well :]
Unfortunately, there hasn't been exactly much traffic on Xorg bugzilla #1559 as
well :-(

For radeon display detection there exists a patch collection ('radeon
superpatch') which I'll compile tomorrow and attach here for testing.

*** Bug 118956 has been marked as a duplicate of this bug. ***

Tried the radeon superpatch. Unfortenately, it crashed hard (no ping) all
systems I tested it on, so I cannot really suggest trying it.

If we get better relations with ATI, we can try to debug these issues in the
mid-term future. But without having a reproduction of the bug in house, this is
almost impossible as well.

Sorry, folks, have to suggest using the binary only driver from ATI, if this
helps you.

Closing this as LATER. Currently we cannot do anything for it.

Same problem with 10.1 beta 8. A solution could be find for this new release ?

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED.

In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(