== Problem ==

Monitor detection is one of Ubuntu/Xorg's most major problems.  Much of the time it works, but when it fails, the user is often left having to edit xorg.conf directly, a task both beyond many user's capabilities and presenting a serious irritation early in new user's Ubuntu experience.

The symptoms of mis-detection are wide ranging, however the failure mode is typically the same.  The detection tools (for whatever reason) fail to detect either the card, the monitor, or both.  This results in generic default settings to be recorded.

Now, sometimes these defaults work just fine, and even though technically the monitor has been mis-detected, the user doesn't see it as a problem and goes about their business.  They may run into a variety of issues later on, however, and may or may not connect those issues with the mis-detection.

Quite often the defaults *almost* work.  For instance, they overlap enough with the card's capabilities that the user can get basic resolutions.  But the user notices that the full range of his card/monitor capabilities are not available; for instance, higher resolutions, widescreen resolutions, or higher refresh rates may not be selectable.

Sometimes the defaults *don't* work.  This can occur if the defaults are outside or incompatible with what the monitor/card can do.  The user tries to start X but it fails with a "no modes available" type of error message.

In any case, for all the myriad symptoms, the core issue is the same:  The monitor/card detection tools failed.

== Causes ==

There are two general reasons the tools fail.

One reason is if the user's hardware setup falls outside the tools' design parameters.  For example, they may be used on a hardware platform the given tool has not been ported to.  Or the user has multiple video cards, or has hot-swapped an external monitor or projector onto their laptop.

The second reason is that the user's hardware is bad.  This is unfortunately common.  Older monitors may not support DDC.  Some monitors are buggy and give bad data.  Adapters or KVMs may corrupt the data from the monitor before it reaches the card.  The card may corrupt things or fail to pass things along properly.  Or the card or monitor may simply lie and give incorrect values.

== Solution Strategies ==

There are two general ways to approach the problem.  First is to address the symptoms, to make the user's experience better when things have failed.  Second is to address the root cause, to make the tools mis-detect less often.

For addressing the symptom of mis-detection, a GUI config tool displayconfig-gtk is to be used.  If the user can boot into X, then they can access this tool for setting the correct driver, resolution, etc.  For situations where they cannot boot into X, we are adding a failsafe mode, called BulletProofX.

For the root cause, there are also two ways to approach this.  First is to rely more heavily on Xorg's built-in detection code; it is under active development and can be expected to eventually always work.  Second is to fix up the existing tools so that they fail less often.  We also need a good way to determine when to use the first approach, and when to use the second.

== Tools ==

 * ddcprobe - (C) queries ddc info
 * get-edid - (C) queries edid info
 * vbetool - (C) uses lrmi to interact with video BIOS
 * laptop-detect
 * xresprobe - (bash) used on i386, amd64, ppc to detect monitor
  * rigprobe.sh
  * lcdsize.sh
  * bitdepth.sh
 * xserver-xorg-postinst - (bash) uses xresprobe to fill in debconf with detection data
 * dexconf - (bash) generates an xorg.conf using debconf database

== Tasks ==

 * Build a database of tool output from a wide range of different hardware types
 * Build a listing of failure scenarios
  * Identify if the failure is due to tool design inadequacy, or to bad hardware
  * Determine if Xorg could have detected the hardware adequately by itself in this scenario
  * Identify what must be added to xorg.conf to make it work
  * Will bulletproof-x/displayconfig-gtk allow for easy manual fixing?
 * Review Debian's current dexconf to Ubuntu's, identify differences, and evaluate how similar/different our dexconf should be
 * Investigate if Xorg has a list of hardware that they know *will* be detected, and hardware that *won't*.  I'm assuming no such list exists, but it'd sure make our lives easier if it did.
 * Improve xresprobe
  * Add more/better error detection/reporting
  * Merge bitdepth.sh into xresprobe
   * Evaluate if there are other situations where bitdepth should be forced
  * Merge ddcprobe.sh into xresprobe
   * Do we still need to blacklist 2288x1430?  Any others that need blacklisted?
   * Evaluate if we're catching all possible failure cases from ddcprobe
   * Is grepping for '*digital*' always going to mean 'lcd'?
   * Do we really want to drop the highest resolution?
  * Merge lcdsize.sh into xresprobe
   * Evaluate if other drivers need lines added (-intel?)
  * Merge rigprobe.sh into xresprobe