Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: read ddc/edid on amd64?

  1. #1
    Join Date
    Nov 2007
    Posts
    1,353

    Default 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. #2
    Join Date
    Apr 2008
    Posts
    126

    Default

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

  3. #3
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote 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) ---

  4. #4
    Join Date
    Sep 2006
    Posts
    353

    Default

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

    Is there somewhere else I should post the above comment?

  5. #5
    Join Date
    Sep 2006
    Posts
    353

    Default

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

    http://linuxhelp.150m.com/resources/modelines.htm
    http://linux.50webs.org/resources/modelines.htm

    These have proved very helpful to me.

  6. #6
    Join Date
    Apr 2008
    Posts
    126

    Default

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

  7. #7
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote 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; 06-04-2008 at 08:50 AM.

  8. #8
    Join Date
    Aug 2007
    Posts
    6,627

    Default

    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.

  9. #9
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote 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; 06-04-2008 at 08:53 PM.

  10. #10
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote 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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •