AutodetectMonitorFrequency
Autodetect Monitor Frequency
[https://bugs.launchpad.net/ubuntu/+bug/3731 Bug 3731] is the second oldest Ubuntu bug, next only to Bug #1. There are also dozens of other bugs directly related to or dependent on fixing this bug. It's extremely important, yet unfortunately no where near trivial to fix.
For Gutsy, we've done some work to mitigate the effects of the bug, via BulletProofX, DisplayConfigGtk, and general upgrades of drivers, xorg, and xorg server, however none of these address the root causes of the problem.
At its core, this bug derives from several interrelated factors, which should be considered:
Monitors should provided EDID data we can use to determine frequencies. However, often this info is missing, inaccurate, corrupted, or misinterpreted.
- Some of the detection code has platform dependencies that may malfunction on some hardware, leading to #1
- The xorg-7.2/debian/xserver-xorg.postinst.in script attempts to guess the frequencies when the above tools aren't working. However, it makes poor guesses, often leading to the bug. This script is also quite lengthy, making it more of a challenge to maintain than it should.
- xorg-server itself has internal code for detecting and using EDID information to properly detect monitors. However, at POSTINST time, we do not have a mechanism for determining whether monitor detection should be left up to xorg later. Thus the installer often specifies frequencies when it doesn't need to.
- There are a number of circumstances, such as hotplugging monitors, attaching projectors, etc. which by definition the POSTINST scripts won't be able to deal with.
From these considerations, it seems that we may need to consider changing the monitor detection architecture.
The current system is designed to attempt to catch every case at installation time, both the regular case and all corner-cases. If the user changes things, they can re-run the script to reconfigure. However, users complain that this is hard to do. DisplayConfigGtk gives a more user-friendly mechanism for doing this, but is not tied in with the debconf mechanisms, and thus may need to be re-run when the user installs new xorg packages, which may lead to a clumsy user experience. Another problem - as outlined above - the current system does not catch all the corner cases as it should, and some cases like monitor hotplugging cannot be addressed at all.
A proposed alternate solution would drop the need to catch every case at installation time, leaving as much as possible to the X server's auto-detection algorithms, and relying more heavily on DisplayConfigGtk and BulletProofX to address the corner cases.
This means that by default dexconfig will be changed to not use debconf's monitor values, and instead will leave it to Xorg. It is expected that in situations where debconf does have accurate values, the X server would likewise be able to detect it, and that in situations where debconf has inaccurate values and that X server also cannot deal with them, that we should allow these to fall through to the GUI X config tools, and not attempt to guess things at POSTINST time.
Detect Bus ID
Another aspect that the xorg-server postinst script gets wrong is guessing at the bus id. This can turn up both as returning a completely erroneous one (e.g. 0:5:0 when the vga device is clearly 1:0:0), and as selecting the on-board device when the user has an add-in card and the monitor is connected to this.
See for example, http://www.linux.com/feature/118668
Todo
- Write some use cases (see Xorg7.3Integration)
- Incorporate the standard blueprint template into the above
Incorporate other bits from "Xorg7.3Integration"
Arrange to have many testers try booting xorg.conf with trimmed down Display sections & report results
Create a patch to /usr/bin/dexconf that omits the Display section & test xorg.conf's
Why does dexconf produce xorg.conf files that differ from what comes out of a generic install?
Is discover needed for any other X bits besides the monitor?
- Conceptualize how multi-head configurations could be detected automatically, and if so, how to configure them
Discussion
As for use cases I can see these:
1) My card and monitor are detected properly. This should JustWork (tm). It should not be broken by solutions to other scenarios. The failure of the current detection system in this case is that for CRT monitors that support multiple resolutions it chooses the largest instead of the one marked preferred in the edid info or one that has reasonable refresh rate (>80Hz). This is a bug in X afaik. For LCDs it should choose the native resolution, and as it is the largest supported it usually works. Unelss the xorg driver is trying to be too clever. The current ati driver does, at least in Debian. It conjures up a mode that fits the HorizSync and VertRefresh constraints but is larger than the physical panel size. Fixed in some 6.7 version of the driver which has reportedly other problems. Looks like even this case still needs quite a bit of testing.
2) My monitor is not detected. There should be an option to send as much info as possible when this situation arises and when the screen is set up properly. This should generate statistics about cards and monitors that fail.
a) my monitor is found in some built-in database, Windows info file or whatever the config tool can use. Just read the info and set up everything as per 1).
b) I do not have such info but my monitor is a LCD panel. This should be pretty easy. Just look up the native resolution which is often wrtten on the monitor or easily found in a manual. The screen should work with a mode that provides that resolution @60Hz.
c) I do not have such info, and my screen is CRT or something special. In some cases the manual might contain the specs like horizontal and vertical refresh ranges so there should be an option to enter these. As a last resort just select the screen size and desired mode, and see if it works.
3) I change my config often. Perhaps an installation on an USB drive or a small system like mini mac that I carry between multiple locations. The configuration tools should cope with different screen hardware on every boot without much hassle. In case the detection does not work, and the system is used only in a few configurations it might be useful to have some sort of profiles.
4) I have a laptop that I connect to external monitor, multiple screens, or other configuration that won't work properly in the near future. Such configurations may require manual setup or proprietary drivers (which often come with their own quite user friendly configuration tool). All the config tool could do in such cases is switching configuration profiles (ie. laptop normal operation, laptop with tvout, laptop with projector connected) and possibly allowing to save/load/share such profiles.
5) I do not see anything!?!. Something went wrong with the X configuration. The config tools should provide some 'safe mode' (VGA/VESA) which is entered easily when the current configuration does not work. Note that some cards/platforms do not do VESA.
-v-
The ubuntu screen resolution is important. It is keeping me on XP.
* Windows correctly detects my monitor settings. Do you know how they achieve this?
No unless yu provide more details.
* Are there distros that work, and if so, what can we learn and incorporate?
* As part of the boot up, would a "set screen resolution and refresh rate" option be a temporary fix? That way if something goes wrong, a mere reboot (press F?) then set the screen resolution and refresh rate would at least make Ubuntu work in this area.
* Can you create an EDID program to detect, update settings? For monitors I take it. Would that provide any useful information?
There is a read-edid package in Ubuntu that provides the command get-edid, which you run like this: sudo get-edid | parse-edid. If your monitor provides EDID information, that command will print it out.
* XP just shows my monitor as "default", not as Viewsonic G90f+. So XP must be doing something right.
No, they aren't. The "default" monitor type is one that is displayed when a monitor is detected as connected but no info can be read. It might be that you have set your mode in Windows at some point (probably when it complained that your screen resolution is low) but the type that appears when Windows can read EDID is "PnP Monitor" or similar.
* In the case of EDID - "missing, inaccurate, corrupted, or misinterpreted", choosing a monitor from a drop down list with a repair EDID or store EDID information settings - would that help?
The EDID is data hardwired into the monitor so AFAIK there's no way to repair it. I suspect what Windows does is either it has a database of all monitors in the world and knows when the EDID is broken and how to overload it, or else the CD that came with the monitor contains correct data for Windows. In our case, choosing from a drop down is probably the way to go - this is what displayconfig-gtk is designed for.
* If you had an EDID tool then you can gather information as to how often the problem is with the EDID. At this stage we don't know to what degree this is causing problems. Stats would be of interest. How wide spread is the problem? Are some monitors worse than others? We would benefit knowing the problem in more detail.
- This is a widespread problem. While read-edid, ddcprobe and xorg do pretty much the same thing sometimes the X drivers or the external tools do something wrong and cannot read the info. There are a few monitors out there that do not provide any info at all, and a few that are broken (and would require a replacement info when detected). However, the most serious problem is that on many cards no monitors are detected because the detection is broken in xorg or the detection tool used.
* I do think that Ubuntu needs a proper safe mode boot option like XP has but better. A GUI that can be used to restore system critical files, such as a working xorg. Anything that will prevent Ubuntu from starting to a basic working interface ought to be protected by redundancy and easy, straight forward GUI interfaces.
* At the moment as soon as Ubuntu falls over, I have to reinstall it. As soon as XP loses paces, I just reimage it - about 5 minutes. You can see that Ubuntu has to be improved in this area.
- Not sure I understand this one - can't Ubuntu also be reimaged?
Just a final comment for now, and that is that the work you have done so far, since April this years is looking good. As you said, this is the 2nd oldest Ubuntu bug and so it will be quite an achievement when it is resolved fully by yourself and the team.