read ddc/edid on amd64?

[duby229]

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?

[apaige]

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

[Jade]

Originally Posted by duby229

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:

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

[Jade]

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

Is there somewhere else I should post the above comment?

[Jade]

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.

[apaige]

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

[Jade]

Originally Posted by apaige

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.

[Kano]

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.

[Jade]

Originally Posted by Kano

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

[Jade]

Originally Posted by Kano

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