On Friday 08 September 2006 23:03, Eberhard Moenkeberg wrote: > During the installation phase, only those facts are valid > which happen to the user, not those stated in papers.
Sure. The fact is, though, that if a reasonable EDID resolution / refresh is found, then it should be used. That's what the monitor manufacturers put these data in their monitors for! I've also experienced many problems with SaX over the years, and until very recently have generally had to resort to manual intervention to get things working the way I wanted. Problems have often included SaX2 picking very high (technically within specification, but in practice right on the limit) refresh rates, particularly with CRT monitors, either using the parameters from its database or read down the wire from the monitor. > If I would not use those tricks with F3 (i.e. telling lies > about the resolution), i would have seen hundreds of black > screens without any way around it the last year. Hmm, I certainly experienced some completely non-working graphics with older versions, but 10.0 and 10.1 have both worked well here (10.1 better than 10.0). Also, I'm surprised you're getting stranded without an escape route (apart from console hacking) - see below. > This is annoying, and only a consequence of a wrong method by > SUSE. I agree: although in my experience Xorg is very good at determining correct settings for attached screens, SaX2 does not seem to be nearly as reliable, for me at least. That was certainly the case until 10.1: 10.1 worked well on this machine, which had defeated SaX2 in several previous versions (nVIDIA GeForce card with two DVI outputs, running dual head), but which worked fine if you just let Xorg pick the resolutions and refresh rates according to the data it gets directly from the screen. I don't know how SaX2 works, but I believe it uses a database of screens, cards etc. Perhaps it should shift to using the resolution and refresh rate data which is read from the monitor as the most-trusted information, favouring it over the numbers in its database, when the machine-readable information is available (apologies to SaX2 developers if it does already!) > This is a major bug DURING installation, when the user is > totally helpless. > After installation one can correct it with sax2, but only if > one has a chance to reach the state after installation... Yes. I think the problem occurs not when SaX2 is unable to determine ideal settings - in that situation it tends to default to sensible baseline IIRC - but when it _thinks_ it's got the ideal settings for the system, but in fact they are out of range. That's just a bug in SaX2, either due to incorrect information in its database, incorrect information reported by the hardware, or incorrect interpretation of that reported information. Isn't it the case, though, that after setting the graphics card and screen parameters, you can test them out: there's a countdown dialogue which you have to press "OK" on to confirm the settings work for you? If you don't press it then you go back to the standard installer display settings (which must have been working for you to get this far!) In this way you can adjust the settings until they work, without being stranded at a blank screen or terminal. This seems sensible, and I think it's how I remember it working in the past. -- Bill Gallafent. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
