[TAG] A script for editing a config file

[Benjamin A. Okopnik]

On Mon, Nov 07, 2005 at 06:07:36PM +0530, Kapil Hari Paranjape wrote:
> On Sun, 06 Nov 2005, Benjamin A. Okopnik wrote:
> > On Sun, Nov 06, 2005 at 10:44:24AM +0100, G?bor Igl?i wrote:
> > >  I admit that I am a bit confused now by the complexity of X and dpi
> > > and have to take a second read. Is there a tool instead of xdpyinfo
> > > that actually measures the REAL dpi?
> > 
> > Not unless it's got a little elf that can crawl out and measure the
> > screen. :) Seriously, I understand that ACPI-compliant hardware reports
> > all its own particulars to the system, and I can't see why an
> > ACPI-compliant monitor wouldn't do that; in this case, all you'd have to
> > do would be to read /sys/devices/<whatever> to get the data. However,
> > complete ACPI compliance is still a ways off. I may be wrong, but this
> > is the state of what I know on this topic. :)
> 
> Actually, there is also DDC and EDID. The first is a way for the
> monitor and the graphics card to "exchange" information. The second
> is some kind of table that the monitor keeps about its capabilities.

Right, right... now that you mention it, I recall using "get-edid" at
some point in the past, for something-or-other. Oh yeah - I was
troubleshooting X setup with a brand-new ATI chipset, and couldn't
figure out what the machine "knew" about the hardware. I'd read about
EDID, and was only slightly enlightened with regard to what it was, but
your explanation now makes a lot of sense.

> Presumably either of these "could" get the monitor to give accurate
> information about itself.

I _think_ that's supposed to be the point of the thing. :) Not that it's
all *that* useful yet:

``
ben at Fenrir:~$ su -c get-edid
Password: 
get-edid: get-edid version 1.4.1

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
        Function supported
        Call successful

        VBE version 200
        VBE string at 0x11110 "ATI MOBILITY RADEON 9600   "

VBE/DDC service about to be called
        Report DDC capabilities

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
        Function supported
        Call successful

        Monitor and video card combination does not support DDC1 transfers
        Monitor and video card combination does not support DDC2 transfers
        0 seconds per 128 byte EDID block transfer
        Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
        Read EDID

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
        Function supported
        Call failed

The EDID data should not be trusted as the VBE call failed
EDID claims 19 more blocks left
EDID blocks left is wrong.
Your EDID is probably invalid.
''

> That is the limit of *my* state of knowledge at this point of time.

  "We should not be crippled by the knowledge that no one of us can know
  what all of us together know."
   -- The Shockwave Rider, John Brunner

:)


* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *