Dieter, On Jan 02, 06 18:21:34 +0100, Dieter Jurzitza wrote:
sax2 -r -m 0=firegl -b /usr/share/doc/packages/fglrx/sax2-profile
It should read sax2 -r -m 0=fglrx Nothing more. please take a look into /usr/share/doc/packages/firegl/README.SuSE as extracted from the latest ATI driver package (8.20.8, similar on older ones). I cite:
************************************************************************* ATI fglrx driver configuration (including 3D support) -----------------------------------------------------
Switch to runlevel 3 ("init 3") and use the following command as user "root" to configure the ATI fglrx driver (including 3D support).
sax2 -r -m 0=fglrx -b /usr/share/doc/packages/fglrx/sax2-profile
On (open)SUSE 10.1 (Alpha) or later it's no longer required to specify the profile, so use "sax2 -r -m 0=fglrx" instead. *************************************************************************
since I explicitly denoted that I am using SuSE 9.3 I cannot know about your suggestion. The doc references SuSE 10.1 which is - to all my knowledge - experimental. README.SuSE should be the reference, shouldn't it? So, please recheck with ATI on this if the README.SuSE is not in tune with what SuSE recommends.
Ok, sorry that I overread the 9.3 thing. In any case, it should read '-m 0=fglrx', not '-m 0=firegl'. In that case with the new ATI drivers the easiest thing is to use the command line given in the README.SuSE and delete all entries from the Modeline section (or better: the 'UseModes "Modes[0]" in the Monitor section) after configuration by hand (Do not 'test' the configuration, as this will crash the driver as well). Sorry, ATI had been notified about that severe bug well ahead of publication of their drivers (in fact, as soon as we stumbled upon it), but appearantly it hasn't been fixed. This is AFAIK nothing that can be easily changed with profiles, but maybe Marcus can comment on that.
is exactly what SuSE recommends for configuration - if this does not work, it should be considered a bug, isn't it?
It is a bug, not of our configuration system, but in the ATI drivers.
The thing you are experiencing is a bug in the fglrx driver. OpenSUSE bugzilla #115281. SL10.0 should work by not including any modelines.
I am listening to the xfree-mailing list for a while now, but I haven't seen any commentary there saying, "hey, if you run into this or that trouble, try this ...". Maybe some readme's with options what and how to test would be helpful, too.
If you havn't seen any tipps, then this might indicate that it just (TM) works (TM)? ;)
Hmmm. Not so sure about this. I have three computers with three different ATI cards (Radeon 9600XT, Radeon 8500, Radeon 9200) from two different vendors all showing the same effect and I am the dummy? No, cannot think so. Maybe this is an issue of large monitors, as Curtis mentioned in his mail, too. I am using montitors like Elsa Ecomo 750 and large HP displays, the maximum (and "working") resolution setting is 1600x1200.
In fact it is. If you read the bugzilla entry you will notice the 'when too many ModeLines are present' - which only happens for large resolutions and/or high refresh rates.
Since my OS is not an Opensuse OS I did not search within the Opensuse bug tracking data base - maybe that was wrong.
Actually, there is no OpenSUSE bugzilla - it's all in the Novell bugzilla now. Therefore all SUSE products are there as well.
Where did you actually get the command line from?
See above. It stems from the README.SuSE that is being installed by the ATI driver.
Thanks. I think the docs are actually ok.
So, thanks for your commentary, but I am still convinced that there is a need for some apropriate documentation. Even more if there are differences between your suggestions and what is being written down in a README.SuSE distributed with the software. Putting modelines into a file with dotclocks of more than 0.4 GHz is questionable at least. The question is, who puts them into the
Actually 'gtf 1600 1200 170' (1600x1200 at 170Hz as your Monitor *was* capable *if* it allowed for higher horizontal sync values) yields Modeline "1600x1200_170.00" 504.56 1600 1744 1920 2240 1200 1201 1204 1325 -HSync +Vsync The horizontal sync values are clearly too high - however, testing this is much easier in the driver, and all drivers do, and no driver *never* *ever* should just crash due to a high number of modelines.
Once again: I did not report this for fun. And even though you seem to mistrust, there are other people perceiving similar issues. So, the lowest level of discussion would be to take things serious, isn't it?
Remember that we are getting quite a number of incomplete, inserious,
often downright false bug reports. Also consider, that on this channel
you are talking to developers, not support stuff. Also consider, that we
do not officially support binary only drivers like the fglrx drivers.
For reasons like this report, where we have to take the blame for a
major bug in binary only drivers - which we cannot change.
In any case, submitting this to bugzilla will probably no good, as
support for old (9.3) releases is on a low profile. And support for
binary only drivers on these releases is effectively non-existent.
No, that hasn't been my decision. We are just short of developers.
I think I'll start a wiki section in the OpenSUSE wiki for documenting
these issues. I hope this comes as close to a good documentation as
possible. It will take some time, though.
Matthias
--
Matthias Hopf