Created attachment 106296 [details]
ddcprobe-stub patch to change "Videocard DDC probe" to "Videocard VBE probe"

Adding Mike Harris to CC on this bug, since this is probably something
he should look at. (I should have done this a long time ago.)

The premise in the initial comment in this bug is incorrect.  DDC
stands for "Display Data Channel".  This is a communication channel
between the video hardware and the display connected to it, which
provide the operating system software with the ability to query
the attached display(s) for their hardware details related to
autoconfiguration.

The process of using the DDC to communicate with the attached
displays is called "DDC probing", since the hardware display is
being probed via the DDC communication channel between the display
and video adaptor.

At the register level, DDC probing is entirely hardware specific.
This means in order to do a DDC probe on a Radeon card, you
must know the specific hardware details not only of ATI Radeon
hardware, but of the specific implementation of the exact board
being used, because it is possible to wire up a Radeon in a variety
of different ways, and both ATI and 3rd party manufacturers do just
that.  I use ATI only as an example here to illustrate that DDC
probing is very hardware specific in nature, and not generic in any
way, however Nvidia and every other piece of video hardware ever
manufactured out there is equally unique in this sense.

Since DDC probing is so incredibly hardware specific, it needs to
be abstracted via some interface, so that it can be used in a
sensible manner.  This is no different really from drawing a line
on the screen, or blitting a pixmap from system memory to screen.
In other words, DDC is just another hardware specific thing that
needs to be abstracted in order to be useable by the OS et al.

Hardware abstraction is done in computer systems generally in two
ways:

1) By providing hardware specific drivers that know how to talk to
the hardware, and export an API of some sort to abstract the
features.

2) By providing a ROM BIOS on the device which uses a standardized
and well accepted API, and implementing the necessary features in the
BIOS to abstract the hardware at the BIOS level.


Like many other things, DDC is implemented at both levels.  Most of
the open source X server drivers have DDC probing implemented directly
in each driver for the hardware that driver covers.  Since it is a
very hardware specific thing, both on the chip and card level, DDC
probing can be tricky to get 100% correct, and like anything,
sometimes driver bugs exist, or sometimes new hardware comes out that
does things differently from what the driver was coded to handle. 
This may require future updates to the driver to handle the new
hardware.  Again, this is really no different from any other feature
of the hardware.

Most video BIOS's implement VESA VBE, which contains an API for doing
DDC probing.  While the DDC probing code present in most video BIOS's
is less than ideal, it is often sufficient enough for simple
configurations, and on some hardware is probably as reliable as doing
it in the driver itself.

Wether you invoke a DDC probe by directly programming registers on the
video hardware - such as the Radeon driver, or wether you invoke a DDC
probe by mapping the video BIOS and invoking the proper VBE calls - it
is still a DDC probe, and calling it something else is just mincing
words for no useful purpose.

There are advantages and disadvantages for both mechanisms of DDC
probing.

One advantage of using the video BIOS directly, is that the software
doing the probing, does not need to know anything at all about the
video hardware specifics, as it is using a standardized abstraction
layer at the BIOS level.  The BIOS takes care of directly programming
the video hardware correctly (hopefully anyway), and presenting the
information back to the caller.  Another advantage of this, is that
the DDC probing implementation is simplified greatly, because the
complexities are hidden by the BIOS itself.

One disadvantage of using the BIOS, is that the BIOS is generally x86
code, and wont run on non-x86 hardware without using x86 emulation. 
That disadvantage is lessened somewhat by the fact that the X server
does have an x86 emulator built into it (x86emu) specifically for
invoking BIOS calls on non-x86 hardware.  The emulator works fairly
well, but isn't 100% flawless, although bugs generally get fixed when
the rare occasion occurs that one is found.  Another disadvantage of
using the BIOS, is that the BIOS implementation may have limitations,
or may have limitations in certain hardware configurations, or may
have blatant bugs in it that just make BIOS DDC probe useless.  In
this case, the real disadvantage is that you can't really "fix" the
BIOS, and thus relying on a buggy BIOS or BIOS lacking certain
features, more or less makes it impossible to do a correct DDC probe.

The advantage of doing DDC directly to the hardware, is that at least
in theory, you can make it work on every piece of hardware, in any
configuration, unless there are hardware bugs, or unless the necessary
documentation required to implement this is not available from the
manufacturer.  The disadvantage of doing DDC probing directly is that
you do need to have the hardware documentation for every piece of
video hardware in order to implement the hardware specific code.


Which method should we use to do DDC probing?  Unfortunately, there
are two answers for that question.

The "What we are stuck with for now, and have no choice" answer:

Most of the video drivers, but not all - internally talk directly
to the video hardware to do DDC probing.  In most cases, the video
driver can thus autodetect attached displays reasonably well.  In
other cases some video drivers internally use VBE calls themselves
to do DDC probing, either because the information required to do it
directly to the hardware are not available, or because nobody has
implemented it directly in that driver yet.  Unfortunately, neither
the X server, nor the video drivers export the DDC information they
are able to obtain via any API, let alone a standardized one.  As
such, the DDC probing code in the X server modules is only useful
inside the modules themselves, and is not useable to external
software at this point in time.  Nonetheless, the DDC probing code in
the driver modules is generally superior to any solution that has been
designed outside of the X server (such as ddcprobe util).  Since the
ddcprobe utility does not have any way at all to use the DDC probing
routines present in every video driver in any sensible way, it either
has to use the VESA VBE calls to get an abstracted API for this
information, or it needs to internally re-implement DDC probing for
every known video card ever made.  The latter is totally infeasible,
and so ddcprobe uses VBE to do DDC probing, and it will probably
remain this way.  An additional limitation of ddcprobe, is that it
uses LRMI, which only works on x86, so the ddcprobe utility is
essentially x86 only.

What is a better solution which may be available in the future?

Ultimately, it is best to have a single place where hardware is
abstracted.  While the BIOS would be an ideal location in theory, in
practice it isn't good to rely on hardware vendors getting their
BIOSes 100% correct all the time, and it also isn't feasible to patch
a BIOS to fix bugs.  As such, the only 'practical' location to do DDC
probing in an architecture neutral fashion is at the video driver
level.  This keeps video hardware specifics all in one place.  In
order for this to be useful outside of the X server however, some form
of standardized API would have to be developed by X.Org developers to
export the video driver's DDC probing code (and preferably a lot of
other video driver internals) outside of the driver, perhaps via a new
X server extension of some kind, or even just letting apps such as
ddcprobe dlopen() the video driver and invoke it's DDC probing routine.

Such an API or mechanism does not currently exist however.  As such,
doing DDC probing outside of the X server and driver modules has some
rather unfortunate limitations at the present time, however these
limitations will hopefully be overcome once the upstream X.Org project
enhances the X server et al. to provide access to it's hardware
routines in an abstracted manner.


Why did I write this lengthy explanation?  ;o)

Because many people have asked me about this in the last 6 months, who
think it should be simple to do DDC probing on all architectures in a
simple manner, and that is unfortunately a false premise.  It is a
complex problem, with no simple solution currently.  By explaining
this here, I can now just point people to this bug report for a
detailed explaination, rather than re-explaining it multiple times.  ;o)

The patch attached is bogus.  There is no such thing as a "VBE probe".
 The terminology being used currently is 100% correct, and IMHO should
not be changed.  

Closing this report "NOTABUG".

Ok, obviously we're not understanding each other. (I read through your
entire comment and it sounds like you're discussing a patch I never
sent.) I'm going to try this again and see if I can explain myself
more clearly this time.

Without my patch:

Videocard DDC probe results       <--- I believe this is incorrect
Description:  ATI Technologies Inc. R100
Memory (MB):  32

Monitor DDC probe results         <--- But we agree this is correct
ID: APP01f4
Name: AppleStudio
Horizontal Sync (kHZ): 31-61
Vertical Sync (HZ)  : 56-76
Width (mm): 310
Height(mm): 230


With my patch:

Videocard VBE probe results     <---- this changes
Description:  ATI Technologies Inc. R100
Memory (MB):  32

Monitor DDC probe results       <---- but this says unchanged
ID: APP01f4
Name: AppleStudio
Horizontal Sync (kHZ): 31-61
Vertical Sync (HZ)  : 56-76
Width (mm): 310
Height(mm): 230


ddcprobe is doing two different things. With my patch, the DDC probe
is still called a DDC probe. As far as I can tell from both what
you're saying and what the VBE standard says, the other probe has
NOTHING to do with DDC! And *that* is what this bug is about.

> The terminology being used currently is 100% correct

It's 100% correct for the 50% of ddcprobe's functionality that you
discussed in your comment. I'm trying to fix the *other* 50%.

Originally I was going to make a patch splitting ddcprobe into two
separate utilities, since half of the functionality has nothing to do
with DDC, but I thought that would be too invasive. Now I'm not so sure...

Ok, I think I misunderstood your request a bit, however I did want
to clarify what DDC actually is, to avoid confusion (beyond what
is in this report).

Detecting what video card(s) are present in a system is indeed
*NOT* DDC probing, and has nothing to do with DDC.  DDC is strictly
a communication channel between the video adaptor and attached
displays with which a video driver or other software can communicate
with the display through the video adaptor.

If our tool is detecting what video card is present and calling
this process "videocard ddc probe" then that does sound silly and
should be fixed.  I would suggest "Autodetecting video card."
and "Autodetecting connected displays." and exclude the low level
details of what is being used to do so entirely.  The end user
does not need to know anything about DDC, and the more technical
information displayed that isn't really necessary, the greater
the chance of confusion.

I'll reopen this, and let the tool maintainer decide what to do.

Thanks for the clarification Barry.