Bug 415 - "ModeLine" ignored, overriding EDID impossible
: "ModeLine" ignored, overriding EDID impossible
Status: CLOSED WONTFIX
Product: AMD Catalyst™Proprietary Display Driver
Classification: Unclassified
Component: X11 Driver
: .archived
: All Linux
: low normal
Assigned To: nobody
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-01 03:21 CST by Josua Dietze
Modified: 2012-10-31 17:35 CDT (History)
3 users (show)



Attachments
Output of atigetsysteminfo.sh, gzipped (61.00 KB, application/x-gzip)
2012-02-01 03:21 CST, Josua Dietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Josua Dietze 2012-02-01 03:21:48 CST
Created attachment 349 [details]
Output of atigetsysteminfo.sh, gzipped

Description of problem: 

In the "Monitor" section of the "xorg.conf" file, any "ModeLine" is obviously ignored by fglrx. The consequence is that any incorrect or missing EDID information will always throw the system back to standard 4:3 resolutions.

This typically happens when booting headless or with a simple KVM switch in use and the system in question not being "active". 

Steps to reproduce:
1. Enter monitor parameters and calculated "ModeLines" in the "Monitor" section of "xorg.conf"
2. List names of the custom ModeLines in the "Display" subsection after the keyword "Modes".
3. Boot headless (no monitor attached).

Actual result: 

Screen resolution is wrong, "/var/log/Xorg.0.log" shows that the custom mode was not evaluated, it is not even mentioned.

Expected result:

Honor the override, just check monitor parameters to make sure that the pixel clock does not exceed the limits. This is how the open source drivers behave.

Alternatively: document a different way to set a FIXED resolution with the fglrx driver.
Comment 1 ogilvierothchild 2012-02-04 01:02:32 CST
Having the same problem, trying to run some v7900's headless to do some GPU calculations remotely.  I managed to get X to start with no attached display, and can setup xauth and DISPLAY vars so I can run programs.  The problem is that many codes have a non-optional display component, which is fine as I setup VNC and VirtualGL also.

The problem is that the framebuffer is 640x480 and cannot be changed.

Modelines, settings in xorg.conf, & in the /etc/ati/amdpcsdb file seem to make no difference, the mode for the display is stuck at 640x480.
Comment 2 chris 2012-02-06 11:57:58 CST
(In reply to comment #1)
> Having the same problem, trying to run some v7900's headless to do some GPU
> calculations remotely.  I managed to get X to start with no attached display,
> and can setup xauth and DISPLAY vars so I can run programs.  The problem is
> that many codes have a non-optional display component, which is fine as I setup
> VNC and VirtualGL also.
> 
> The problem is that the framebuffer is 640x480 and cannot be changed.
> 
> Modelines, settings in xorg.conf, & in the /etc/ati/amdpcsdb file seem to make
> no difference, the mode for the display is stuck at 640x480.

As work around you can try to emulate the entire edid and to fake a monitor. So even if you currently cannot specify the video timings using a mode line you can define them in an edid file. (In reply to comment #0)
> Created attachment 349 [details]
> Output of atigetsysteminfo.sh, gzipped
> 
> Description of problem: 
> 
> In the "Monitor" section of the "xorg.conf" file, any "ModeLine" is obviously
> ignored by fglrx. The consequence is that any incorrect or missing EDID
> information will always throw the system back to standard 4:3 resolutions.
> 
> This typically happens when booting headless or with a simple KVM switch in use
> and the system in question not being "active". 
> 
> Steps to reproduce:
> 1. Enter monitor parameters and calculated "ModeLines" in the "Monitor" section
> of "xorg.conf"
> 2. List names of the custom ModeLines in the "Display" subsection after the
> keyword "Modes".
> 3. Boot headless (no monitor attached).
> 
> Actual result: 
> 
> Screen resolution is wrong, "/var/log/Xorg.0.log" shows that the custom mode
> was not evaluated, it is not even mentioned.
> 
> Expected result:
> 
> Honor the override, just check monitor parameters to make sure that the pixel
> clock does not exceed the limits. This is how the open source drivers behave.
> 
> Alternatively: document a different way to set a FIXED resolution with the
> fglrx driver.


As work around you could emulate the entire edid. So even if you cannot spcify the video timing using a mode line you can add a fake edid to an display output that contains the video format that you need. So if you have problems with an incorrect or missing edid this method could work. You need to get the edid information that you want to apply as binary file. There are freeware tool available that can capture and edit an edid and save it as binary file.

In you xorg.conf you can check the name of the output on which you want to apply the edid. You might find an entry that looks as follow:

(II) fglrx(0): Output DFP1 disconnected
(II) fglrx(0): Output DFP2 connected
(II) fglrx(0): Output DFP3 disconnected
(II) fglrx(0): Output DFP4 disconnected
(II) fglrx(0): Output DFP5 disconnected
(II) fglrx(0): Output DFP6 disconnected


Assuming you want to override the edid of output DFP2, you need to copy the bin edid file to /et/ati/dfp2.edid

After the next XServer start the driver should take this edid of dfp2. The xorg.0.log should show the following message:

(II) fglrx(0): Successfully loaded EDID override file - /etc/ati/dfp2.edid - bytes:128 

This method works for monitors that are connected through DVI or VGA (including DP to DVI or DP to VGA adapters).
Comment 3 Josua Dietze 2012-02-06 12:11:30 CST
Thank you very much!
I was hoping for a workaround like that. In fact, I'm doing the same thing in Windows 7 on the respective machine (multiboot).

I think I can manage that.

Is there any place where information like that is available? The link to AMD's Radeon on Linux FAQ leads to the standard Catalyst start page.
It would be good to have a simple dedicated page with concise information about the fglrx driver parameters and advanced features. Right now, there is just too much guesswork involved ... Just saying ...
Comment 4 Josua Dietze 2012-02-06 14:58:32 CST
The described workaround via EDID override file works flawlessly.

To create the EDID file I used "Monitor Asset Manager" or "Phoenix EDID Designer" in that 'other' operating system. Both provide a way to save the current monitor's EDID data as a binary/raw file which should be 128 byte in size.
Comment 5 Michael Cronenworth 2012-10-24 16:55:13 CDT
This message is a reminder that your bug is marked as Catalyst 12.1.

The current Catalyst version is 12.10.

Approximately 7 days from now the Bugzilla administrator will be removing the
12.1 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla
administrator provides this as a unofficial, free service to AMD customers, and
I like to keep my systems neat and tidy. If you would like to keep your bug
from being closed, please try a new Catalyst version and update the 'version'
field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will
change it for you.
Comment 6 Michael Cronenworth 2012-10-31 17:02:17 CDT
This bug is being closed due to the 'version' being 12.1 after 7 days of the
previous closure notice.

Thank you for your bug report.