Anaconda and monitor handling

[Mike A. Harris]

Peter Boy wrote:

[Apologies for the lengthy reply, but I thought it was worth
  explaining this in a bit of detail, so it's archived somewhere
  for future reference.]

> There is a bugzilla entry (115662) regarding the the video resolution
> used by anaconda, if the properties of the monitor are unknown
> (proposition: use 640*400 instead of 800*600 as currently)

640x480 is incredibly small, and does not leave much room to fit
everything on the screen that is needed, so that is more or
less out of the question as far as I understand.  Even 800x600
is pretty short on real estate.


> On the other hand: anaconda can detect the proper resolution via DPMS
> and does so correctly.

DPMS is power saving.  You mean "DDC probing".  DDC probing is
performed by the "ddcprobe" utility, which uses LRMI which is
x86 specific.  As such, monitor autodetection is only performed
on x86, and not on any other architecture.

Additionally, DDC probing via ddcprobe only works if the video
BIOS implements it correctly and handles all of the connected
displays in a sane fashion, which in practice is rarely true.

KVM switches also generally block the DDC signal to/from the
monitor, which means most KVM switch users cause all software
to lose the ability to autodetect attached displays.

Many LCD panels, and DFP displays do not support DDC, and while
most if not all currently selling models do, there are hundreds
of thousands of ones already sold that do not.  So we can not
rely on the panel always being able to be detected.

There are various other reasons why DDC probing simply does
not work reliably, but I think the above list is adequate
enough to point out that it simply does not work very often.


The long term solution to this problem ultimately, requires
some rather long overdue non-trivial changes to the X server.
Since most of the video drivers implement DDC probing directly
by talking to the chip directly through i2c, the video drivers
have access to the most correct and accurate information, and
tend to be much more reliable in practice.

Additionally, since the video drivers do this directly, they
are not limited to DDC probing only on x86, and thus can
probe on any architecture. Some of the drivers do not have
native DDC probing, and use the VBE, however since the X server
includes a complete x86 emulator, the BIOS can be executed on
non-x86 architectures to provide DDC probing as well.

Unfortunately, none of that functionality is easily exported
outside of the running X server currently.  Once X.Org gets
enhanced to standardize the internal interfaces with which
drivers do this probing and various other things, and export
the information to applications in some manner, we will
theoretically be able to replace the very limited x86-only
ddc-probe utility with a more generic solution that works
on all architectures, and is much more accurate at detecting
attached displays and their various characteristics.

While there are currently no X developers who are planning
on working on this anytime soon to the best of my knowledge,
if there are any highly motivated developers out there, who
are interested in volunteering to make this happen, wether
or not you have prior X server development experience, please
feel free to drop by xorg at freedesktop.org and discuss your
interest.   The #freedesktop channel on freenode may also
be helpful as many X devs hang out there.

TTYL