Announcement

Collapse
No announcement yet.

read ddc/edid on amd64?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • read ddc/edid on amd64?

    There has got to be a way to do it. On x86 there is ddcxinfo, read-edid, ddcprobe. But none of these utilities work on amd64. How to do it There has to be some way.

    Do you guys have any idea how to get the ddc/edid data from a monitor on amd64?

  • #2
    I used the open source nv driver, started X.org. The EDID was present in /var/log/Xorg.0.log as a hex dump.

    Comment


    • #3
      Originally posted by duby229 View Post
      There has got to be a way to do it. On x86 there is ddcxinfo, read-edid, ddcprobe. But none of these utilities work on amd64. How to do it There has to be some way.

      Do you guys have any idea how to get the ddc/edid data from a monitor on amd64?
      Run the command startx -- -logverbose 5 from the console.

      The EDID information turns up in /var/log/Xorg.0.log (or /var/log/XFree86.0.log).

      On my amd64 box I get something like this:

      Code:
       --- EDID for Philips 170S (CRT-0) ---
      
       EDID Version                 : 1.3
       Manufacturer                 : PHL
       Monitor Name                 : Philips 170S
       Product ID                   : 2078
       32-bit Serial Number         : 693129
       Serial Number String         :  CF  693129
       Manufacture Date             : 2003, week 32
       DPMS Capabilities            : Standby Suspend Active Off
       Prefer first detailed timing : Yes
       Supports GTF                 : No
       Maximum Image Size           : 340mm x 270mm
       Valid HSync Range            : 30.0 kHz - 82.0 kHz
       Valid VRefresh Range         : 56 Hz - 76 Hz
       EDID maximum pixel clock     : 140.0 MHz
       
       Established Timings:
         640  x 480  @ 60 Hz
         640  x 480  @ 72 Hz
         640  x 480  @ 75 Hz
         800  x 600  @ 56 Hz
         800  x 600  @ 60 Hz
         800  x 600  @ 72 Hz
         800  x 600  @ 75 Hz
         1024 x 768  @ 60 Hz
         1024 x 768  @ 70 Hz
         1024 x 768  @ 75 Hz
         1280 x 1024 @ 75 Hz
       
       Standard Timings:
         1152 x 864  @ 70 Hz
         1152 x 864  @ 75 Hz
         1280 x 960  @ 60 Hz
       
       Detailed Timings:
         1280 x 1024 @ 60 Hz
           Pixel Clock      : 108.00 MHz
           HRes, HSyncStart : 1280, 1328
           HSyncEnd, HTotal : 1440, 1688
           VRes, VSyncStart : 1024, 1025
           VSyncEnd, VTotal : 1028, 1066
           H/V Polarity     : +/+
       
       --- End of EDID for Philips 170S (CRT-0) ---

      Comment


      • #4
        The above info on EDID does not seem to be that well known.

        Is there somewhere else I should post the above comment?

        Comment


        • #5
          By the way,.. you can find a list of known good modelines here:

          How to Make a Website with free web hosting services & cheap web hosting for ecommerce & small business hosting. Create & Make a Free Website with Affordable web hosting provider free website promotion tools & web stats. Free Website Builder, Templates, & Best Free Web Hosting. How to Create a Website



          These have proved very helpful to me.

          Comment


          • #6
            I can't believe we still need to edit display resolutions and frequencies ourselves. This is 2008 for crying out loud.

            Comment


            • #7
              Originally posted by apaige View Post
              I can't believe we still need to edit display resolutions and frequencies ourselves. This is 2008 for crying out loud.
              Believe it or not. The need to manually edit display resolutions and frequencies is a "design feature" that, for some 15 years now, has made Linux much harder to install and use, than say, windows.

              This "design feature" (after some 15 years) is being phased out by simple programs that read the EDID and then deliver the wrong resolution,... "by mistake," of course.

              This "design feature" has been bought to your local dedicated team from Linux Saboteurs Inc.

              Yes you may wonder why it has taken 15 years to write a very simple piece of software that would read the EDID and set the correct resolution, etc, in the Xorg.conf file. And,... we are nearly there,... if only the simple piece of software could read the stored resolution and set it, rather than set some other resolution. O.K.,.. sometimes this works, but it is broken in a lot of cases.

              You may also wonder why the best Linux filesystem (Reiser4) has been actively sabotaged and kept out of the Linux kernel.

              You may wonder why the kernel NTFS filesystem (the windows filesystem) driver for Linux was removed from the kernel and thrown away (about 1999) and a (slower) user-space driver for the NTFS filesystem, not developed till 2006/7.

              By the way Reactos still uses the discarded NTFS kernel driver (that has been kept from Linux users for many years) and it works fine.

              You may wonder why video and audio has a long history of stuff-ups in Linux. Ask Microsoft, the RIAA and MPAA if they know anything about this.

              Ask Linus why he tossed the kernel NTFS driver away.

              Ask Linus why he wouldn't allow Reiser4 into the kernel.

              Ask Linus if he really only cares about technical issues, when it is clear he is up to his neck in various political issues.
              Last edited by Jade; 04 June 2008, 08:50 AM.

              Comment


              • #8
                Only Red Hat did not include the ntfs driver which actually is inside the kernel. For read access that was enough and it could change files - but you could not add much more data to a file as that would have required some changes to the filesystem which where not supported. There was another userspace driver much before ntfs-3g (called ntfs-fuse) but the main developer went to Apple and then the development was done privately, therefore ntfs-3g was the 3rd generation driver.

                Comment


                • #9
                  Originally posted by Kano View Post
                  Only Red Hat did not include the ntfs driver which actually is inside the kernel.
                  Sorry but you are completely wrong.

                  Are you deliberately confusing the (essentially) READ-ONLY and READ-WRITE ntfs drivers that existed back about 1999/2000.

                  Red Hat stopped including the READ-ONLY ntfs driver (that all other distros include).

                  Red Hat never included the (almost fully functional) READ-WRITE ntfs driver of 1999/2000.

                  The READ-WRITE ntfs driver was thrown away by Torvalds (but it is still used in ReactOS).
                  Last edited by Jade; 04 June 2008, 08:53 PM.

                  Comment


                  • #10
                    Originally posted by Kano View Post
                    There was another userspace driver much before ntfs-3g (called ntfs-fuse) but the main developer went to Apple and then the development was done privately, therefore ntfs-3g was the 3rd generation driver.
                    This is wrong as well.

                    The ntfs-3g userspace driver uses the FUSE (filesystem in user space) API to do its thing.

                    NTFS-3g needs FUSE to run.

                    FUSE was not (and has never been an NTFS driver, in itself).

                    Maybe you are confusing FUSE with ntfsprogs package from http://www.linux-ntfs.org (which are userspace programs which now include read-write functionality).

                    Comment

                    Working...
                    X