| Summary: | Server log is noisy, unhelpful, and/or misleading | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Adam Jackson <ajax> |
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | high | CC: | brant, erik.andren, hans, roland.mainz, stuart.kreitman |
| Version: | git | Keywords: | janitor |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 927, 2141, 2142, 3016, 3224, 3687, 4837, 4948 | ||
| Bug Blocks: | |||
|
Description
Adam Jackson
2005-04-23 12:33:18 UTC
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 MODE_CLOCK_RANGE. 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.