This is a tracker for the general issue that the server's log output is awful.
A recent logfile improvement David Dawes put into XFree86 was going through all
the drivers mode validation functions and fix them to return more specific errors
than "MODE_BAD" whereever possible. Seems like a reasonable project to recreate
(not copying David's code directly of course) on our side if someone has a couple
of hours to spare.
users are trained to interpret (WW) and (EE) as Very Bad Things. as a general guideline we should only
issue (EE) statements when we know for absolute certain that the issue the message diagnoses is going
to be fatal to the server. (WW) is a bit of a judgement call but should be kept to a minimum at any rate.
Bug #2141 is a good example of a bad X_WARNING.
*** Bug 1406 has been marked as a duplicate of this bug. ***
Sometimes I set the monitor properly in xorg.conf, yet I can't get the
resolution I want at 75Hz even though it supports it. I would like to see the
logs specifically tell me why it could not work at 75Hz, i.e. what the problem is.
Also, once X chooses a resolution, I would like to see it show up in the logs.
I cannot tell what resolution was choosen by reading the logs. Sometimes it is
obvious that 1280x1024 was not selected, but am I in 800x600 or 640x400? In
some OS with a simple X login, it is not easy to guess by looking at the screen.
I nice clear message in the logs would be helpfull.
the remaining blockers on this aren't severe enough to block 7.0.
removing from 5041 blocker, 4837 isn't strong enough to block release.
(In reply to comment #1)
> A recent logfile improvement David Dawes put into XFree86 was going through all
> the drivers mode validation functions and fix them to return more specific errors
> than "MODE_BAD" whereever possible. Seems like a reasonable project to recreate
> (not copying David's code directly of course) on our side if someone has a couple
> of hours to spare.
Some of this ModeStatus noise will get resolved by my removal of multiple
clockRanges. This is because of clockRange checking returning the pretty useless
The few quick and dirty culls/cleanups i've done locally had the clockRange
checking (replacing the clockrange search, as we have only one (dot)clockRange
per CRTC) return something useful.
This will happen at the same time as the static dotclock clean-up though, which
sadly depends on mach64 clean-up.
Are there any papers defining what kind of verbosity the different log levels
are supposed to have?
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
ajax at nwnk dot net
Do you still experience this issue with newer soft ?
Please check the status of your issue.
The bug summary is certainly still true, but this should be tracked with more specific bugs for individual issues.