Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ddcprobe's "Videocard DDC probe" isn't really a DDC probe (it uses VBE)|
|Product:||[Fedora] Fedora||Reporter:||Barry K. Nathan <barryn>|
|Component:||rhpxl||Assignee:||Chris Lumens <clumens>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-10-11 12:00:38 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Barry K. Nathan 2004-11-08 14:04:26 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1 Description of problem: ddcprobe claims to do a "Videocard DDC probe". However, in the course of troubleshooting bug 108681, I learned from Mike Harris that there is no such thing. I think it would be less misleading if it was called something like a "Videocard VBE probe". Even if that's not the best phrase either, it's much better and much closer to the truth than "Videocard DDC probe". To make sure there's no misunderstanding, I will attach a patch that shows the type of change I'd like to see. Version-Release number of selected component (if applicable): rhpl-0.148-1 How reproducible: Always Steps to Reproduce: 1. Run "/usr/sbin/ddcprobe" as root. Actual Results: "Videocard DDC probe" -- but there is no such thing Expected Results: "Videocard VBE probe" or some other phrase that is closer to being correct Additional info:
Comment 1 Barry K. Nathan 2004-11-08 14:06:06 EST
Created attachment 106296 [details] ddcprobe-stub patch to change "Videocard DDC probe" to "Videocard VBE probe"
Comment 2 Barry K. Nathan 2005-01-06 03:02:03 EST
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.)
Comment 3 Mike A. Harris 2005-01-10 15:31:55 EST
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".
Comment 4 Barry K. Nathan 2005-01-10 17:19:29 EST
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...
Comment 5 Mike A. Harris 2005-01-11 13:24:29 EST
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.