Hi,
On Fri, 8 Sep 2006, William Gallafent wrote:
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.
Please stop falsifying this thread.
AFTER installation is totally different from DURING installation.
Getting confronted with too high frequencies at the right resolution
during installation is a 100% show stopper if you don't know some dirty
tricks.
This has to get fixed!
It is NOT OK currently!
Maybe some of us can't accept it as a bug, but then they have to accept it
as a SUSE specific stupidity (believing "facts" or similar).
Please, please someone with the same experience may call "me too" here
now, before I loose my patience in the well-known way...
Cheers -e
--
Eberhard Moenkeberg ([EMAIL PROTECTED], [EMAIL PROTECTED])
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
